The bugfix has been working as expected over the past 3 days on my 2
systems:

Intel NUC (kernel 5.11.0-37-generic)
GCP Instance (kernel 5.11.0-1020-gcp)

None of my syncoid jobs have failed, I am no longer using the --no-
resume (-s) flag as a workaround.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to zfs-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1939177

Title:
  Ubuntu 20.04.2 LTS kernel 5.11.0-25 zfs send | receive broken

Status in zfs-linux package in Ubuntu:
  Confirmed
Status in zfs-linux source package in Focal:
  Fix Committed

Bug description:
  == SRU Justification Focal ==

  [Impact]

  https://github.com/openzfs/zfs/issues/12462

  Ubuntu 20.04.2 LTS
  Kernel: 5.11.0-25-generic #27~20.04.1-Ubuntu
  zfs-0.8.3-1ubuntu12.12
  zfs-kmod-2.0.2-1ubuntu5

  Trying to run zfs send | receive and getting an error:

  # zfs send  'rpool/home'@'autosnap_2020-08-01_00:59:01_monthly' | zfs receive 
 -s -F 'nas/rpool_backup/home'
  cannot receive: failed to read from stream
  cannot receive new filesystem stream: dataset does not exist

  This used to work before the recent Ubuntu kernel update from 5.8 to 5.11
  Kernel 5.8 came with zfs-kmod-0.8.4-1ubuntu11.2

  Ubuntu updates that broke it:

  Upgrade: linux-headers-generic-hwe-20.04:amd64 (5.8.0.63.71~20.04.45, 
5.11.0.25.27~20.04.10), linux-
  image-generic-hwe-20.04:amd64 (5.8.0.63.71~20.04.45, 5.11.0.25.27~20.04.10), 
linux-generic-hwe-20.04
  :amd64 (5.8.0.63.71~20.04.45, 5.11.0.25.27~20.04.10)

  Sending the zfs send part to a file works, but then sending the file
  to zfs receive also fails. The dump file size seems reasonable but the
  contents may not be correct.

  [Test Plan]

  1. create test pool and backup pool

  sudo zpool create pool /dev/vdb1
  sudo zpool create backup  /dev/vdc1

  2. populate pool with some files and create some snapshots

  sudo  zfs snapshot pool@now1

  create some more files etc, make another snapshot

  sudo  zfs snapshot pool@now2

  3. perform send/recv using -s option:

  sudo zfs send pool@now1 | sudo zfs receive -vFs backup
  sudo zfs send -i pool@now1 pool@now2 | sudo zfs receive -vFs backup

  Without the fix, the -s option on the receive fails. With the fix it
  works fine.  Test with focal 5.4 and 5.11 kernel to exercise 0.8.x and
  2.x kernel ZFS drivers.

  [Where problems could occur]

  The main fix nullifies the deprecated  action_handle option so that
  it's not checked, this allows 0.8.x userspace it to be forwardly
  compatible with 2.x kernel ZFS and also since it is deprecated in
  0.8.x it makes not difference to the 0.8.x kernel ZFS driver. Thus the
  risk with patch action_handle is very small.

  Included in the fix is a send/recv upstream bug fix 
4910-Fix-EIO-after-resuming-receive-of-new-dataset-over-a.patch that makes 
send/recv more resilient by making  zfs receive to always unmount and remount 
the
  destination, regardless of whether the stream is a new stream or a
  resumed stream.  The change is upstream for ~10 months and has minimal impact 
on current recv functionality.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1939177/+subscriptions


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to