"dpool" is another datapool created with Ubuntu 19.10 and it had the
same defaults with respect to "large-dnode" as rpool. My main problem
has been with rpool, since it took my whole nvme-SSD. By the way the
same happened in FreeBSD with zroot, during the install it also took
all space on my striped HDDs :)
Note that FreeBSD is a 32-bits version on an old Pentium 4 HT :)
By the way dpool (Ubuntu) is also striped over two 450GB partitions on a 500GB
and a 1TB HDD. The second part of the 1TB HDD still had the
partition/datapool created by Ubuntu 18.04 with zfs 0.7.x release and
that one had no large-dnode problems.
I solved my send/receive problem by specifying on the Ubuntu system for
each dataset on rpool and dpool dnodesize=legacy and reloaded the
content of those datasets.
See the Ubuntu dnodesize overview in the attachment.
On FreeBSD zroot has "large-dnode = active" and the dnodesize is as
follows:
----------------------------------------------------------------
root@freebsd:~ # zfs get dnodesize
NAME PROPERTY VALUE SOURCE
bootpool dnodesize legacy default
zroot dnodesize legacy default
zroot/ROOT dnodesize legacy default
zroot/ROOT@upgrade12-1 dnodesize - -
zroot/hp-data dnodesize legacy local
zroot/hp-data/ISO dnodesize legacy inherited from
zroot/hp-data
-----------------------------------------------------------------
I have created a separate dataset on FreeBSD with the same attributes
as rpool/USERDATA on Ubuntu
zroot/USERDATA dnodesize auto local
Sending data to this datset had the following result:
See the send/receive results after the dnodesize overview in the
attachment. Note that at the end I tried to create a new dataset
zroot/USER.
-----------------------------------------------------------------------
And now the sends inside FreeBSD both with a new USER dataset and the
exsisting USERDATA with dnodesize=auto.
root@freebsd:~ # zfs send -c zroot/var/log@upgrade12-1 | zfs receive
zroot/USER
root@freebsd:~ # zfs send -c zroot/var/log@upgrade12-1 | zfs receive -F
zroot/USERDATA
root@freebsd:~ #
zroot/USER has been created and USERDATA existed with dnodesize=auto
The result has been as expected.
zroot/USER dnodesize legacy default
zroot/USER@upgrade12-1 dnodesize - -
zroot/USERDATA dnodesize auto local
zroot/USERDATA@upgrade12-1 dnodesize - -
---------------------------------------------------------------------
And now send from FreeBSD to Ubuntu:
see for the command attachment at the end.
and the result
rpool/USER@upgrade12-1 0B - 888K -
rpool/USER dnodesize auto inherited from rpool
rpool/USER@upgrade12-1 dnodesize - -
---------------------------------------------------------------------
Both system have the large-dnode feature active!
And almost all combinations work,
- freeBSD to freeBSD from dnodesize=legacy to a dnodesize, that is
either legacy or auto
- Ubuntu to Ubuntu, I do not remember any problem.
- freeBSD to Ubuntu from dnodesize=legacy to dnodesize=auto
- Ubuntu (dnodesize=legacy) to FreeBSD 12.x (dnodesize-legacy) works
and that is what I use now.
The default one selected as default by both development teams in
spendlid isolation, did not work! The one from Ubuntu 19.10
(dnodesize=auto) to FreeBSD 12.x (dnodesize=legacy)
Also from Ubuntu 19.10 (dnodesize=auto) to FreeBSD 12.x
(dnodesize=auto) failed, see test.
GOOD LUCK finding the error.
On Wed, 2020-01-29 at 04:29 +0000, Garrett Fields wrote:
> So these pools were created with the Ubuntu Ubiquity ZFS
> installer? I
> missed that because the pool names are hardcoded to bpool and rpool
> and
> your message lists 'dpool/dummy' and 'zroot/hp-data/dummy'
>
> Also, in the linked email thread, you stated "The ZFS manual advised
> auto, if also using xattr=sa, so that is why I used auto for my own
> datapools/datasets."
>
> Now the origin of the pool is clearer to me. Yes I do see -O
> dnodesize=auto being set on (and inherited from) rpool in Ubiquity
> root
> zfs installation. This would impact the ease of sending to non-
> large_dnode pools (or in your case FreeBSD with large_dnode
> problems).
>
> Some simple tests to run:
> Within FreeBSD, I'd be really surprised if large_dnode=active to
> large_dnode=enabled/active zfs send/recv doesn't work, but I'd start
> there.
>
> Next, I'd try to send from FreeBSD large_dnode=active to Linux
> large_dnode=enabled/active. If it fails, what error is returned?
>
> Also, like rlaager stated, we should do the original Linux
> large_dnode=active to FreeBSD large_dnode=enabled/active that gave
> you
> problems. This all will give us evidence for bug reports in FreeBSD
> and/or ZOL upstreams.
>
> I'm on a mobile device, so can build examples, if requested, at a
> later
> time.
>
** Attachment added: "dnodesize-ubuntu-freebsd"
https://bugs.launchpad.net/bugs/1854982/+attachment/5323858/+files/dnodesize-ubuntu-freebsd
--
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
