Thanks, given that this is resolved with the recent ZFS issues and there
is a workaround too, I'm going to close this bug.
** Changed in: zfs-linux (Ubuntu)
Status: Incomplete => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subsc
I'm using Ubuntu 21.04 Beta and FreeBSD 13.0-RC5 now on my desktop and
backup server. I did check it and it works without any issue, even after
I changed the setting I used to force compatibility. I changed the
'dnodesize' back to 'auto' from 'legacy'. Legay that I used to force
compatibility.
--
I'm using Ubuntu 21.04 Beta and FreeBSD 13.0-RC5 now on my desktop and
backup server. I did check it and it works without any isue, even after
I changed the setting I used to force compatibility.
I already added this text to the bug report.
On Wed, 2021-04-07 at 13:24 +, Colin Ian King wrote:
ZFS 2.0.x is now the default for Ubuntu Hirsute 21.04. If anyone would
like to check that this is now compatible with BSD then that would be
useful so we can close this issue.
** Changed in: zfs-linux (Ubuntu)
Importance: Undecided => Medium
--
You received this bug notification because you a
@BertN45, thanks for the update information. Let's keep this bug open
until OpenZFS 2.0 lands and see if this resolves itself then
--
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/185498
Basically I backup every weekend again from my 64-bits Ubuntu to my
32-bits FreeBSD. I solved the issue by setting the property
dnodesize=legacy for the datasets I wanted to backup. I also reloaded
those datasets once to get the storage with the right dnodesize
everywhere.
The problem has been in
@folks, what's the current state of this bug? Has any progress been made
on cornering this on the FreeBSD or Linux side?
--
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:
The system uses xattr=sa, but I did not set it myself. Like you can see
in the annex, it has been inherited from rpool everywhere and it has
been set by the installer.
I annexed the properties
- Home of Ubuntu, which properties I did not touch at all (except
canmount) and
- my main dataset with
I quickly set up a VM last night and tried to recreate problem, I have
been unsuccessful so far. I'm wondering if certain dnode data (perhaps
the use of xattr=sa on the Linux source) might be triggering the issue?
--
You received this bug notification because you are a member of Kernel
Packages,
There does seem to be a real bug here. The problem is that we don’t know
if it is on the ZoL side or the FreeBSD side. The immediate failure is
that “zfs recv” on the FreeBSD side is failing to receive the stream. So
that is the best place to start figuring out why. If it turns out that
ZoL is gene
BertN45,
Thanks for the continued followup. Most of these ZFS variants run test
suites to ensure that new code has a limited ability to create
additional issues. I would expect that cross OS compatibility is not
heavily tested (if at all). You were in a position to witness this
problem, took ef
I did not blame you, I only noticed a seemingly missing process in the
communication between both groups (ZOL/ZOF or Ubuntu/FreeBSD).
I said I already tried your proposed case in a different way. I'm always
willing to try something else, but I need to understand why. I'm not a monkey,
that has t
The FreeBSD bug report:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243730
Like I said, boiling this down to a test case would likely help a lot.
Refusing to do so and blaming the people giving you free software and
free support isn’t helpful.
** Bug watch added: bugs.freebsd.org/bugzilla/
I now also filed a bug-report Bug 243730 for FreeBSD with the following
ending;
Ubuntu and FreeBSD did choose different defaults for large-dnodes and
dnodesizes, but to solve bugs related to feature incompatibility both
groups have to communicate! The problem will not disappear completely,
because
** Changed in: zfs-linux (Ubuntu)
Status: New => Incomplete
--
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
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 uncompress
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
"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 stripe
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=s
What do you mean with "a compact reproducer"? I can reproduce the error
easily, but I have no clue, how to produce more info? I'm still
relatively new to FreeBSD.
On Wed, 2020-01-29 at 01:20 +, Richard Laager wrote:
> So, one of two things is true:
> A) ZFS on Linux is generating the stream in
So, one of two things is true:
A) ZFS on Linux is generating the stream incorrectly.
B) FreeBSD is receiving the stream incorrectly.
I don't have a good answer as to how we might differentiate those two.
Filing a bug report with FreeBSD might be a good next step. But like I
said, a compact reprodu
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/re
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 bizarr
Lazy is not the goal, nor is prematurely cleaning out the bug tracker.
After the 2019-12-04 message, it seemed that things were working well,
so it seemed to be time for a re-declaration of what we are trying to
achieve.
It seems this situation was created by a user explicitly running "zfs
set dno
The easy, lazy solution is to close this bugreport. However if you
start to use this install option on servers in server farms, you might
have this problem more frequently. The OpenZFS website has a matrix
with which features are supported by which OSes. It would be relatively
easy to implement tha
At this point, does this need a code improvement to avoid this situation
for others? If not, this looks like this bug report is ready to be
closed/resolved.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to zfs-linux in Ubuntu.
https://bugs
I did hide my errors :)
On the ZOL site Richard Laager advised me to look also at the dnodesize
property for the datasets, since both systems had the zpool feature large-dnode
"active". He assumed that the send/receive should work. The FreeBSD system had
all dnodesizes from all datasets set to
I updated both Ubuntu and I upgrade FreeBSD to 12.1, but it did not
help. Both system remain incompatible. A serious regression that forces
me to fall back on rsync-backup or ext4-boot with correctly featured
user datapools with large_dnode disabled.
So what else should we learn:
- Never break the
I received the email of your latest comment, but oddly I’m not seeing it
here.
Before you go to all the work to rebuild the system, I think you should
do some testing to determine exactly what thing is breaking the send
stream compatibility. From your comment about your laptop, it sounds
like you
I updated both Ubuntu and I upgrade FreeBSD to 12.1, but it did not
help. Both system remain incompatible.
So what should we learn:
- Never break the send/receive compatibility, especially not if you demand
during the install the complete disk (Ubuntu) or all complete disks (Raid-0 or
1) (FreeBS
I'm not sure if userobj_accounting and/or project_quota have
implications for send stream compatibility, but my hunch is that they do
not. large_dnode is documented as being an issue, but since your
receiver supports that, that's not it.
I'm not sure what the issue is, nor what a good next step wo
I will add an overview of the features of all involved datasets.
The feature@userobj_accounting and feature@project_quota are not
supported by FreeBSD 12.0 and are not part of feature list of FreeBSD as
annexed, but they are active in Ubuntu. Why? I don't use them and don't
intent to use them ever
This is probably an issue of incompatible pool features. Check what you
have active on the Ubuntu side:
zpool get all | grep feature | grep active
Then compare that to the chart here:
http://open-zfs.org/wiki/Feature_Flags
There is an as-yet-unimplemented proposal upstream to create a features
I decided to add the properties of my Dec 2018 archives datapool and
dataset of the Ubuntu PC. That dataset-backup still works between Ubuntu
19.10 and FreeBSD 12.0. I did send an incremental update a few days ago.
I noticed that the archives feature@large_dnode is enabled and not
active, maybe tha
** Description changed:
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/datas
35 matches
Mail list logo
