Date: Wed, 29 Aug 2007 16:20:48 -0500 From: Craig Boston <cb@severious.net> To: Christian Walther <cptsalek@gmail.com> Cc: Nathan Butcher <n-butcher@fusiongol.com>, freebsd-current@freebsd.org Subject: Re: Encrypted zfs? Message-ID: <20070829212048.GB896@nowhere> In-Reply-To: <46D5B46D.5010202@gmail.com> References: <46D4EFFF.5080807@fusiongol.com> <46D5B46D.5010202@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Aug 29, 2007 at 06:01:17PM +0000, Christian Walther 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. So long as you re-import the pool, this works great. However, I've found that getting ZFS pools recognized on _boot_ can be really delicate. I have a USB stick with a FreeBSD install on it that uses ZFS for everything (gzip compression is great for this). I do use glabel with the hope that it will always be able to find the device the same way no matter if it's da0, da1, whatever. It seems to work fine so long as I'm really careful not to touch it using anything else. Doing a 'zpool import' (even with -R) from another host in order to pull some files off of it seems to be a surefire way to render it unbootable. Copying the zpool.cache file from a machine that has it imported doesn't help the situation either. So far the only way I've found to recover it is to boot a livecd, import the pool, copy zpool.cache to the boot partition, then immediately (without exporting the pool) power off and boot the USB stick on the same hardware. After doing that it's stable again and can boot on pretty much anything. Craig
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070829212048.GB896>