Can't remove directory when over quota

[Matthew Ahrens]

Why does making a snapshot cause the problem still on build 36?

Having a snapshot causes a problem because of the details of how we
implement file (and directory) deletion in ZFS. In particular, we might
have to put the file (or directory) onto an on-disk "delete queue" for
later processing (eg. if the file is currently open). The delete queue
data structure *is* part of the snapshot, so we will end up using more
net space, at least temporarily. Currently, we use the delete queue
even when it is not strictly necessary, like in 'rmdir' case that you
are testing, causing this unexpected behavior.

You should note that even with no snapshots, you will not be able to
rmdir a directory on a full filesystem if that filesystem is in a
multi-block[*] directory. In multi-block directories, it is nontrivial
to determine which blocks will need to be modified to record the removal
of a given directory entry, so we don't currently attempt that.

In general, once you are out of space (due to a quota or pool-wide space
exaustion), you can only remove files that are larger than some minimum
size. Smaller files and metadata operations will fail because we make
some overly-conservative estimates of the amount of space that will be
needed.

We're working on these problems. The excessive delete queue usage, and a
great number of these estimates will be tightened down as part of bug id
6362156, which is expected to be fixed in the next few months.

--matt

[*] Multi-block directories are implemented using the "fat ZAP" (as
opposed to the "micro ZAP" which uses only a single block). The fat zap
will be used if there are more than 2000 directory entries, or if any
entry name is longer than 49 bytes.

[Matthew Ahrens]

Post by Matthew Ahrens

Why does making a snapshot cause the problem still on build 36?
# zfs create tank/t2
# zfs set quota=100k tank/t2
# cd /tank/t2
# perl -e 'for (1..10000) { mkdir "$_"; }'

Having a snapshot causes a problem because of the details of how we
implement file (and directory) deletion in ZFS. In particular, we might
have to put the file (or directory) onto an on-disk "delete queue" for
later processing

Actually, I just noticed that in your particular test case, we will also
have to modify the filesystem's root directory's link count when you do
the 'rmdir'. Since the root directory is part of the snapshot, this
will result in a net increase in the amount of space used.

Since your particular test does in fact use more space after the 'rmdir'
(and this is not due to an unnecessary artifact of ZFS's implementaion),
it is correct for it to fail.

To isolate the delete queue problem, you can populate a subdirectory of
the filesystem's root directory:

# zfs create tank/t2
# zfs set quota=100k tank/t2
# zfs snapshot foo/***@snap1
# mkdir /tank/t2/dir
# cd /tank/t2/dir
# perl -e 'for (1..10000) { mkdir "$_"; }'

--matt