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> References: <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 holgerhelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9DF3E719-5184-419E-B81A-599D5ECCD969>