zpool import taking weeks ...

[Freddie Cash]

On Tue, Jan 14, 2014 at 8:58 AM, Thomas Hoffmann <trh411 at gmail.com> wrote:

> On Tue, Jan 14, 2014 at 11:52 AM, Freddie Cash <fjwcash at gmail.com> wrote:
>
>> Dedupe enabled on this server?
>>
>>
>> --
>> Freddie Cash
>> fjwcash at gmail.com
>
>
>  Buried in his rather lengthy text was:
>
> "The storage is using one zpool with multiple dataset with dedup on (i
> know it EATS RAM :s )"
>
> So the answer is yes.
>

​Whoops, missed that.

In that case, it's "normal".  The pool was interrupted in the middle of a
send and a rollback.  The import will now do the necessary cleanup to
return the pool to the correct state, during the import process.  To do so,
it has to remove all the blocks from the send, remove all the blocks from
the rollback, and update the DDT entries for all those blocks.

It will load the DDT into ARC as needed, and eventually blow out all the
RAM in the system and lockup.

Reboot, re-do the import, it will continue from where it left off, load the
DDT into ARC, and eventually blow out all the RAM in the system and lockup.

Rinse, repeat, reboot, blah blah blah.

After several iterations, it will eventually finish the cleanup, and the
pool will import.

This is a known limitation of dedupe and interrupted operations.  Similar
to the "destroy lots of filesystems" and then lockup issue.  Basically,
dedupe makes a lot of things very slow in recovery.

I once had to spend 2 weeks doing the reboot/import/wait/lockup dance to
get through a similar situation.​

​-​
-
Freddie Cash
fjwcash at gmail.com