zfs-recv can be broken by some ZFS-ioctls
zfs - Zettabyte File System
#6874 introduced the regression
From the illumos-list:
Hi. We found that ZFS_IOC_USERSPACE_MANY breaks final-stage of zfs-recv where ZFS does clone-swap. "6874 rollback and receive need to reset ZPL state to what's on disk" introduces some changes that causes the behavior. ZFS_IOC_USERSPACE_MANY -> zfs_ioc_userspace_many() -> zfsvfs_hold() -> zfsvfs_create() -> ... -> dsl_dataset_long_hold() dsl_dataset_clone_swap_check_impl() -> dsl_dataset_handoff_check() -> EBUSY if there are long holds This affect only non-mounted FS.
I think your analysis is correct. There are a few other places where we also abuse the long hold if the fs is not mounted: zfs_ioc_userspace_one, zfs_prop_set_special(VERSION or userquota). These are abuses of the long-hold mechanism because they aren't really holding for a long time. We would rather that the receive code wait for them to complete. I assume that "breaks" here means that the receive can fail if you do a concurrent "zfs userspace" (or other ZFS_IOC_USERSPACE* ioctl). That definitely seems like undesirable behavior. Could you file a bug? But FYI, I'm not sure when I personally will be able to get to it. --matt