Or can reads, and preferably writes, that are outside the snapshot (basically everything) still progress?
-
3This seems to be a comment in favor of Linux ZFS implementation: "the biggest differences between solaris ZFS (v28) and OpenZFS (Linux) is LZ4 compression as an alternative [and better] algorithm, and that 'zfs destroy' isn't the slow and blocking operation it once was". From December 2014: mattzone.com/zfsonlinux/zfsonlinux_20141225.html– Henk PoleySep 17, 2019 at 7:16
1 Answer
In short: no, a zfs destroy
will not block normal IO on recent (circa post-2013) ZFS versions.
Additional details: since many years, ZFS supports a features called "async destroy" which runs in a background thread without blocking normal IO. From zpool man page:
freeing After a file system or snapshot is destroyed, the space it was using is returned to the pool asynchronously. freeing is the amount of space remaining to be reclaimed. Over time freeing will decrease while free increases.
Sure you can see a slight drop in IO performance, but it should be quite tolerable; moreover, there are tunables to adapt it to your requirements.
-
Thanks for the comment :). We're seeing 30 second hick-ups after snapshot destroys, that in turn panic the NFS/CIFS daemon, that panic Windows Servers relying on it. I suspect that our storage platform should give some back-pressure, so it doesn't get 30 seconds worth of delete commands from ZFS in one go. Sep 17, 2019 at 7:35
-
I guess the
zfs_per_txg_dirty_frees_percent
tunable will do ZFS side throttling. Thanks for the hint, I'll discuss it with our sysadmin. Sep 17, 2019 at 7:39 -
3@HenkPoley if you are using a proprietary storage appliance, be sure to poke your storage vendor before changing tunables. Sep 17, 2019 at 8:32
-
I believe in the end we mostly 'resolved' this by upgrading from an older NFS (v2?) protocol to NFSv4, which has better locking that doesn't degenerate into looonnnnggg lock acquire times as often. Not sure if the underlying issue that
zfs destroy
caused is actually resolved, but at least the Windows servers seem happy now that they don't frequently need to wait that long. Sep 1, 2020 at 7:40