[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: [Patch] Robustly search for ZFS labels & uberblocks
Date: Sat, 28 Jan 2012 20:27:59 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0

On 28.01.2012 19:40, Darik Horn wrote:
2012/1/28 Vladimir 'φ-coder/phcoder' Serbinenko<address@hidden>:
I already commented on 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:

Does adding

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

Vladimir 'φ-coder/phcoder' Serbinenko

reply via email to

[Prev in Thread] Current Thread [Next in Thread]