Date: Tue, 31 Jul 2012 08:31:33 -0700 From: Freddie Cash <fjwcash@gmail.com> To: =?UTF-8?Q?Karli_Sj=C3=B6berg?= <Karli.Sjoberg@slu.se> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: Hang when importing pool Message-ID: <CAOjFWZ52XvMO%2BA7cwa3fnkJcXMCbGgWD91gvZsmW8Navh0AZ9A@mail.gmail.com> In-Reply-To: <D13A3EA7-B229-4B78-915E-A3CC3162DB8A@slu.se> References: <D13A3EA7-B229-4B78-915E-A3CC3162DB8A@slu.se>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 30, 2012 at 11:31 PM, Karli Sjöberg <Karli.Sjoberg@slu.se> wrote: > I´m really struggling with this. I have had a pool with imported filesystems from a Solaris system that had dedup activated. Then, when the time came to erase them, it just stalled. When rebooting, it stalled again at mounting filesystems, and since then, I´ve installed two USB drives to act as root pool with FreeBSD-9.0-RELEASE so that I could import the original pool in recovery, but it always stalls after a couple of hours. Looking at top, I could see that the 16GB RAM was maxed out, so I have heavily tuned down kmem, arc, etc: You're running out of RAM during the import, as it loads the DDT. Stuff a bunch more RAM into the machine (32 GB, 48 GB, even 64 GB). Then you will be able to load the full DDT into RAM, finish the aborted destroy process, and import the pool. We've run into this three or four times now on systems with dedupe enabled and only 16 GB of RAM. We've since upgraded all our boxes to a minimum of 32 GB, with one having 64 GB. ZFS dataset destruction with dedupe enabled takes *a lot* of time and RAM, as the DDT needs to be updated for every block freed. And rebooting in the middle of a "zfs destroy" operation means that the operation needs to finish at pool import time. -- Freddie Cash fjwcash@gmail.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOjFWZ52XvMO%2BA7cwa3fnkJcXMCbGgWD91gvZsmW8Navh0AZ9A>