[PATCH 2.6.20-rc6] md: expose uuid and degraded attributes in sysfs

[PATCH 2.6.20-rc6] md: expose uuid and degraded attributes in sysfs

[Iustin Pop]

From: Iustin Pop <iusty@k1024.org>

This patch exposes the uuid and the degraded status of an assembled
array through sysfs.

The uuid is useful in the case when multiple arrays exist on a system
and userspace needs to identify them; currently, the only portable way
that I know of is using 'mdadm -D' on each device until the desired uuid
is found. Having the uuid visible in sysfs is much more cleaner, IMHO.
Note on the method to format the uuid: I'm not sure if this is the best
way, I've copied and transformed the one in print_sb.

The 'degraded' attribute is also useful to quickly determine if the
array is degraded, instead of, again, parsing 'mdadm -D' output or
relying on the other techniques (number of working devices against
number of defined devices, etc.). The md code already keeps track of
this attribute, so it's useful to export it.

Signed-off-by: Iustin Pop <iusty@k1024.org>
---

--- linux-2.6.20-rc6/drivers/md/md.c.orig	2007-01-27 02:31:11.496575360 +0100
+++ linux-2.6.20-rc6/drivers/md/md.c	2007-01-27 02:32:51.746741201 +0100
@@ -2856,6 +2856,22 @@
 static struct md_sysfs_entry md_suspend_hi =
 __ATTR(suspend_hi, S_IRUGO|S_IWUSR, suspend_hi_show, suspend_hi_store);
 
+static ssize_t
+uuid_show(mddev_t *mddev, char *page)
+{
+	__u32 *p = (__u32*)mddev->uuid;
+	return sprintf(page, "%08x:%08x:%08x:%08x\n", p[0], p[1], p[2], p[3]);
+}
+static struct md_sysfs_entry md_uuid =
+__ATTR_RO(uuid);
+
+static ssize_t
+degraded_show(mddev_t *mddev, char *page)
+{
+	return sprintf(page, "%i\n", mddev->degraded);
+}
+static struct md_sysfs_entry md_degraded =
+__ATTR_RO(degraded);
 
 static struct attribute *md_default_attrs[] = {
 	&md_level.attr,
@@ -2881,6 +2897,8 @@
 	&md_suspend_lo.attr,
 	&md_suspend_hi.attr,
 	&md_bitmap.attr,
+	&md_uuid.attr,
+	&md_degraded.attr,
 	NULL,
 };
 static struct attribute_group md_redundancy_group = {

Re: [PATCH 2.6.20-rc6] md: expose uuid and degraded attributes in sysfs

[Iustin Pop]

On Sat, Jan 27, 2007 at 02:59:48AM +0100, Iustin Pop wrote:
> From: Iustin Pop <iusty@k1024.org>
> 
> 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

Re: [PATCH 2.6.20-rc6] md: expose uuid and degraded attributes in sysfs

[Bill Davidsen]

Iustin Pop wrote:
> On Sat, Jan 27, 2007 at 02:59:48AM +0100, Iustin Pop wrote:
>   
>> From: Iustin Pop <iusty@k1024.org>
>>
>> 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 <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

Re: [PATCH 2.6.20-rc6] md: expose uuid and degraded attributes in sysfs

[Neil Brown]

On Saturday February 10, davidsen@tmr.com wrote:
> Iustin Pop wrote:
> > On Sat, Jan 27, 2007 at 02:59:48AM +0100, Iustin Pop wrote:
> >   
> >> From: Iustin Pop <iusty@k1024.org>
> >>
> >> 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

Re: [PATCH 2.6.20-rc6] md: expose uuid and degraded attributes in sysfs

[Iustin Pop]

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

Re: [PATCH 2.6.20-rc6] md: expose uuid and degraded attributes in sysfs

[Bill Davidsen]

Neil Brown wrote:
> On Saturday February 10, davidsen@tmr.com wrote:
>   
>> Iustin Pop wrote:
>>     
>>> On Sat, Jan 27, 2007 at 02:59:48AM +0100, Iustin Pop wrote:
>>>   
>>>       
>>>> From: Iustin Pop <iusty@k1024.org>
>>>>
>>>> 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/xxxxxxxx -> /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 <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

Re: [PATCH 2.6.20-rc6] md: expose uuid and degraded attributes in sysfs

[Neil Brown]

On Sunday February 11, davidsen@tmr.com 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/xxxxxxxx -> /dev/whatever.
> > ??
> >
> >   
> Which would be kept in sync how when the uuid is changed?

Don't change the UUID on an active array.

NeilBrown

Re: [PATCH 2.6.20-rc6] md: expose uuid and degraded attributes in sysfs

[Bill Davidsen]

Neil Brown wrote:
> On Sunday February 11, davidsen@tmr.com 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/xxxxxxxx -> /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 <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979