Garret Fields also specified some test and the result of those test were as specified here.
I used Ubuntu 19.10 and FreeBSD 12.1. I detected the issue running FreeBSD 12.0. Both system have the large-dnode feature active! Weekly I do send the data with the param -c, there is however one uncompressed dataset, that is sent without -c. And the following combinations work, Correct Local transfers: - freeBSD 12.1 (dnodesize=legacy) to freeBSD 12.1 (dnodesize=legacy) - freeBSD 12.1 (dnodesize=legacy) to freeBSD 12.1 (dnodesize=auto) - Ubuntu to Ubuntu, with and without -c I do not remember any problem. Correct Remote transfers: - freeBSD 12.1 (dnodesize=legacy) to Ubuntu (dnodesize=auto) - Ubuntu (dnodesize=legacy) to Laptop-Ubuntu (dnodesize=legacy), with and without -c - Ubuntu (dnodesize=legacy) to FreeBSD 12.x (dnodesize=legacy), with and without -c The last two I do use weekly! Failing transfers: - Ubuntu 19.10 (dnodesize=auto) to FreeBSD 12.x (dnodesize=legacy) - Ubuntu 19.10 (dnodesize=auto) to FreeBSD 12.1 (dnodesize=auto) Note that during the transfers, I do see, that the dataset is growing in size, while using zfs list or Conky in FreeBSD (using zfs list). At the end of the transfer, sometimes after hours or minutes I get the error message and the dataset disappears :( The settings selected as default by both development teams in spendlid isolation, do not work! The one from Ubuntu 19.10 (dnodesize=auto) to FreeBSD 12.x (dnodesize=legacy) This is the relevant information you can get out of me. Time to get somebody involved, who knows the corresponding program code. In the past I solved bugs, having with less information available. Like I said: GOOD LUCK in solving the bug. On Thu, 2020-01-30 at 05:53 +0000, Richard Laager wrote: > In terms of a compact reproducer, does this work: > > # Create a temp pool with large_dnode enabled: > truncate -s 1G lp1854982.img > sudo zpool create -d -o feature@large_dnode=enabled lp1854982 > $(pwd)/lp1854982.img > > # Create a dataset with dnodesize=auto > sudo zfs create -o dnodesize=auto lp1854982/ldn > > # Create a send stream > sudo zfs snapshot lp1854982/ldn@snap > sudo zfs send lp1854982/ldn@snap > lp1854982-ldn.zfs > > sudo zpool export lp1854982 > > cat lp1854982-ldn.zfs | ssh 192.168.1.100 zfs receive zroot/ldn > > If that doesn't reproduce the problem, adjust it until it does. You > were > using `zfs send -c`, so maybe that's it. You may need to enable more > pool features, etc. > > But if this can be reproduced with an empty dataset on an empty pool, > the send stream file is 8.5K (and far less compressed). Attach the > script for reference and the send stream to a FreeBSD bug. > -- 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/1854982 Title: Lost compatibilty for backup between Ubuntu 19.10 and FreeBSD 12.0 Status in zfs-linux package in Ubuntu: New Bug description: After I tried to back-up my datapools from Ubuntu 19.10 to FreeBSD 12.0 as I have done since June each week, I found out it did not work anymore. The regression occurred after I reinstalled Ubuntu on my new nvme drive. I also had to reorganize my own datapools/datasets, because they either moved to the nvme drive or they had to be located on 2 HDDs instead of 3. I had one datapool that still works, the datapool containing my archives and it is the datapool, that has NOT been reorganized. I tried for a whole long day to get the backup working again, but I failed. I compared the properties from datapool and dataset, but did not see any problem there. Only a lot of new features and properties not present before and not present in FreeBSD. I used FreeBSD, because I use for backup an old 32-bits Pentium. I have two complaints: - the Ubuntu upgrade did cost me the compatibility with FreeBSD. Open-ZFS? :( - the system transfers the dataset and at the end of a long transfer it decides to quit and the error messages are completely useless and self contradicting. On the first try it say the dataset does exist and on the second try it says it does NOT exist. One of the two is completely wrong. Some consistency and some clearer error messages would be helpful for the user. See the following set of strange set error messages on two tries: root@VM-Host-Ryzen:/home/bertadmin# /sbin/zfs send -c dpool/dummy@191130 | ssh 192.168.1.100 zfs receive zroot/hp-data/dummy cannot receive new filesystem stream: destination 'zroot/hp-data/dummy' exists must specify -F to overwrite it root@VM-Host-Ryzen:/home/bertadmin# /sbin/zfs send -c dpool/dummy@191130 | ssh 192.168.1.100 zfs receive -F zroot/hp-data/dummy cannot receive new filesystem stream: dataset does not exist A 2nd subset of my backup is stored on the laptop and that still works. I also compared the properties with those of my laptop, that still has its original datapools of begin of the year. I aligned the properties of FreeBSD with those of my laptop, but it did not help. I attach the properties of the datapool and dataset from both FreeBSD and Ubuntu. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: zfsutils-linux 0.8.1-1ubuntu14.1 ProcVersionSignature: Ubuntu 5.3.0-23.25-generic 5.3.7 Uname: Linux 5.3.0-23-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu8.2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Dec 3 13:35:08 2019 InstallationDate: Installed on 2019-11-30 (3 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) SourcePackage: zfs-linux UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.sudoers.d.zfs: [inaccessible: [Errno 13] Permission denied: '/etc/sudoers.d/zfs'] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1854982/+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
