Deadlock on zfs import

[David Wimsey]

I should have followed up on my original message.  I presumed it was a memory issue as I know everyone says to use more RAM so I went ahead and put another 4GB in the machine and imported the pool.  The first import took a few minutes as it chewed through the disks for some reason  but it did import and since then I've exported and reimported with normal response times and the machine functions just fine now.  After all the reading I did I came to the conclusion that my setup was just not ZFS worthy with only 4GB since I calculated that I needed about 2GB just for DDT.

In the one instance I had top running it didn't end up at 100% in wired, but it came fairly close before the consoles stopped updating.  If anyone cares enough about the issue to look into it deeper I can pull the extra RAM out and do it again to be sure but I'm considering the problem resolved as an ID10T error on the admin's part (me).

The only change to the whole thing I would like to see is some sort of console indication of the problem.  I realize the difficulty in doing things when the kernel itself is out of memory but it seems like it'd be possible to reserve a little space for outputting a 'Don't do that dummy' type of message for people like me.

Thanks
David Wimsey

On Oct 10, 2012, at 12:45 PM, Freddie Cash <fjwcash at gmail.com> wrote:

> If you boot to single-user mode, disable the auto-import of pools
> (zfs_enable=no in rc.conf), boot to multi-user, start top in one
> terminal, and then manually import the pool in another window, and
> watch top out, does it run out of RAM (putting everything into wired)?
> 
> You're running dedupe with only 4 GB of RAM, with pools over 90% full.
> My guess is that it's running out of ARC space trying to import the
> pool and load the DDT (dedupe table).  The above test will show that
> to be the case (wired memory goes to 100% and system locks up).
> 
> If that's the case, the only solution I've found is to stick more RAM
> into the box.
> 
> If the cause of the "can't import due to running out of ARC" is that
> you were destroying a ZFS filesystem that had dedupe enabled, then you
> can try upgrading to 9-STABLE and add the "zfs features" patch that
> was posted here last week.  That will run the "zfs destroy" process in
> the background and allow the pool to import.  It worked for us ("zfs
> destroy" of a 1 TB filesystem locked up our pool; but the background
> destroy feature let us work around it for importing).
> 
> -- 
> Freddie Cash
> fjwcash at gmail.com