6

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

1
  • 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: mattzone.com/zfsonlinux/zfsonlinux_20141225.html
    – Henk Poley
    Sep 17, 2019 at 7:16

1 Answer 1

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.

4
  • 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, 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.
    – Henk Poley
    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.
    – shodanshok
    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.
    – Henk Poley
    Sep 1, 2020 at 7:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .