fix for 3740 changed behavior of zfs destroy/hold/release ioctl
In the fix for #3740 the behavior of the ZFS snapshot destruction, hold, and release IOCTLs from "ignore missing snapshots when determining the returned error (but returning ENOENT in the errlist for each missing snapshot)" to "ignore missing snapshots when determining the returned error, unless all snapshots are missing in which case ENOENT is returned". While the new behavior more closely matches what the 'zfs' command does it is not ideal for programmatic consumers and breaks existing consumers.
The goal of the old behavior was to avoid races with 'destroy' (a common case for any program that does not have a way to stop snapshots from being destroyed while it is building the list of snapshots to send in the IOCTL for example 'zfs destroy/hold/release -r'). Any consumer that cares about missing snapshots could check the returned 'errlist' for ENOENT. With the new code consumers that care about missing snapshots still need to check 'errlist' because a return code of 0 only means that at least one of the snapshots existed, while consumers that don't care about missing snapshots now need to explicitly ignore ENOENT.
The 'zfs' command line does want the "error if none of the snapshots exists" behavior, but implements it differently.
Updated by Matthew Ahrens over 7 years ago
This caused a bug in our product at Delphix. Here's a test case that will reproduce this, usually very quickly. The two destroys race; if they both determine that they need to destroy test@snap, then only one will succeed, as the other will see that it does not exist.
#!/bin/bash -x while true; do zfs create test/fs zfs snapshot -r test@snap zfs destroy -r test@snap & zfs destroy -r test/fs || exit 1 wait %1 || exit 1 done exit 0
Updated by Christopher Siden over 7 years ago
- Status changed from In Progress to Closed
commit bb6e707 Author: Matthew Ahrens <email@example.com> Date: Thu Jun 20 15:43:17 2013 3829 fix for 3740 changed behavior of zfs destroy/hold/release ioctl Reviewed by: Matt Amdur <firstname.lastname@example.org> Reviewed by: Christopher Siden <email@example.com> Approved by: Richard Lowe <firstname.lastname@example.org>