Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prevent ZFS leaking pool free space #2896

Closed
wants to merge 1 commit into from

Conversation

dweeezil
Copy link
Contributor

When processing async destroys ZFS would leak space every txg timeout
(5 seconds by default), if no writes occurred, until the pool is totally
full. At this point it would be unfixable without a pool recreation.

In addition if the machine was rebooted with the pool in this situation
would fail to import on boot, hanging indefinitely, as the import process
requires the ability to write data to the pool. Any attempts to query
the pool status during the hung import would not return as the import
holds the pool lock.

The only way to import such a pool would be to specify -o readonly=on
to the zpool import.

zdb -bb can be used to check for "deferred free" size which is
where this lost space will be counted.

Ported by: Tim Chase tim@chase2k.com

References:
freebsd/freebsd-src@48431b7
http://svnweb.freebsd.org/base?view=revision&revision=273158

When processing async destroys ZFS would leak space every txg timeout
(5 seconds by default), if no writes occurred, until the pool is totally
full. At this point it would be unfixable without a pool recreation.

In addition if the machine was rebooted with the pool in this situation
would fail to import on boot, hanging indefinitely, as the import process
requires the ability to write data to the pool. Any attempts to query
the pool status during the hung import would not return as the import
holds the pool lock.

The only way to import such a pool would be to specify -o readonly=on
to the zpool import.

zdb -bb <pool> can be used to check for "deferred free" size which is
where this lost space will be counted.

Ported by:	Tim Chase <tim@chase2k.com>

References:
    freebsd/freebsd-src@48431b7
    http://svnweb.freebsd.org/base?view=revision&revision=273158
@dweeezil
Copy link
Contributor Author

I came across this awhile ago and have been meaning to post it for some feedback as a pull request.

@behlendorf
Copy link
Contributor

@ahrens could you comment on this recent bug fix from freebsd.

@behlendorf behlendorf added this to the 0.6.4 milestone Nov 14, 2014
@ahrens
Copy link
Member

ahrens commented Nov 15, 2014

@behlendorf The fix in FreeBSD is correct. I have a more comprehensive change in this area coming to illumos. These changes are out for review: https://reviews.csiden.org/r/132/

@behlendorf
Copy link
Contributor

@ahrens Thanks for the review. For the moment we've picked up the FreeBSD fix, we'll replace it with the more comprehensive fix once it's ready.

ryao pushed a commit to ryao/zfs that referenced this pull request Nov 29, 2014
When processing async destroys ZFS would leak space every txg timeout
(5 seconds by default), if no writes occurred, until the pool is totally
full. At this point it would be unfixable without a pool recreation.

In addition if the machine was rebooted with the pool in this situation
would fail to import on boot, hanging indefinitely, as the import process
requires the ability to write data to the pool. Any attempts to query
the pool status during the hung import would not return as the import
holds the pool lock.

The only way to import such a pool would be to specify -o readonly=on
to the zpool import.

zdb -bb <pool> can be used to check for "deferred free" size which is
where this lost space will be counted.

References:
  freebsd/freebsd-src@48431b7
  http://svnweb.freebsd.org/base?view=revision&revision=273158
  https://reviews.csiden.org/r/132/

Porting notes:

This issue was filed as illumos 5347 and a more comprehensive fix is
under review.  Once that change is finalized it will be integrated, in
the meanwhile the FreeBSD fix has been merged to prevent the issue.

Ported by: Tim Chase <tim@chase2k.com>
Signed-off-by: Matthew Ahrens mahrens@delphix.com
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes openzfs#2896
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants