Date: Sat, 23 Oct 2010 12:03:03 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Karl Pielorz <kpielorz_lst@tdx.co.uk> Cc: freebsd-fs@freebsd.org Subject: Re: ZFS 'read-only' device / pool scan / import? Message-ID: <20101023100303.GE1742@garage.freebsd.pl> In-Reply-To: <F92BF0095A701A7CC2045894@Octa64> References: <E1P8W1Q-0004Y2-7Z@dilbert.ticketswitch.com> <F92BF0095A701A7CC2045894@Octa64>
next in thread | previous in thread | raw e-mail | index | archive | help
--cPi+lWm09sJ+d57q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 23, 2010 at 09:56:43AM +0100, Karl Pielorz wrote: >=20 > --On 20 October 2010 11:35 +0100 Pete French <petefrench@ticketswitch.com= >=20 > wrote: >=20 > >You can do a forced export - as long as the system doesnt think > >the pool is imported then an import will go looking. I made a > >similar mess of my drives the first time I changed discs oover, and I > >also didnt know about the import/export trick. But since then I > >have used iit every time I have got into trouble and it has always > >worked for me. >=20 > As a follow up to this - we tried to reproduce the original problem once= =20 > we'd restored the data. We removed a drive - rebooted, and got 'a mess': >=20 > " > NAME STATE READ WRITE CKSUM > vol UNAVAIL 0 0 0 insufficient replicas > mirror ONLINE 0 0 0 > da1 ONLINE 0 0 0 > da2 ONLINE 0 0 0 > da3 UNAVAIL 0 0 0 corrupted data > mirror UNAVAIL 0 0 0 insufficient replicas > da4 FAULTED 0 0 0 corrupted data > da5 FAULTED 0 0 0 corrupted data > da6 FAULTED 0 0 0 corrupted data > mirror UNAVAIL 0 0 0 insufficient replicas > da7 FAULTED 0 0 0 corrupted data > da8 FAULTED 0 0 0 corrupted data > da9 FAULTED 0 0 0 corrupted data > mirror UNAVAIL 0 0 0 insufficient replicas > da10 FAULTED 0 0 0 corrupted data > da11 FAULTED 0 0 0 corrupted data > " Your analysis is incorrect, I'm afraid. ZFS in FreeBSD can cope really well with disks name changes. Your problem is somewhere else. My guess is that you booted your machine in single-user mode and you didn't run: # /etc/rc.d/hostid start ZFS has protection for SAN/NAS environments where it keeps hostid in its metadata, so when you try to import the pool on different machine by accident it will warn you and will require -f option if you really know what you are doing. The rc.d/hostid script is there to configure hostid for your system. It is not executed in single-user mode, so hostid of your system is not set properly. I do agree that running /etc/rc.d/hostid in single-user mode should be documented better. > Doing a zpool export, then a zpool import (which required '-f' to get pas= t=20 > "cannot import 'vol': pool may be in use from other system use '-f' to=20 > import anyway") Yes, -f is required, because hostid is now different (uninitialized), but really you don't need export/import cycle if you first set your hostid right. If you could repeat your test, but executing the following command in the following order once you boot into single-user mode: # /etc/rc.d/hostid start # zpool status > Seems to have done the trick: [...] When you now boot in multi-user mode I guess you will have the same problem, because now ZFS stored invalid (uninitialized) hostid in its metadata. As for read-only imports. This is not possible in the ZFS version we have now, but such functionality is available in most recent ZFS, which is not yet in FreeBSD. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --cPi+lWm09sJ+d57q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkzCstcACgkQForvXbEpPzRApACdHTQFEAUFX+KKVr19JMeI4iYA 9p8AoM+edvhy3j2TEp0STxORmGyV9h76 =Omqk -----END PGP SIGNATURE----- --cPi+lWm09sJ+d57q--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101023100303.GE1742>