b333z/zfs — comment on commit 2d69db27f9f459d4205050899589893dee4564bc
File:  line 0
By b333z:

On Feb 8, 2012 9:09 AM, "Brian Behlendorf" <
reply@reply.github.com>
wrote:
>
> Thanks for running down the root cause on this. I think a slightly
cleaner fix would be just to check for ENOENT as a safe return code from
`zfs_unmount_snap()` in `dsl_dataset_user_release_one()`. This was the
ENOENT behavior is preserved for all other callers which might need to know
why an unmount failed. I'll roll this change in to an updated snapshot
patch.
>
> ---
> Reply to this email directly or view it on GitHub:
>
https://github.com/b333z/zfs/commit/2d69db27f9f459d4205050899589893dee4564bc#commitcomment-942984

No worries sounds good, I did start with that change but I pushed it down
into zfs_umount_snap because the change above fixes the temp snapshot
destroy in the diff, but think deleting a snapshot using zfs destroy and
getting dataset not found comes from a different caller that also not setup
to deal with ENOENT from zfs_unmount_snap, so we might need to identify
that caller as well.

Do you know the path zfs destroy would take? I put a print_backtrace in the
stap script I was using in the zfs_unmount_snap but it didn't seem to make
sense and then I ran out of time and went on hol's...