Re: [Patch] Enable libzfs detection on Linux

[Seth Goldberg]

On 11/10/11 12:02, Robert Millan wrote:
> Hi Zachary,
>
> 2011/9/14 Zachary Bedell<address@hidden>:
> > FWIW, my commit comment locally for this was:
> >   * Adjusts autoconf logic to properly detect libzfs on Linux.
> >   * Includes additional headers necessary for libspl.
>
> Excuse me if I missed something, but weren't you holding the position
> that libzfs ABI was too unstable and relying on it from external
> programs was a bad idea?
>
> Recently Debian has had severe problems in this area because of this.
> C.f. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645305
>
> Last month I sent a proof of concept patch that implements this idea
> (in "getroot for ZFS without libzfs?" thread).  Did you see this part
> of the thread?

Hi,

  I had a conversation with Vladimir about this.  I think retaining 
libzfs is a good thing, Debian bugs notwithstanding.  libzfs provides an 
interfaces that enables a consumer to find zpool on system without 
scanning the world (the idea being that the kernel has already done 
that, and has cached that information), so one need not have to deal 
with devices that might become unresponsive to a user-level process when 
scanned.  It also allows one to enumerate pools that might have the same 
name (in which case you'd use the pool's GUID (in base 10) to access the 
pool).  So libzfs, whatever its stability level, still seems like a 
better plan than going out to disks directly and pulling metadata.

(FWIW, I looked at that Debian bug, and IMHO, the problem there was that 
libzfs wasn't properly versioned in the first place-- if the person who 
added or changed the libzfs API didn't version it, they're just asking 
for trouble.  The proper solution in that case would have been adding 
versioning and not pulling the whole library).

 --S