According to the overview of features on the OpenZFS website (see the link provided by Richard Laager in the bug-report), FreeBSD 12 does not support "large dnode". However FreeBSD did set the large dnode feature to "active" and it is still set to "active". But FreeBSD does not handle those send/receive streams correctly. It reads the stream builds up the dataset@snapshot and at the end after an hour or so, it gives the errormessage.
--------------------------------------------------------------- cannot receive new filesystem stream: destination 'zroot/hp-data/dummy' exists must specify -F to overwrite it ---------------------------------------------------------------- That dataset did exists, I can see it grow in size during that hour with "zfs list" but, when the transfer is completed, it gives that error message. I guess FreeBSD is creating the dataset and start filling it and in the end instead of creating the snapshot, it tries to recreate the whole dataset :) And all transfered data disappears. The fun part is, that if you follow the advise in the errormessage, the system will say: ------------------------------------------------------------ cannot receive new filesystem stream: dataset does not exist ---------------------------------------------------------- Your remark: "the situation was created by a user explicitly running "zfs set dnodesize=auto" or a "zpool create -O dnodesize=auto", was wrong. I did not set anything, but those settings were chosen by the Ubuntu install process and I only created some own datasets on that "rpool" datapool. That is why I complained about the missing params in a future "install" or "create datapool" process. For me personally, it also could be solved by allowing me to choose the "rpool" size during install. In that case I would not store my user datasets in rpool, but create an own datapool on that nvme-SSD with the correct compatible feature settings using the OpenZFS document. I tried it again, because I updated FreeBSD to 12.1, but exactly the same error happened again. What happens and the commands and error messages were in the original bugreport. If you think it is a FreeBSD problem, please send the stuff to them. On Tue, 2020-01-28 at 20:46 +0000, Richard Laager wrote: > The last we heard on this, FreeBSD was apparently not receiving the > send > stream, even though it supports large_dnode: > > https://zfsonlinux.topicbox.com/groups/zfs- > discuss/T187d60c7257e2eb6-M14bb2d52d4d5c230320a4f56/feature- > incompatibility-between-ubuntu-19-10-and-freebsd-12-0 > > That's really bizarre. If it supports large_dnode, it should be able > to > receive that stream. Ideally, this needs more troubleshooting, > particularly on the receive side. "It said (dataset does not exist) > after a long transfer." is not particularly clear. I'd like to see a > copy-and-paste of the actual `zfs recv` output, at a minimum. > > @BertN45, if you want to keep troubleshooting, a good next step would > be > to boil this down to a reproducible test case. That is, create a list > of > specific commands to create dataset and send it that demonstrates the > problem. That would help. We may need to flesh out the reproducer a > bit > more, e.g. by creating a pool on sparse files with particular feature > flags. > -- 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
