Date: Wed, 10 Oct 2012 12:58:57 -0400 From: David Wimsey <david@wimsey.us> To: Freddie Cash <fjwcash@gmail.com> Cc: freebsd-fs@freebsd.org Subject: Re: Deadlock on zfs import Message-ID: <99965AED-8B44-49F7-9EF0-2CD16DB2EEC9@wimsey.us> In-Reply-To: <CAOjFWZ45jLDahejzNSy8qHP=eVNR-oNBqXc56c5x12XODm8CYg@mail.gmail.com> References: <074F3CC1-E29F-4552-840F-A38FDDCC7E76@wimsey.us> <CAOjFWZ45jLDahejzNSy8qHP=eVNR-oNBqXc56c5x12XODm8CYg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@gmail.com> wrote: > If you boot to single-user mode, disable the auto-import of pools > (zfs_enable=3Dno 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)? >=20 > 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). >=20 > If that's the case, the only solution I've found is to stick more RAM > into the box. >=20 > 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). >=20 > --=20 > Freddie Cash > fjwcash@gmail.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99965AED-8B44-49F7-9EF0-2CD16DB2EEC9>