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

[Joel Becker]

On Tue, Nov 27, 2007 at 07:33:05AM +0100, Fabio Massimo Di Nitto wrote:
> note that I already applied a "udev filter" in /dev scanning to skip .static.
> 
> +      if (strcmp(namelist[n]->d_name, ".") &&
> +         strcmp(namelist[n]->d_name, "..") &&
> +         strcmp(namelist[n]->d_name, ".static") && <----
> +         strcmp(namelist[n]->d_name, ".udev"))

	Checking on things, wouldn't it be best as
"if (namelist[n]->d_name[0] == ".")"?  Everyone does magic things
(.static, .udev, .initramfs, .udev.tbd, etc) as hidden files.  Makes us
pretty future proof.

> I think I have a solution that I believe is the best compromise.
> 
> We start scanning /sys/block for disks (this will solve directly the filtering
> problem at the source by skipping tapes, cd-rom's no matter how they are
> connected to the system or called in /dev).

	Yeah, <sysfspath>/removable is a nice start - if 0 we don't even
worry about checking <sysfspath>/device/media.

> We gather the major/minor for each device and by simply doing a stat in /dev
> (and filtering .static as in the previous code) we can associate maj/min to the

	We're scanning recursively in /dev, not just listing the
toplevel, right?

> name in /dev. If we find no devices we can either wait a few secs or just skip
> it (thought luck).

	Yup.  I'd say wait a second.  The stat(2) will be cached on the
second pass.

> It is slightly more expensive because there might be tons of entries in /sys but
> none of them will involve a disk access and we will do a real check only on
> devices we care. Stat of /dev is cheap as an ls (you can't make it cheaper than
> that I believe).

	It depends on what you are looking for.  If you want to iterate
on devices, you have to do the whole scan anyway (eg the partition list
in ocfs2console).  If you want a specific device, /dev/disk/by-* is what
you want.  (I have to look at our use cases again).

> The code will be a bit more complex as we need to work on 2 lists rather than
> one, but I doubt this is an issue at all.
> 
> How does it sound?

	Sounds like a nice approach.  Are you going to try to make it
code usable in ocfs2-tools and gfs2-tools?

Joel

-- 

"The whole principle is wrong; it's like demanding that grown men 
 live on skim milk because the baby can't eat steak."
        - author Robert A. Heinlein on censorship

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127