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>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 26 Jun 2016, at 19:28, Karli Sj=C3=B6berg <karli.sjoberg@slu.se> = wrote: >=20 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? =46rom common sense this block table would only be = needed on write to map from checksum to block? kind regards holger=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9DF3E719-5184-419E-B81A-599D5ECCD969>