On Tue, Oct 28, 2008 at 02:44, Neil Brown <neilb@xxxxxxx> wrote:
> On Tuesday October 28, kay.sievers@xxxxxxxx wrote:
>> On Tue, Oct 28, 2008 at 00:23, Neil Brown <neilb@xxxxxxx> wrote:
>> > 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.
>>
>> 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. :)
>
> I've just done a bit of experimentation...
>
> If create an array /dev/md0 and we get a symlink
> /dev/disk/by-id/md-uuid-XXXXX -> ../../md0
> I stop the array and the symlink stays there
> I create a new array as /dev/md0 (hence new uuid)
> and I get an new symlink
> /dev/disk/by-id/md-uuid-YYYY -> ../../md0
> but also, the first symlink goes away.
>
> So somehow that first symlink is being removed even though the device
> isn't being stopped.
I guess mdadm --export didn't give the old name again when the
"change" event was sent. If udev get's an "add" or "change" event for
an existing device, it will lookup the currently links belonging to
that device in its database. It computes the new links, deletes all
the no longer valid links, keeps the still valid ones, and creates the
new ones. On "remove" it will remove all links and possibly restore
stuff this device has overwritten.
> I guess I need a
> kobject_uevent(...., KOBJ_CHANGE)
> when the array is stopped.... [tries that].
If mdadm will not export stuff anymore, the links will be removed that way, yes.
> Better. But it looks like I need to get rid of the partitions too...
>
> Yes. Putting
>
> bdev = bdget_disk(mddev->gendisk, 0);
> if (bdev) {
> blkdev_ioctl(bdev, 0, BLKRRPART, 0);
> bdput(bdev);
> }
> kobject_uevent(&disk_to_dev(mddev->gendisk)->kobj, KOBJ_CHANGE);
>
> at a suitable place in do_md_stop causes all the symlinks created by
> udev to disappear when I stop the array, only the /dev/mdX remains.
> That should do for 2.6.28. Something better maybe for .29.
Yes, BLKRRPART does already send change events for the disk and all partitions.
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
