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

[Andriy Gapon]

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.

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...

-- 
Andriy Gapon