Date: Thu, 6 Sep 2007 22:06:52 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Barry Pederson <bp@barryp.org> Cc: freebsd-current@freebsd.org Subject: Re: Encrypted zfs? Message-ID: <20070906200652.GB33420@garage.freebsd.pl> In-Reply-To: <46E02DEE.1010007@barryp.org> References: <46D4EFFF.5080807@fusiongol.com> <46D5B46D.5010202@gmail.com> <46D66A23.3060108@fusiongol.com> <20070903124232.GC64967@garage.freebsd.pl> <46E02DEE.1010007@barryp.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070906200652.GB33420>