From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1RQReZ-0003fC-Ab for mharc-grub-devel@gnu.org; Tue, 15 Nov 2011 17:38:55 -0500 Received: from eggs.gnu.org ([140.186.70.92]:44158) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQReW-0003f0-4e for grub-devel@gnu.org; Tue, 15 Nov 2011 17:38:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RQReU-0000vc-VL for grub-devel@gnu.org; Tue, 15 Nov 2011 17:38:52 -0500 Received: from rcsinet15.oracle.com ([148.87.113.117]:43794) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQReU-0000vQ-QC for grub-devel@gnu.org; Tue, 15 Nov 2011 17:38:50 -0500 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pAFMcmMI018685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 15 Nov 2011 22:38:49 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id pAFMcmJd021540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 15 Nov 2011 22:38:48 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id pAFMch3w023492 for ; Tue, 15 Nov 2011 16:38:43 -0600 Received: from [10.132.136.136] (/10.132.136.136) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 15 Nov 2011 14:38:42 -0800 Message-ID: <4EC2E98C.6020705@oracle.com> Date: Tue, 15 Nov 2011 14:37:00 -0800 From: Seth Goldberg User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:6.0.2) Gecko/20111003 Thunderbird/6.0.2 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: [Patch] Enable libzfs detection on Linux References: <37B025F9-45D9-4424-8458-6B40D2D5A249@gmail.com> <4E4D42A8.4000503@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4EC2E9F9.014E,ss=1,re=0.000,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 148.87.113.117 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 22:38:53 -0000 On 11/10/11 12:02, Robert Millan wrote: > Hi Zachary, > > 2011/9/14 Zachary Bedell: >> 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