Re: RFC - device names and mdadm with some reference to udev.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Oct 27, 2008 at 23:37, Neil Brown <neilb@xxxxxxx> wrote:
> On Monday October 27, madduck@xxxxxxxxxx wrote:
>> also sprach Neil Brown <neilb@xxxxxxx> [2008.10.26.2356 +0100]:

>> I would really like to have a clear separation of competencies.
>> Ideally, mdadm never creates any devices but leaves it all to udev,
>> and all configuration about alternate names ("symlinks") is done in
>> the udev rules file.
>
> Yes, I am moving towards this.  And it seems to be an idea with
> resounding support judging by the follow-ups.  So I will probably go
> even further than I was planning.
>  - if mdadm detects that udev is active (how do I do that???)

Most tools just check if /dev/.udev/ exists.

>   mdadm
>   won't create anything in /dev, or remove anything from /dev, except
>   for temporary devices with names that start with '.'.

Fine.

>  - if mdadm does not detect udev, it will still create the device
>   and maybe some links.  And remove anything it might have created.

Sounds good.

>> I know mdadm needs the devices for the ioctls(). However, much of
>> what it does with ioctl should already be possible with /sys. Thus,
>> in my ideal world, I imagine mdadm to be a manipulator of /sys,
>> instructing the kernel to do stuff with components and arrays, and
>> have udev create and remove corresponding devices in response to
>> kernel events.
>
> Most things can now be done via sysfs, but not everything (bitmaps is
> the most obvious hole in the sysfs support).  And I still need to
> support older kernels that don't have as many sysfs attributes.
>
> However I do want to move towards using sysfs preferentially,
> particularly for "mdadm --monitor".  I would rather that daemon didn't
> ever open the device, as that can interfere with e.g. stopping the
> array.  The "mdadm -D" calls from udev also need to not open the device.

Sounds fine, but remember that udev will always look at every device's
content if not explicitly told no to do. It will look for filesystem
signatures and other metadata at the beginning and the end of the
device.

> One issue that looms in my mind as I consider this is the Usage of
> mdadm when e.g. creating an array
>
>   mdadm -C /dev/md5 -l5 -n3 /dev/sd[bcd]
>
> I need to give the name of an array device (/dev/md5) that may not
> exist but that mdadm doesn't now want to create.
>
> Once I have created the array I might want to look at the details with
>
>   mdadm --detail /dev/md5
>
> The important role that the string "/dev/md5" is serving here is
> providing a connection between the two command.  Whatever I created in
> the first is what I access in the second.

Can't you just use the major/minor is there is no other meaningful
name? The devnum can not change on any system, and is always valid as
long as the kernel device exists.

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

[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux