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