If "zfs send" gets interrupted the destination dataset will be left in a mounted, accessible state. However, after resuming the transfer (with zfs send -t) the destination dataset will be left in a mounted by inaccessible state, returning EIO for all accesses. Unmounting and remounting it suffices to fix the problem. Steps to reproduce: $ cd / $ sudo zpool create testpool vtbd1 $ sudo zfs create testpool/src $ sudo zfs create testpool/dst $ sudo dd if=/dev/zero bs=1m count=2048 of=/testpool/src/zerofile 2048+0 records in 2048+0 records out 2147483648 bytes transferred in 8.584807 secs (250149331 bytes/sec) $ sudo zfs snapshot testpool/src@1 $ sudo zfs send -v testpool/src@1 | sudo zfs recv -Fsv testpool/dst full send of testpool/src@1 estimated size is 2.00G total estimated size is 2.00G full send of testpool/src@1 estimated size is 2.00G TIME SENT SNAPSHOT receiving full stream of testpool/src@1 into testpool/dst@1 10:31:19 83.3M testpool/src@1 10:31:20 479M testpool/src@1 10:31:21 479M testpool/src@1 cannot receive new filesystem stream: checksum mismatch or incomplete stream. Partially received snapshot is saved. A resuming stream can be generated on the sending system by running: zfs send -t 1-bfb9f6182-b8-789c636064000310a500c4ec50360710e72765a52697303030419460caa7a515a7968064441461f26c48f2499525a9c540fa82b9962236fd25f9e9a599290c0cd71e84f16f0ff8705d03499e132c9f97989b0aa4538b4b0af2f373f48b8b921d0c216e010068421904 fish: Process 37889, 'sudo' 'sudo zfs send -v testpool/src@1…' terminated by signal SIGTERM (Polite quit request) # (In another terminal) $ sudo pkill -f "zfs send -v testpool/src@1" # (Back in the original terminal) $ ls -a testpool/dst ./ ../ $ zfs get mounted testpool/dst NAME PROPERTY VALUE SOURCE testpool/dst mounted yes $ sudo zfs send -t 1-bfb9f6182b8-789c636064000310a500c4ec50360710e72765a52697303030419460caa7a515a7968064441461f26c48f2499525a9c540fa82b9962236fd25f9e9a599290c0cd71e84f16f0ff8705d03499e132c9f97989b0aa4538b4b0af2f373f48b8b921d0c216e010068421904 | sudo zfs recv -Fsv testpool/dst $ ls -a testpool/dst ls: testpool/dst: Input/output error $ zfs get mounted testpool/dst NAME PROPERTY VALUE SOURCE testpool/dst mounted yes - $ sudo zfs unmount testpool/dst && sudo zfs mount testpool/dst $ ls -a testpool/dst ./ ../ zerofile
A commit references this bug: Author: asomers Date: Thu Aug 20 01:31:22 UTC 2020 New revision: 364412 URL: https://svnweb.freebsd.org/changeset/base/364412 Log: zfs: fix EIO accessing dataset after resuming interrupted receive ZFS unmounts a dataset while receiving into it and remounts it afterwards. But if ZFS is resuming an incomplete receive, it screws up and ends up with a dataset that is mounted, but returns EIO for every access. This commit fixes that condition. While the vulnerable code also exists in OpenZFS, the problem is not reproducible there. Apparently OpenZFS doesn't unmount the destination dataset during receive, like FreeBSD does. PR: 248606 Reviewed by: mmacy MFC after: 2 weeks Sponsored by: Axcient Differential Revision: https://reviews.freebsd.org/D26034 Changes: head/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c
A commit references this bug: Author: asomers Date: Sun Aug 30 16:27:58 UTC 2020 New revision: 364974 URL: https://svnweb.freebsd.org/changeset/base/364974 Log: MFC r364412: zfs: fix EIO accessing dataset after resuming interrupted receive ZFS unmounts a dataset while receiving into it and remounts it afterwards. But if ZFS is resuming an incomplete receive, it screws up and ends up with a dataset that is mounted, but returns EIO for every access. This commit fixes that condition. While the vulnerable code also exists in OpenZFS, the problem is not reproducible there. Apparently OpenZFS doesn't unmount the destination dataset during receive, like FreeBSD does. PR: 248606 Reviewed by: mmacy Sponsored by: Axcient Differential Revision: https://reviews.freebsd.org/D26034 Changes: _U stable/12/ stable/12/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c
A commit references this bug: Author: asomers Date: Sun Aug 30 18:21:54 UTC 2020 New revision: 364978 URL: https://svnweb.freebsd.org/changeset/base/364978 Log: MFC r364412: zfs: fix EIO accessing dataset after resuming interrupted receive ZFS unmounts a dataset while receiving into it and remounts it afterwards. But if ZFS is resuming an incomplete receive, it screws up and ends up with a dataset that is mounted, but returns EIO for every access. This commit fixes that condition. While the vulnerable code also exists in OpenZFS, the problem is not reproducible there. Apparently OpenZFS doesn't unmount the destination dataset during receive, like FreeBSD does. PR: 248606 Reviewed by: mmacy Sponsored by: Axcient Differential Revision: https://reviews.freebsd.org/D26034 Changes: _U stable/11/ stable/11/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c
Reopening because this bug has returned on head, thanks to the OpenZFS import.
Fixed by r366780, which imported upstream's 4673ab21b860e3580789539ba14a25206c0ba589 .