Bug #1105


zpool import should report if it is going to take forever, or do background tasks after import

Added by Jim Klimov about 11 years ago. Updated about 11 years ago.

Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:


As conveyed in my bug #956, some of my OpenSolaris Forum posts and recent mail-list activity (links below), my "zpool import" on oi_148a often takes very long to complete, presumably due to going through deferred-free blocks on a deduped pool. As Garrett said, DDT takes a prodigous amount of RAM.

In fact, after a while the system runs out of RAM regardles of configured swap areas, and hangs in an infinite loop of high scan rates (there are no free pages to find anyway - kernel holds them all and does not release, I guess). Also any zfs-related programs spawned after the import attempt, hang.

While fixing the core problem may be long or complicated (and deserves another bugfix request), I believe that at some point the import attempt can determine if it has some maintenance to do - and at least report this via the zpool command, that it may take an undetermined amount of time to complete.

Alternatively, in case of deferred-free at least, the import should succeed quickly and then the defereed-free list processing can go in the background, not unlike scrub, resilver, etc.

Also the ongoing import attempt should not stall whatever low-level calls are used in "zfs", "zpool", "df" and "bootadm" commands which currently (oi_148a) freeze during the import and become unkillable.

Links to external detailed info:
Actions #1

Updated by Jim Klimov about 11 years ago

I have kept closer watch on my system now - after a couple of hours of disk thrashing with both reads and writes to the physical "pool", my "dcpool" is reported as imported by kernel, and I can even "df -k" it. I see in iostat that there's lots of ongoing IO, and with df I see that over time some free space is reclaimed. Now I am not sure what is being written to "pool" before the "dcpool" is reported as imported, and whether any deferred frees are processed before this reporting.

However for several first times the system crashed without reporting that the pool became imported, and according to zdb I think I still had some reduction in deferred-free counts.

So the part about background processing of deferred-free blocks after the pool import is already in place, at least somewhat.

Now, the import itself should preferably complete faster (or warn that it is going to take long - and not lock up other zfs-related tools), and processing of this import and of deferred deletes should not crash the system (for that RFE see bug #1106).


Also available in: Atom PDF