destroying a snapshot does not attempt unmount

[nedbass]

The 'zfs destroy' command fails to destroy a snapshot if the snapshot is mounted, but still returns a successful error code. I believe it should attempt to unmount the snapshot and return a 'dataset busy' or similar error if the unmount fails.

To reproduce:

$ zpool create tank /tmp/tank
$ zfs snap tank@a
$ mount -t zfs tank@a /mnt
$ zfs destroy tank@a # returns success
$ zfs list -t snapshot
NAME     USED  AVAIL  REFER  MOUNTPOINT
tank@a      0      -    30K  -

Similarly, recursively destroying a dataset or pool fails if it has a mounted snapshot.

[behlendorf]

Nice find. That cleanly explains why it would fail but not why no error was being logged. It looks like the error code should be returned by the ioctl().

[nedbass]

I found that I got a 'dataset busy' error when destroying a mounted snapshot with the latest master, but not with rc13. Not sure which commit improved the error reporting. At first I suspected it was 761394b but I tried reverting it and still got the (expected) error.

[behlendorf]

Hmm, it might have been addressed in the feature flags patches in particular the async destroy feature. Anyway, your fix is clearly right I'll get it merged.

[behlendorf]

94a9bb4 Fix quoting error in unmount command

[nedbass]

Yes is was fixed by 9ae529e, in particular this line

9ae529#L51L941

removed a redeclaration of err inside the for loop, effectively discarding the return value of dsl_dataset_own() which is where the EBUSY error originates.

While investigating this I noticed that zfs_ioc_destroy_snaps_nvl() discards the return value of zfs_unmount_snap(), which is why the umount syntax error wasn't propagated back to the ioctl() call.