From owner-freebsd-current@FreeBSD.ORG Thu Aug 30 06:56:53 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1064516A41B for ; Thu, 30 Aug 2007 06:56:53 +0000 (UTC) (envelope-from n-butcher=freebsd-current=freebsd.org=sbibybnr@fusiongol.com) Received: from smtp02.dentaku.gol.com (smtp02.dentaku.gol.com [203.216.5.72]) by mx1.freebsd.org (Postfix) with ESMTP id D475A13C46B for ; Thu, 30 Aug 2007 06:56:52 +0000 (UTC) (envelope-from n-butcher=freebsd-current=freebsd.org=sbibybnr@fusiongol.com) Received: from pat.gol.co.jp ([203.216.1.191] helo=[127.0.0.1]) by smtp02.dentaku.gol.com with esmtpa (Dentaku) id 1IQdxD-00034i-Od; Thu, 30 Aug 2007 15:56:35 +0900 Message-ID: <46D66A23.3060108@fusiongol.com> Date: Thu, 30 Aug 2007 15:56:35 +0900 From: Nathan Butcher User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Christian Walther References: <46D4EFFF.5080807@fusiongol.com> <46D5B46D.5010202@gmail.com> In-Reply-To: <46D5B46D.5010202@gmail.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Abuse-Complaints: abuse@gol.com Cc: freebsd-current@freebsd.org Subject: Re: Encrypted zfs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2007 06:56:53 -0000 > AFAIK zfs is immune against device enumeration issues itself. There is a > nice video on YouTube showing Sun engineers setting up a ZFS pool on a > bunch of USB sticks. Afterwards they remove all of them, shuffle them, > and put them back in. No problem. You're correct,... only as long as the zpool is EXPORTED FIRST, and imported after the drives have been shuffled around. ZFS has no trouble piecing them back together wherever they are during an import, it seems. If you were to, say, forget to export the zpool, shutdown your system, shuffle the drives around, and THEN restart the system with the drives in the wrong places, zfs will consider the zpool unavailable. In this case, all the drives will be turn up as FAULTED due to "corrupted data"... when in reality, ZFS was set up to expect certain data to be on certain drives, and now it just can't find it thanks to the harddrive "hokey-pokey" done on it. I guess glabeling isn't really necessary, but it does prevent the above issue from ever occuring.... "An ounce of prevention" or something like that.