6

Or can reads, and preferably writes, that are outside the snapshot (basically everything) still progress?

Henk Poley
  • 165
  • 3
    This 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: http://www.mattzone.com/zfsonlinux/zfsonlinux_20141225.html – Henk Poley Sep 17 '19 at 07:16

1 Answers1

7

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.

Paul Tobias
  • 770
shodanshok
  • 50,565
  • 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. – Henk Poley Sep 17 '19 at 07: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. – Henk Poley Sep 17 '19 at 07:39
  • 3
    @HenkPoley if you are using a proprietary storage appliance, be sure to poke your storage vendor before changing tunables. – shodanshok Sep 17 '19 at 08: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. – Henk Poley Sep 01 '20 at 07:40