zfs destroy failure due to a long hold should return a more descriptive error message #14538
Description
Describe the feature would like to see added to OpenZFS
Today in #openzfs on the libera IRC network, a user thought his pool was corrupt because he could not destroy snapshots. It turned out that zfs_autobackup had set a hold on the snapshot he wanted to destroy and the error message simply said that the dataset is busy.
How will this feature improve OpenZFS?
Having an error message that tells users that a hold caused a destroy to fail would prevent users from thinking they have encountered a bug.
Additional context
An example session that shows the poor error message:
richard@vserver ~/zfs $ sudo zfs snapshot rpool@test
richard@vserver ~/zfs $ sudo zfs hold example rpool@test
richard@vserver ~/zfs $ sudo zfs destroy rpool@test
cannot destroy snapshot rpool@test: dataset is busy
richard@vserver ~/zfs $ sudo zfs release example rpool@test
richard@vserver ~/zfs $ sudo zfs destroy rpool@test
Changing the tool to pass a different error code than EBUSY to tell the tools to print a different error message would make sense, but if the userland tools and kernel are out of sync, then the tools could hit a VERIFY() due to the unknown error code. Changing the tools to check for a hold following EBUSY might be better. That said, this requires more thought, so I am filing an issue for me or someone else to tackle in the future rather than a PR.