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

[Bill Davidsen <davidsen@tmr.com>]

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