[Ocfs2-tools-devel] [RFC] changing default block device detection method and more

[Sunil Mushran]

Apart from what you've pointed out, we have also to deal with multipath
and lvm. Have you looked into lib/filters/filter.c in LVM2. That starts
scanning from /proc/devices.

blkid was added before upstream picked up the changes. We have no intention
of making our lives harder. ;)

Fabio Massimo Di Nitto wrote:
> Hi guys,
>
> let's start the flamewar :)
>
> so our tools in general uses /proc/partitions to detect available block devices
> on the system. While this is quick and somewhat a not expensive operation, it
> has a major limitation of not discovering devices that are not exported to
> /proc/partitions. This generally fits well most of the users out there but of
> course not me :)
>
> So there have been several discussion on how we can address this problem.
>
> One of them could be to scan directly /dev for block devices and that is the
> same approach I used in another piece of software that was using
> /proc/partitions. The general experience is that it is still very fast to stat
> the bits we need, we catch all the devices around and sometimes a bit too many
> (for example all loop devices are also shown).
>
> As a proof of concept I prepared a patch for ocfs2console (_DO NOT_ pull for now
> - read below) here:
> http://git.fugedabout.it/?p=people/fabbione/ocfs2-tools.git;a=commitdiff;h=b39b9cc002125c5e81c61fd7af617a697ce80836
>
> The patch is really not as scary as it looks. It is mostly re-indent of already
> existing code.
>
> Another solution could be to walk /sys/block that indeed exports only available
> block devices in the system. The problem is that /sys/block does not have any
> knowledge on how /dev is populated. So once we get to the major/minor
> information of each single device, we still have the issue to go around /dev to
> stat all block devices to match them with /sys/block entries.
> I don't have a PoC for this approach but the code wouldn't look too different
> from the above and it will not solve the "loop" issue as they are still exported
> in /sys/block. So except a possibly shorter list of real devices, there is only
> an increase of code.
>
> One general comment that I heard in a previous discussion is that scanning /dev
> is racy. This is true no matter if you start by /dev or by /sys/block as usually
> /sys/block is populated before the kernel has sent the hotplug even down to
> userland (like udev) and the /dev entry has not been created yet.
>
> Anyway I am very open on any solution, but i want to get to one :)
>
> Other bits:
>
> 1) The /proc/partition scanning code is duplicated 5 times "in wonderful 5
> different variants ;)" within the ocfs2-tools tree. Specifically in:
>
> - ocfs2console
> - ocfs2_hb_ctl
> - mounted.ocfs2
> - listuuid (*)
> - ocfs2console/blkid (**)
>
> what we really care about are the first 3 of them.
> (*) it is not used in the tree at all and there are several variants available
> around provided by other tools. IMHO it could go away from the tree.
> (**) it's there as a matter of commodity. I am personally strongly against
> shipping copies of code that live in other upstream and it is more wise to ask
> the users to get them from the original upstream or distro maintainers rather
> than having to carry to burden to maintain them ourself. So no matter what path
> we take i will not touch this code as it will introduce a delta compared to
> upstream.
>
> 2) the scanning code uses some kind of filtering to avoid work on media that are
> not disks. This generally needs some cleanup to fit with new system. For example
> it checks for cdrom only on IDE chains. Now we have cdrom that are exported as
> scsi devices due to libata changes in the kernel. I am pretty sure we want to
> rework those filters a bit to match the new reality. I already have done some
> work in this direction before for totally different reasons and all the
> information we need are exported in /sys/block so we can stop parsing bits in
> /proc in one go.
>
> Cheers
> Fabio
>
> PS not sure it's clear, but if we find a common solution, I will take care of
> the burden to code it :) (probably only after i will be back from paternity
> leave but there is hope ;))
>
>