On Sun, Feb 11, 2007 at 08:15:31AM +1100, Neil Brown wrote: > Resending after a suitable pause (1-2 weeks) is never a bad idea. Ok, noted, thanks.
> Exposing the UUID isn't - and if it were it should be in > "md_default_attrs" rather than "md_redundancy_attrs". > > The UUID isn't an intrinsic aspect of the array. It is simply part of > the metadata that is used to match up different devices from the same > array. I see. Unfortunately, for now it's the only method of (more or less) persistently identifying the array. > I plan to add support for the 'DDF' metadata format (an 'industry > standard') and that will be managed entirely in user-space. The > kernel won't know the uuid at all. I've briefly looked over the spec, but this seems a non-trivial change, away from current md superblocks to ddf... But the virtual disk GUIDs seem nice. In the meantime, probably the solution you gave below is best. > So any solution for easy access to uuids should be done in user-space. > Maybe mdadm could create a link > /dev/md/by-uuid/xxxxxxxx -> /dev/whatever. > ?? That sounds like a good idea. mdadm (or udev or another userspace solution) should work, given some safety measures against stale symlinks and such. It seems to me that, since now it's possible to assemble arrays without mdadm (by using sysfs), mdadm is not the best place to do it. Probably relying on udev is a better option, however it right now it seems that it gets only the block add events, and not the block remove ones. Thanks, Iustin - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
