Deadlock in zpool import with degraded pool

[Karli Sjöberg]

Den 27 jun 2016 5:28 em skrev Holger Freyther <holger at freyther.de>:
>
>
> > 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?

Yes, it needs to load all unique posts of the destroy into RAM and it can't be swapped either, meaning that once the RAM is full, the system locks up.

> * Why a plain dead-lock and no panic?

No idea. But I know how reluctant developers have been going through ZFS's dedup code. Most is like "twenty foot pole" because of it's complexity, I guess, not a developer my self.

> * Is there an easy way to see how much RAM is needed?

No.

> (In the end I can use Linux/KVM with RAM backed in a file/disk and just wait...)

Good thinking! Wish I had thought of that... After I tried importing with a machine equipped with 64GB I just gave up.

> * Would you know if zpool import -o readonly avoids loading/building that big table?

Yes, I tried that to. Made no difference what so ever unfortunately.

> From common sense this block table would only be needed on write to map from checksum to block?

Common sense?! I wish there was more of that in ZFS's dedup code:)

/K

>
> kind regards
>         holger