illumos gate

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:

dtrace -n 'dsl_dir_tempreserve_space:entry{printf("alloc=%uK free=%uK",
args²>>10, args³>>10)}' -c 'rm f'