Public bug reported:
If you do zfs send -D with 0.8.x userland and 2.0.x kernel, it will
actually try to produce a deduplicated send stream (whereas 2.0.x
userland stubs out that flag and prints a "this did nothing, stop trying
to use it" note).
On the system that generated it (20.04 amd64, running 5.11.0-38-generic with
zfs-0.8.3-1ubuntu12.13 zfs-kmod-2.0.2-1ubuntu5.1):
$ dd if=/dev/urandom of=/badidea/1 bs=1M count=16
$ sudo dd if=/dev/urandom of=/badidea/1 bs=1M count=16
$ sudo cp /badidea/1 /badidea/2
$ sudo zfs snap badidea@snap1
$ sudo zfs send -RLeD badidea@snap1 > dedupstream
$ sudo zfs recv badidea/badbadidea < dedupstream
internal error: Unknown error 1037
Aborted
On my Debian 10 testbed running zfs-2.1.99-422_gb0f3f393d (and same for kmod):
cannot receive: stream has unsupported feature, feature flags = 7
This functionality was dropped in commit
196bee4cfd576fb15baa6a64ad6501c594f45497. Since it does all its voodoo
in userland, it can indeed still generate a dedup'd stream.
Might it make sense to at least print a warning if using zfs send
--dedup with 2.0.x, as well as maybe copying the warning that 2.0.x
spits out on attempting to receive such a stream, so people don't
conclude that being unable to receive a send stream they generated means
their system is broken?
** Affects: zfs-linux (Ubuntu)
Importance: Undecided
Status: New
--
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/1949249
Title:
zfs send --dedup with HWE kernel modules produces unreceivable stream
Status in zfs-linux package in Ubuntu:
New
Bug description:
If you do zfs send -D with 0.8.x userland and 2.0.x kernel, it will
actually try to produce a deduplicated send stream (whereas 2.0.x
userland stubs out that flag and prints a "this did nothing, stop
trying to use it" note).
On the system that generated it (20.04 amd64, running 5.11.0-38-generic with
zfs-0.8.3-1ubuntu12.13 zfs-kmod-2.0.2-1ubuntu5.1):
$ dd if=/dev/urandom of=/badidea/1 bs=1M count=16
$ sudo dd if=/dev/urandom of=/badidea/1 bs=1M count=16
$ sudo cp /badidea/1 /badidea/2
$ sudo zfs snap badidea@snap1
$ sudo zfs send -RLeD badidea@snap1 > dedupstream
$ sudo zfs recv badidea/badbadidea < dedupstream
internal error: Unknown error 1037
Aborted
On my Debian 10 testbed running zfs-2.1.99-422_gb0f3f393d (and same for kmod):
cannot receive: stream has unsupported feature, feature flags = 7
This functionality was dropped in commit
196bee4cfd576fb15baa6a64ad6501c594f45497. Since it does all its voodoo
in userland, it can indeed still generate a dedup'd stream.
Might it make sense to at least print a warning if using zfs send
--dedup with 2.0.x, as well as maybe copying the warning that 2.0.x
spits out on attempting to receive such a stream, so people don't
conclude that being unable to receive a send stream they generated
means their system is broken?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1949249/+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
