Deadlock in zpool import with degraded pool

Holger Freyther holger at freyther.de
Mon Jun 27 15:21:12 UTC 2016


> On 26 Jun 2016, at 19:28, Karli Sjöberg <karli.sjoberg at slu.se> wrote:
> 

Hi,



> That's your problem right there; dedup! You need to throw more RAM into it until the destroy can complete. If the mobo is 'full', you need new/other hw to cram more RAM into or you can kiss your data goodbye. I've been in the exact same situation as you are now so I sympathize:(

did you look at it further?

* Why does it only start after I zfs destroyed something? The dedup hash/table/??? grows by that?
* Why a plain dead-lock and no panic?
* Is there an easy way to see how much RAM is needed? (In the end I can use Linux/KVM with RAM backed in a file/disk and just wait...)
* Would you know if zpool import -o readonly avoids loading/building that big table? From common sense this block table would only be needed on write to map from checksum to block?

kind regards
	holger


More information about the freebsd-fs mailing list