ZFS server has gone crazy slow

Andriy Gapon avg at FreeBSD.org
Sun Apr 12 11:26:25 UTC 2020


On 12/04/2020 00:24, Peter Eriksson wrote:
> Another fun thing that might happen is if you reboot your server and happen
> to have a lot of queued up writes in the ZIL (for example if you did a “zfs
> destroy -d -r POOL at snapshots” (deferred(background) destroys of snapshots)
> and do a hard reboot while it’s busy it will “write out” those queued
> transactions at filesystem mount time during the boot sequence

Just nitpicking on two bits of incorrect information here.
First, zfs destroy never uses ZIL.  Never.  ZIL is used only for ZPL operations
like file writes, renames, removes, etc.  The things that you can do with Posix
system calls (~ VFS KPI).

Second, zfs destroy -d is not a background destroy.  It is a deferred destroy.
That means that either the destroy is done immediately if a snapshot has no
holds which means no user holds and no clones.  Or the destroy is postponed
until holds are gone, that is, the last clone or the last user hold is removed.

Note, however, that unless you have a very ancient pool version destroying a
snapshot means that the snapshot object is removed and all blocks belonging to
the snapshot are queued for freeing.  Their actual freeing is done
asynchronously ("in background") and can be spread over multiple TXG periods.
That's done regardless of whether -d was used.

-- 
Andriy Gapon


More information about the freebsd-fs mailing list