On Tue, Oct 28, 2008 at 01:43, Neil Brown <neilb@xxxxxxx> wrote: > On Tuesday October 28, kay.sievers@xxxxxxxx wrote: >> > But in different places. >> > Debian has /etc/udev/rules >> > openSUSE has /lib/udev/rules >> > >> > I love standards. There are so many to choose from. :-) >> >> They are all valid and needed. You should install in >> /lib/udev/rules.d/ if the rule is not supposed to be edited by the >> user. > > Clearer now. Thanks. > >> > I notice that 'md' >> > devices don't seem to disappear. Maybe that is because /sys/block/mdX >> > never disappears (last time I tried it was too racy). >> >> It stays because the md kernel device lifetime rules are kind of >> broken regarding hotplug setups. Similar issue why md needs all the >> static nodes in /dev too to create a device. >> >> > Would there be any way to get udev to delete devices when >> > /sys/block/mdX/md/array_state >> > becomes 'clear' (presumably on a CHANGE event) ?? >> >> What would be the reason to leave the kernel block device around? >> Can't you just remove it like any other subsytem in the kernel does. >> That would just remove the node, all links and update userspace to >> reflect the change. > > I tried some time ago. It was hard. > > md devices magic appear when you tried to open the device-special > file. I need some sort of locking to prevent that creation while I'm > destroying the old device. But when I was trying this (quite some > months ago) the locking around do_open was fairly difficult to > follow. I don't remember the exact issues, but I gave up. > > What would happen was that when the md device disappear, udev would > try to open it (I think) and make it reappear again. Sometimes with > an oops. I think I avoided some of that by sending the DELETE event > well before the device was actually deleted ... or something. But it > was still far from perfect. Hmm, that would be a bug, if udev looks at a volume at "remove". > Maybe I should try again. I would love to see /sys reflecting the actual state and not carrying all the "dead" devices. Also some other logic to instantiate a new device then open() would be nice. Other subsytems use control device nodes to request new devices, sysfs might work too, if that's the preferred method. The create-on-open is just a not easy to solve chicken/egg problem today and not really supported. Can't we have mdadm creating new devices with a control device instead of relying on the open() logic of a pre-existing device node? >> There is currently no "change" event that could tell to remove a >> device node in /dev while we still have a kernel device around. And >> you would need to convince me that this is really needed, and why md >> is so special here. :) > > md is a bit 'special', but not quite unique. I think 'loop' now works > the same way as md in terms of devices magically appearing on open. Yeah, that's fine for some special use cases, they also have "destruct on last close" now which sounds useful for some setups. But as mentioned the whole create-at-open does not really integrate with a dynamic /dev. > Maybe I can see how it was made to work for that case. That would be great. Thanks, Kay -- 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
