Date: Fri, 2 Mar 2018 21:25:54 +0000 (UTC) From: James Phillips <anti_spam256@yahoo.ca> To: <freebsd-fs@freebsd.org> Subject: Re: ZFS trashed by bad import [Update] Message-ID: <104055907.2968604.1520025954207@mail.yahoo.com> References: <104055907.2968604.1520025954207.ref@mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
As Andry Gapon suggested (in an apparently private mail), the problem was mostly user error. The import did indeed overwrite the root directory structure.
While I am aware that the zpool(8) man page is already on the long side: I would suggest a more explicit hint in the import section that you may need to specify an alternate root,
I had expected the command:
# zpool import -f 8255478166520290766 granny
to mount my foreign filesystem under /granny instead of /zroot. It did not occur to me that files would mount above the mount point in the directory hierarchy.
The man page *does* talk briefly about when you would want to use an "altroot" in the "Properties" section:
altroot
Alternate root directory. If set, this directory is prepended to any
mount points within the pool. This can be used when examining an
unknown pool where the mount points cannot be trusted, or in an
alternate boot environment, where the typical paths are not valid.
...
I mostly trust my own filesystem that was merely degraded. I was not in an alternate boot environment (like a live DVD); I was merely trying to import my files into a new FreeBSD installation.
I guess the typical work-flow for a failed disk is simply to attach a new disk in place of the old one (and wait for re-silvering). Since my disk array was was about 5GB too small to ingest all the data I wanted: I wanted to upgrade anyway.
While running ddrescue proved to be unnecessary, it was able to recover about 99.9% of the data from the failed disk. A second invocation was able to recover a further 5kB (mostly a waste of time).
Not sure if it was FS related, but I have absolutely been unable to boot the machine with both pools in place.
The new installation (GELI) reports:
"failed to read pad2 area of primary vdev" (with granny removed -- successful boot).
Granny would not even run the first stage loader.
What I ended up doing is the following:
1. Load up live DVD (with degraded granny + an "archive" disk)
2. # zpool import -f -R /tmp granny
3. # zpool export granny
Later:
1. Same live DVD setup
# ls /dev
-> ada2p1 looks like my "archive" disk
1a. # mount -t extfs /dev/ada2p1 /mnt
2. # zpool import -R /rescue granny
3. # zfs snapshot -r granny@2018-02-26
3b. forgot the -r the first time. To recover (scary command):
# zfs destroy granny@2018-02-26
4a: Learned that sending a zfs to itself is a valid operation (yay snapshots!) cryptic error message (out of disk space):
warning cannot send '...' : signal received
4b. # zfs send -R -D -v granny@2018-02-26 > /mnt/granny.2018-02-26.zfs
5. clean up
# unmount /mnt
# zpool export granny
Incidentally, granny was able to boot after all that, so I am reasonably sure I have all my data back. Have not tried importing it into my new installation yet.
The new machine took me 2 weeks to set up, not 1, but that is off-topic here.
Regards,
James Phillips
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?104055907.2968604.1520025954207>