Re: [PATCH 2.6.20-rc6] md: expose uuid and degraded attributes in sysfs
Neil Brown wrote: On Sunday February 11, [EMAIL PROTECTED] wrote: I don't think moving it would get much argument, but having it visible has advantages as noted in the original post, and opens the door to someone writing code to allow the uuid to be changed with a write to a sys file. We had a discussion of setting uuid a few months ago, I think you agreed it was a reasonable thing to do. Current mdadm lets you change the uuid while assembling an array mdadm -A /dev/mdX --update=uuid --uuid=whatever /dev/.. This was in response to our discussion that you mention. Changing the uuid while the array is active is a somewhat different consideration. It's hard to see it being a good idea. Filesystems have UUIDs. They are visible via the 'blkid' command. md arrays have UUIDs. They are visible via 'mdadm'. sysfs isn't the only place to make things visible, and sometimes it isn't the best. Noted. 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. Outside of forcing changes for all of us using uuid, what does this standard compliance buy us as users? Or you as a maintainer? Does this let Linux get run on a million computers which can't now because of lack or standard compliance? I'm always worried when things change without a visible benefit, so feel free to make the benefits visible. Managed in user space is not a big item for me, it means there will be more more places for errors to creep in. Supporting DDF means we can tick the 'Supports DDF' check-box and sell in to thousands of new potential customers who don't really need it .. no, just kidding. Supporting DDF means we can move drives from a DDF based hardware RAID card only a regular SATA card and still access the data. It means we can dual-boot with another OS that does DDF/raid and have access to the same data. It means that a fakeraid card that has bios support for booting off a RAID array can have the same perspective of the RAID arrays as the kernel has. Or at least, that is the theory. I don't actually know of anything card that definitely used DDF raid yet, but I suspect they will start appearing. You had me going for a moment, but since you don't really know of any controllers using it I'm less impressed ;-) However, if lack of DDF isn't the problem with using hardware RAID drives on software RAID and vice-versa, why *can't* I pull a pair of RAID-1 drives to a software RAID and use them? I can understand that RAID-5 might be different and need some tuning of chunk size or whatever, , but a mirror should be a mirror. And I doubt DDF is going to help. And 'DDF' isn't the only reason that in-kernel UUIDs don't always make sense. If you create an array with no superblock there is likewise no UUID to provide from kernel-space. And where is the DDF? In some standard mandated place? Or wherever the hardware controller puts it? Without a superblock, I can't see that any layout but mirrored would work, and from a sample size of two that doesn't work either. So any solution for easy access to uuids should be done in user-space. Maybe mdadm could create a link /dev/md/by-uuid/ - /dev/whatever. ?? Which would be kept in sync how when the uuid is changed? Don't change the UUID on an active array. Man, what fun is that? ;-) Seriously, I would expect someone to find a use for it, but I agree it's not a requirement for anything I want to do. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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
Re: [PATCH 2.6.20-rc6] md: expose uuid and degraded attributes in sysfs
Neil Brown wrote: On Saturday February 10, [EMAIL PROTECTED] wrote: Iustin Pop wrote: On Sat, Jan 27, 2007 at 02:59:48AM +0100, Iustin Pop wrote: From: Iustin Pop [EMAIL PROTECTED] 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. I don't think moving it would get much argument, but having it visible has advantages as noted in the original post, and opens the door to someone writing code to allow the uuid to be changed with a write to a sys file. We had a discussion of setting uuid a few months ago, I think you agreed it was a reasonable thing to do. 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. Outside of forcing changes for all of us using uuid, what does this standard compliance buy us as users? Or you as a maintainer? Does this let Linux get run on a million computers which can't now because of lack or standard compliance? I'm always worried when things change without a visible benefit, so feel free to make the benefits visible. Managed in user space is not a big item for me, it means there will be more more places for errors to creep in. So any solution for easy access to uuids should be done in user-space. Maybe mdadm could create a link /dev/md/by-uuid/ - /dev/whatever. ?? Which would be kept in sync how when the uuid is changed? I'm not trying to argue with you, just trying to cover the benefits and possible exposures from the change. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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
Re: [PATCH 2.6.20-rc6] md: expose uuid and degraded attributes in sysfs
On Sunday February 11, [EMAIL PROTECTED] wrote: I don't think moving it would get much argument, but having it visible has advantages as noted in the original post, and opens the door to someone writing code to allow the uuid to be changed with a write to a sys file. We had a discussion of setting uuid a few months ago, I think you agreed it was a reasonable thing to do. Current mdadm lets you change the uuid while assembling an array mdadm -A /dev/mdX --update=uuid --uuid=whatever /dev/.. This was in response to our discussion that you mention. Changing the uuid while the array is active is a somewhat different consideration. It's hard to see it being a good idea. Filesystems have UUIDs. They are visible via the 'blkid' command. md arrays have UUIDs. They are visible via 'mdadm'. sysfs isn't the only place to make things visible, and sometimes it isn't the best. 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. Outside of forcing changes for all of us using uuid, what does this standard compliance buy us as users? Or you as a maintainer? Does this let Linux get run on a million computers which can't now because of lack or standard compliance? I'm always worried when things change without a visible benefit, so feel free to make the benefits visible. Managed in user space is not a big item for me, it means there will be more more places for errors to creep in. Supporting DDF means we can tick the 'Supports DDF' check-box and sell in to thousands of new potential customers who don't really need it .. no, just kidding. Supporting DDF means we can move drives from a DDF based hardware RAID card only a regular SATA card and still access the data. It means we can dual-boot with another OS that does DDF/raid and have access to the same data. It means that a fakeraid card that has bios support for booting off a RAID array can have the same perspective of the RAID arrays as the kernel has. Or at least, that is the theory. I don't actually know of anything card that definitely used DDF raid yet, but I suspect they will start appearing. And 'DDF' isn't the only reason that in-kernel UUIDs don't always make sense. If you create an array with no superblock there is likewise no UUID to provide from kernel-space. So any solution for easy access to uuids should be done in user-space. Maybe mdadm could create a link /dev/md/by-uuid/ - /dev/whatever. ?? Which would be kept in sync how when the uuid is changed? Don't change the UUID on an active array. NeilBrown - 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
Re: [PATCH 2.6.20-rc6] md: expose uuid and degraded attributes in sysfs
On Sat, Jan 27, 2007 at 02:59:48AM +0100, Iustin Pop wrote: From: Iustin Pop [EMAIL PROTECTED] 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? 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
Re: [PATCH 2.6.20-rc6] md: expose uuid and degraded attributes in sysfs
Iustin Pop wrote: On Sat, Jan 27, 2007 at 02:59:48AM +0100, Iustin Pop wrote: From: Iustin Pop [EMAIL PROTECTED] 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. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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
Re: [PATCH 2.6.20-rc6] md: expose uuid and degraded attributes in sysfs
On Saturday February 10, [EMAIL PROTECTED] wrote: Iustin Pop wrote: On Sat, Jan 27, 2007 at 02:59:48AM +0100, Iustin Pop wrote: From: Iustin Pop [EMAIL PROTECTED] 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/ - /dev/whatever. ?? NeilBrown - 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
Re: [PATCH 2.6.20-rc6] md: expose uuid and degraded attributes in sysfs
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/ - /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
