zfs: affected by geom_(mbr|bsd) => geom_part_(mbr|bsd) ?

[Marcel Moolenaar]

On Nov 26, 2008, at 1:22 PM, Andriy Gapon wrote:

> on 18/11/2008 21:49 Marcel Moolenaar said the following:
>> On Nov 18, 2008, at 9:29 AM, Andriy Gapon wrote:
>>> I just remembered that I saved old zpool.cache file before  
>>> "migrating"
>>> the pool.
>>> I looked at the diff of hexdumps and there are a number of  
>>> differences,
>>> it's hard to understand them because the file is binary (actually it
>>> seems to contain serialized name-value pairs), but one difference is
>>> prominent:
>>> ...
>>> 00000260  64 65 76 69 64 00 00 00  00 00 00 09 00 00 00 01
>>> |devid...........|
>>> ...
>>> -00000270  00 00 00 15 61 64 3a 47  45 41 35 33 34 52 46 30
>>> |....ad:GEA534RF0|
>>> -00000280  54 4b 33 35 41 73 31 73  33 00 00 00 00 00 00 28
>>> |TK35As1s3......(|
>>> ...
>>> +00000270  00 00 00 11 61 64 3a 47  45 41 35 33 34 52 46 30
>>> |....ad:GEA534RF0|
>>> +00000280  54 4b 33 35 41 00 00 00  00 00 00 28 00 00 00 28
>>> |TK35A......(...(|
>>> ...
>>>
>>> It looks like old "devid" value is "ad:GEA534RF0TK35As1s3" and new  
>>> one
>>> is "ad:GEA534RF0TK35A". Just a reminder: actual zpool device is  
>>> ad6s2d.
>>>
>>> The new value is what is reported by diskinfo:
>>> $ diskinfo -v ad6
>>> ad6
>>> ...
>>>       ad:GEA534RF0TK35A       # Disk ident.
>>>
>>> $ diskinfo -v ad6s2
>>> ad6s2
>>> ...
>>>       ad:GEA534RF0TK35A       # Disk ident.
>>>
>>> $ diskinfo -v ad6s2d
>>> ad6s2d
>>> ...
>>>       ad:GEA534RF0TK35A       # Disk ident.
>>>
>>> Hmm, "indent" is reported to be the same for all three entities.
>>>
>>> I don't remember what diskinfo reported with pre-gpart kernel, but I
>>> suspect that it was something different.
>>> Could anybody please check this? (on 7.X machine without GEOM_PART).
>>>
>>> I quickly glimpsed through sources and it seems that this comes from
>>> DIOCGIDENT GEOM ioctl i.e. "GEOM::ident" attribute. It seems that
>>> geom_slice.c code has some special handling for that.
>> Interesting. Can you try the attached patch to GPart:
>
> Marcel,
>
> unfortunately the patch caused a panic.
> Unfortunately, again, I wasn't able to catch a proper dump, but I  
> remembered that the panic was in g_part_done+0x16.

I see :-/

> In general, I am not sure if anything is really needed in this  
> direction.
> First, I think that pjd has recently committed changes to trunk ZFS,  
> so that it doesn't need device ids anymore and uses some metadata in  
> the devices.
> Second, there is a migration path that I used - export/import of a  
> pool.
>
> So unless this detail of backward compatibility is really needed  
> somewhere else...

pjd told me that and since it was added for ZFS, I think I'll
just drop it. Patching GEOM:ident this way is kinda ugly...

Thanks for testing!

-- 
Marcel Moolenaar
xcllnt at mac.com