Date: Sun, 26 Jun 2016 16:52:30 +0000 (UTC) From: Holger Freyther <holger@freyther.de> To: freebsd-fs@freebsd.org Subject: Deadlock in zpool import with degraded pool Message-ID: <loom.20160626T182625-385@post.gmane.org>
next in thread | raw e-mail | index | archive | help
Hi, Everytime I run zpool import tank, I can see disk activity with gstat, with top I see the ARC growing and the free memory going down and then the system seems to lock-up. Adding a swap partition doesn't help. I have tried the zpool import with 10.1, 10.3 and 11.0-CURRENT. My pool consists out of two disks and on the last start the second GELI partition was not attached. When manually doing geli attach + zpool online it started to resilver. The system still had a broken disk inside so I took this opportunity to halt and remove it. On reboot the disk changed from ada2 to ada1. With that the pool was degraded and the only thing I found was zpool replace to replace the physical disk with itself. As it was resilvering before this didn't look like a big loss in terms of time. GELI is not the fastest and I didn't want to wait too long so I started zfs destroy of some volumes I will not use anymore. This should have freed 300GB from 2TB of a ~3TB pool. Before the zfs destroy completing the system locked-up. On reboot the system unlocked both GELI partitions but got stuck on mounting the rootfs. Booting the memstick version of FreeBSD 10.3 and 11.0-CURRENT I do see the deadlock on import (top not updating time, not responding to switches of the VTY, USB keyboard plug/unplug still generating messages though). The system is a AMD64 with 12GB RAM and running FreeBSD 10.1. It has two 3TB disks, a boot pool and the main pool on top of GELI. The main pool runs with deduplication enabled Does this sound familiar? Is there anything I can try before saying good bye to mybacked up data? If the pool itself can not be repaired, is there a way to access the volumes with the data? thanks for your help.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?loom.20160626T182625-385>