files sometimes can't be removed from a full filesystem
In some full filesystems, "rm" of even small files works just fine. But in
other full filesystems, "rm" even of large files can fail with ENOSPC.
The problem occurs when the unlinked ZAP object (which contains the list of
files which have a link count of zero but which haven't been removed from disk
yet, e.g. because the file is still open) is a fat ZAP (because at some point
it had more than ~2000 entries). In this case, our space estimation
(dmu_tx_hold_zap()) doesn't determine exactly which blocks of the fat zap will
be modified, so it has to assume that those blocks might be part of a snapshot,
and therefore won't be freed.
The space estimation code is fairly fragile, so a robust solution is to
explicitly mark file removal transactions as "presumed to result in a net free
of space". This would let them ignore refquotas, and use half of the pool
space overhead (dsl_pool_adjustedsize()).
The problem can be seen when the estimated space to "alloc" is more than the
estimated space to "free", as shown by the following dtrace command:
Updated by Electric Monk about 8 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
commit 4bb73804952172060c9efb163b89c17f56804fe8 Author: Matthew Ahrens <firstname.lastname@example.org> Date: 2014-07-07T19:49:36.000Z 4950 files sometimes can't be removed from a full filesystem Reviewed by: Adam Leventhal <email@example.com> Reviewed by: George Wilson <firstname.lastname@example.org> Reviewed by: Sebastien Roy <email@example.com> Reviewed by: Boris Protopopov <firstname.lastname@example.org> Approved by: Dan McDonald <email@example.com>