Re: [Patch] Robustly search for ZFS labels & uberblocks

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

On 28.01.2012 19:40, Darik Horn wrote:
> 2012/1/28 Vladimir 'φ-coder/phcoder' Serbinenko<phcoder@gmail.com>:
>> I already commented on 10_linux.in changes. They are pretty sloppy. (mostly
>> is "it works for me and I don't care about other legitimate configs")
> How do you want these things changed?  I searched the email archive
> and couldn't find where you gave an example of another legitimate
> configuration, or suggested to how improve any of the related
> submissions by Robert Millan, Richard Laager, or Zachary Bedell.
Even if I didn't do before (I didn't recheck), I did it in another 
message in this thread
> Keep in mind that ZoL cannot resolve the grub mdnobj number, or use
> the Solaris bootpath or devid.  The only thing that matters on the
> Linux command line is the pool name, and everything else is for
> interface compatibility with Solaris.
Even this is already one piece of info which will be resolved wrong.
(Also note that if you need only this particular info you should 
probably consider zfsinfo. In this case it doesn't matter because it's 
still wrong though)
> Also note that this code is in the latest ZFS patch:
>
>    if (strcmp (name, "mirror")&&  !sscanf (name, "mirror-%u",&dummy)
>      &&  !sscanf (name, "raidz%u",&dummy)
>
> That format doesn't match the `zpool status` output on my current
> Solaris and Linux computers.  The vdev names now have the RAID level
> number and a dash character like this:
>
>    raidz1-0
>    raidz1-1
>    raidz2-0
>    raidz3-0
Does adding

"&&  !sscanf (name, "raidz1-%u",&dummy)&&  &&  !sscanf (name, "raidz2-%u",&dummy)&&  !sscanf (name, "raidz3-%u",&dummy)"
resolve this problem?


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko