Date: Mon, 27 Jun 2016 17:21:07 +0200 From: Holger Freyther <holger@freyther.de> To: =?utf-8?Q?Karli_Sj=C3=B6berg?= <karli.sjoberg@slu.se> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: Deadlock in zpool import with degraded pool Message-ID: <9DF3E719-5184-419E-B81A-599D5ECCD969@freyther.de> In-Reply-To: <8a4cb87252c04ebfbf71451c5dc1a41e@exch2-4.slu.se>
index | next in thread | previous in thread | raw e-mail
> On 26 Jun 2016, at 19:28, Karli Sjöberg <karli.sjoberg@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 holgerhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9DF3E719-5184-419E-B81A-599D5ECCD969>