Project

General

Profile

Feature #3428

zpool import -f zpoolname Time Remaining

Added by Matt Hollander almost 8 years ago. Updated almost 8 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Start date:
2012-12-23
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

Recently i experienced a strange issue where my power failed when I had issued a delete command to a zvol. Upon reboot I was unable to boot OI151a5 and was forced to roll back to a previous boot environment. The zpool was missing upon a zpool list. I then attempted to import the zpool using zpool import -f tank and the import has now taken close to 12 hours with consistent disk i/o. I've yet to have the zpool import.

Is there anyway to add a way to monitor the resulting time remaining for the import, or to check the status of whats going on outside of issueing a zdb -et poolname to find that the filesystem is busy?

#1

Updated by Jim Klimov almost 8 years ago

Did your deleted data use dedup? Does your box have little/moderate RAM (under tens or hundreds of gigabytes)? If both answers are "yes", then likely ZFS quickly marked the deleted blocks for post-processing, as in "Deferred Free Blocks". It now has to inquire for each block whether it was in DDT, decrease the entry's counter, and release the disk storage if the counter goes to 0. This is lots of small IOs which are very slow in HDDs (my pool took several weeks to become usable, being 100% busy with 3-5Mb/s of throughput all the time).

The process can also cause the kernel to deplete available RAM and hang (search my posts and bugtracker items with "scanrate hell" keywords, i.e. http://mail.opensolaris.org/pipermail/zfs-discuss/2011-June/048767.html), however ZFS continues to clean up the pool after the box is reset.

You can inquire the "Deferred Free" list size (and lots of other info) with a ZDB walk "zdb -bsvL -e poolname-or-guid", however it can take hours to complete. When this counter goes from millions to about 0, your pool should become usable.

This quest's resolution could be to devise a more civilized and quick and convenient way than a long ZDB walk to query such data - perhaps expose it as a kstat or a line in a verbose "zpool status"/"zpool import" info?

Also, since it may be known to ZFS and its authors, which tasks are to complete before the pool is presented to programs and users, some quantitative measure (N blocks of M total processed, N filesystems of M automounted, etc.) and/or a checklist of tasks (completed, doing now, will do soon) would be quite useful to end-users to estimate the pool import progress - even if without any useless promises about the time it should take. My scrubs do estimate time to completion, but can stay under "30 min to complete" for days ;)

#2

Updated by Anonymous almost 8 years ago

Box contains Intel Xeon E5530 with 16GB of RAM and Dedup was turn on but turned off a long time ago.

A side note, was able to import the pool as read only without the import hanging, between this and backups I had my data so I destroyed the pool. Needless to say I thought i might bring it up.

Also available in: Atom PDF