[PATCH 3/3] Don't pass md array UUID as member format UUID.

Anne Mulhern amulhern at redhat.com
Mon Aug 4 10:04:14 UTC 2014





----- Original Message -----
> From: "David Lehman" <dlehman at redhat.com>
> To: anaconda-patches at lists.fedorahosted.org
> Sent: Friday, August 1, 2014 6:46:19 PM
> Subject: Re: [PATCH 3/3] Don't pass md array UUID as member format UUID.
> 
> On 08/01/2014 03:35 AM, Anne Mulhern wrote:
> >
> >
> >
> >
> > ----- Original Message -----
> >> From: "David Lehman" <dlehman at redhat.com>
> >> To: anaconda-patches at lists.fedorahosted.org
> >> Sent: Friday, August 1, 2014 12:16:04 AM
> >> Subject: [PATCH 3/3] Don't pass md array UUID as member format UUID.
> >>
> >> Related: rhbz#1070095
> >> ---
> >>   blivet/devicetree.py | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/blivet/devicetree.py b/blivet/devicetree.py
> >> index 73558df..03da94f 100644
> >> --- a/blivet/devicetree.py
> >> +++ b/blivet/devicetree.py
> >> @@ -1806,7 +1806,7 @@ class DeviceTree(object):
> >>
> >>               # attempt to reset the uuid using mdexamine info
> >>               # will succeed only if metadata version > 0.90
> >> -            kwargs["uuid"] = udev.device_get_md_device_uuid(info) or
> >> kwargs["uuid"]
> >> +            kwargs["uuid"] = udev.device_get_md_device_uuid(info)
> >>
> >>               kwargs["biosraid"] = udev.device_is_biosraid_member(info)
> >>           elif format_type == "LVM2_member":
> >> --
> >> 1.9.3
> >>
> >> _______________________________________________
> >> anaconda-patches mailing list
> >> anaconda-patches at lists.fedorahosted.org
> >> https://lists.fedorahosted.org/mailman/listinfo/anaconda-patches
> >>
> >
> > If it's really true that the value obtained from device_get_uuid()
> > is certain to be completely irrelevant here, so that we can
> > override it unconditionally, then device_get_uuid() can probably
> > be simplified to a 1-liner and maybe a comment added about the
> > nature of ID_FS_UUID (it's not clear to me what might be expected
> > to set it.)
> 
> If MD_UUID was ever in the udev info for md members, it isn't anymore.
> It probably came from anaconda's udev rules.

I believe that I actually saw it pop up as a result of running the previous
pyudev code in the debugger. I can't for the life of me see any way that
mdadm could be setting it, but I do think I saw it.

> > ID_FS_UUID is the UUID of the filesystem/data on the current device. It
> only becomes complicated with md and btrfs because, instead of using
> ID_FS_UUID for the device-specific (and therefore unique, like a UUID
> should be) value, they use it for the container/array/volume and
> introduce ID_FS_UUID_SUB for the member-specific UUIDs. LVM (correctly)
> has the PV UUID as ID_FS_UUID of the members and then you have to look
> elsewhere for VG and/or LV UUIDs.
> 
> Anyway, I was able to reduce device_get_uuid to a single line and since
> I just found out that ID_FS_UUID_SUB contains the md member-specific
> UUID I changed device_get_md_device_uuid like this:
> 
> @@ -395,7 +387,9 @@ def device_get_md_device_uuid(info):
>       # Value for MD_UUID known to be obtained from:
>       #  * pyudev/libudev
>       #  * mdraid/mdadm (only 1.x metadata versions)
> -    return info.get('MD_DEV_UUID')
> +    # Value for ID_FS_UUID_SUB known to be obtained from:
> +    #  * pyudev/libudev
> +    return info.get('ID_FS_UUID_SUB') or info.get('MD_DEV_UUID')
> 

I just realized that now that the infos are distinct that it works,
but wierdly. If you pass udev info you may get value for ID_FS_UUID_SUB,
but if md info then you may get value for MD_DEV_UUID. So, it might make
sense to pass both infos.

I'm not sure how to handle this exactly, but it does make an argument
for the notion of having a SuperCache of the kind I described in my
previous email.



> >
> > Also, the comment should be changed to something like:
> >
> > reset the device UUID using mdexamine info
> > UUID is None if metadata version <= 0.90
> >
> > or something like that.
> 
> Done.
> 
> >
> > - mulhern
> >
> >
> > _______________________________________________
> > anaconda-patches mailing list
> > anaconda-patches at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/anaconda-patches
> >
> 
> _______________________________________________
> anaconda-patches mailing list
> anaconda-patches at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/anaconda-patches
> 


More information about the anaconda-patches mailing list