From owner-freebsd-current@FreeBSD.ORG Thu Sep 6 20:08:21 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 8A4D716A41A for ; Thu, 6 Sep 2007 20:08:21 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id DDF9113C478 for ; Thu, 6 Sep 2007 20:08:20 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 6194445E97; Thu, 6 Sep 2007 22:08:18 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id ED16845EB2; Thu, 6 Sep 2007 22:08:11 +0200 (CEST) Date: Thu, 6 Sep 2007 22:06:52 +0200 From: Pawel Jakub Dawidek To: Barry Pederson Message-ID: <20070906200652.GB33420@garage.freebsd.pl> References: <46D4EFFF.5080807@fusiongol.com> <46D5B46D.5010202@gmail.com> <46D66A23.3060108@fusiongol.com> <20070903124232.GC64967@garage.freebsd.pl> <46E02DEE.1010007@barryp.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GPJrCs/72TxItFYR" Content-Disposition: inline In-Reply-To: <46E02DEE.1010007@barryp.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 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, 06 Sep 2007 20:08:21 -0000 --GPJrCs/72TxItFYR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 06, 2007 at 11:42:22AM -0500, Barry Pederson wrote: > Pawel Jakub Dawidek wrote: > >On Thu, Aug 30, 2007 at 03:56:35PM +0900, Nathan Butcher wrote: > >>>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. > > > >You are correct, but not entirely. If you don't export the pool before > >shuffling driver around, ZFS can still recognize them after reboot, but > >those drives have to support GEOM::ident attribute. A disk, when asked > >about this attribute, returns its serial number. If ZFS can find disk > >using its name, it tries to use its ident. Not all GEOM providers > >support idents. Currently only ATA disks and slices/partitions on top of > >ATA disks. >=20 > I've been fooling with a zpool of 8 glabeled SATA disks, 4 of which are= =20 > connected to motherboard SATA ports, and 4 to SAS ports. >=20 > After shutting the machine down (without exporting the pool) and=20 > shuffling disks around , it seems that the disks that were originally=20 > connected via SATA but that are now on the SAS controller show up as=20 > "UNAVAIL"/"cannot open", and doing a "zpool online tank label/750_03"=20 > (for example) doesn't have any effect. The disks really are present=20 > though, showing up in dmesg, glabel status, and able do "dd" from them. >=20 > The disks that were originally on the SAS controller when the pool was=20 > created show up fine when connected to the motherboard SATA ports. >=20 > Doing a "strings /boot/zfs/zpool.cache" I see that it's storing the=20 > serial numbers as described above, of the originally SATA-connected pool= =20 > members, such as: >=20 > path > /dev/label/750_03 > devid > 5QD01BS6s0 >=20 > but the originally SAS-connected drives don't show that "devid" (which=20 > makes sense). >=20 > Does ZFS ignore the path if it thinks the device should have a certain=20 > devid? Is there a slick way to clear out the devid/serial-number from=20 > the zpool's memory? Have you tried zpool export/import? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --GPJrCs/72TxItFYR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG4F3cForvXbEpPzQRAioMAJ4oo5gmxj21pRs48zqxJf3C3w0tIACggh2W hYi69aZEtMXipHtGSRQAvBE= =3ytc -----END PGP SIGNATURE----- --GPJrCs/72TxItFYR--