Neil Brown wrote: > On Monday July 3, bluca@xxxxxxxxxx wrote: >> Hello, >> the following patch aims at solving an issue that is confusing a lot of >> users. >> when using udev, device files are created only when devices are >> registered with the kernel, and md devices are registered only when >> started. >> mdadm needs the device file _before_ starting the array. >> so when using udev you must add --auto=yes to the mdadm commandline or >> to the ARRAY line in mdadm.conf >> >> following patch makes auto=yes the default when using udev > > The principle I'm reasonably happy with, though you can now make this > the default with a line like > > CREATE auto=yes > in mdadm.conf. > > However.... > >> + >> + /* if we are using udev and auto is not set, mdadm will almost >> + * certainly fail, so we force it here. >> + */ >> + if (autof == 0 && access("/dev/.udevdb",F_OK) == 0) >> + autof=2; >> + > > I'm worried that this test is not very robust. > On my Debian/unstable system running used, there is no > /dev/.udevdb > though there is a > /dev/.udev/db > > I guess I could test for both, but then udev might change > again.... I'd really like a more robust check. Why to test for udev at all? If the device does not exist, regardless if udev is running or not, it might be a good idea to try to create it. Because IT IS NEEDED, period. Whenever the operation fails or not, and whenever we fail if it fails or not - it's another question, and I think that w/o explicit auto=yes, we may ignore create error and try to continue, and with auto=yes, we fail on create error. Note that /dev might be managed by some other tool as well, like mudev from busybox, or just a tiny shell /sbin/hotplug script. Note also that the whole root filesystem might be on tmpfs (like in initramfs), so /dev will not be a mountpoint. Also, I think mdadm should stop creating strange temporary nodes somewhere as it does now. If /dev/whatever exist, use it. If not, create it (unless, perhaps, auto=no is specified) directly with proper mknod("/dev/mdX"), but don't try to use some temporary names in /dev or elsewhere. In case of nfs-mounted read-only root filesystem, if someone will ever need to assemble raid arrays in that case.. well, he can either prepare proper /dev on the nfs server, or use tmpfs-based /dev, or just specify /tmp/mdXX instead of /dev/mdXX - whatever suits their needs better. /mjt - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html