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

Fabio Massimo Di Nitto fabbione at ubuntu.com
Mon Nov 19 23:05:24 PST 2007


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 ;))

-- 
I'm going to make him an offer he can't refuse.



More information about the Ocfs2-tools-devel mailing list