On Saturday February 10, davidsen@xxxxxxx wrote: > Iustin Pop wrote: > > On Sat, Jan 27, 2007 at 02:59:48AM +0100, Iustin Pop wrote: > > > >> From: Iustin Pop <iusty@xxxxxxxxx> > >> > >> This patch exposes the uuid and the degraded status of an assembled > >> array through sysfs. > >> > > [...] > > > > Sorry to ask, this was my first patch and I'm not sure what is the > > procedure to get it considered for merging... I was under the impression > > that just sending it to this list is enough. What do I have to do? > Normally I would expect Neil to pick it up and forward it, but I would > have expected an ack from him. He's been busy with other problems, NFS > as I recall, and may have missed it, so I cc'd him this time. > > Neil, I would think this is 2.6.21 material unless you see a problem I > missed. > yeh - sorry about that. mail is somewhat of a lossy protocol for me. I usually try to reply, but sometimes it just doesn't happen. Resending after a suitable pause (1-2 weeks) is never a bad idea. Exposing the 'degraded' status is probably a good idea. I'll take that. 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 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. 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. ?? NeilBrown - 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
