Bug 248606 - zfs receive: Input/output error accessing dataset after resuming interrupted receive
Summary: zfs receive: Input/output error accessing dataset after resuming interrupted ...
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-fs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-08-11 16:36 UTC by Alan Somers
Modified: 2020-10-29 08:07 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alan Somers freebsd_committer 2020-08-11 16:36:39 UTC
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
Comment 1 commit-hook freebsd_committer 2020-08-20 01:31:36 UTC
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
Comment 2 commit-hook freebsd_committer 2020-08-30 16:28:16 UTC
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
Comment 3 commit-hook freebsd_committer 2020-08-30 18:22:37 UTC
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
Comment 4 Alan Somers freebsd_committer 2020-09-24 23:30:29 UTC
Reopening because this bug has returned on head, thanks to the OpenZFS import.