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>