Hello all,

Hope everyone is well and safe.

This is a plea to push along the resolution of this bug.

I'm heavily invested in zfs and this has been a huge problem for me.

Just like TimK I'm a sanoid/syncoid user and have seen the zfs recv
problem.  Changing syncoid's perl to not use "-s" worked for me. But
thats not been an end to my problems.

Originally I thought I had "lost" my main 10TB zpool for e.g hardware
reasons, but its not proved simple as that. I can import and read from
the zpool but see zfs timeouts regularly in syslog. If I try to write
to this pool it hangs. zfs list hangs as well. Eventually zfs seems
completely "stopped" and I have to reboot.

Assuming my "tank" was trashed, I had been using my (syncoid) backups
to reestablish my files in a new zfs pool on new hardware. Which
worked fine (+1 syncoid).

I've been trying to reestablish backups for my new pool/hardware this
morning and find whereas I can zfs send a 4.8GB snapshot ok, I can not
send a 7.2GB (or larger) snapshots - I get the rather anodyne message
"Input/output error".

I have also seen hangs when trying to zfs destroy snapshots on one of
my other pools. Whether the hanging destroy is the root cause or just
a casualty of other zfs stuff going on, I've no information.

I realise that relating the generally instability of my system is
pretty vague: its proving hard to pick apart the problems and
demonstrate repeatable effects.

So I'm eager to try the proposed fix but, as Jason has said, there is
no amd64 version yet in focal-proposed.

Can I encourage you to make the fix available please?

Really appreciate everybody's effort.

Thanks in advance.

-- 
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