large_blocks error

[fow0ryl]

I have synced some datasets to a new machine with ssd's instead of hdd's. Works fine fo far.
Now I wish to make this machine the primary one and the old machine a backup machine. So I decided to change the zrep direction. Works for most datasets, but I faild with one :(
I get this error on the new master:cannot receive incremental stream: incremental send stream requires -L (--large-block), to match previous receive.
After looking around I found that on the old master "feature@large_blocks" is set to "active". But on the new master it is set to "enabled".
After creating a file with 1M blocksize, the status changed to "active" on the new master too.

But I still get the error "requires -L" ...

[ppbrown]

Hello,
I'm afraid this sounds like some issue specific to your ZFS implementation.
This is best solved by a support forum for your OS.
If there are then any tweaks that may be needed on the zrep end, please let me know

[linuxturtle]

I'm running into this same error trying to set up zrep with existing datasets I've been syncing manually.
But I have no problem doing a send/receive of the zrep "unsent" snapshot using only zfs send -vwI (i.e. without -L). I don't understand what zrep is doing under the covers, so I'm having a hard time figuring out what's going on. DEBUG=1 doesn't give any additional information. Here's the whole sequence if that's helpful:

># zrep sync pond/Media
DEBUG: lock is no longer held by 45689
overiding stale lock on pond/Media from pid 45689
DEBUG: zrep_lock_fs: set lock on pond/Media
sending pond/Media@zrep_000002 to nandi.bejfam.net:pond/Media
cannot receive incremental stream: incremental send stream requires -L (--large-block), to match previous receive.
Error: Problem doing sync for pond/Media@zrep_000002. Renamed to pond/Media@zrep_000002_unsent

Then syncing manually:

># zfs send -vw -I zrep_000001 pond/Media@zrep_000002_unsent | ssh nandi zfs recv -Fs pond/Media
send from @zrep_000001 to pond/Media@zrep_000002_unsent estimated size is 125K
total estimated size is 125K
TIME        SENT   SNAPSHOT pond/Media@zrep_000002_unsent

Any help/guidance in figuring out what's happening would be appreciated :)

BTW, these datasets are configured with recordsize=1M, if that might be relevant.

[ppbrown]

that is very odd. Any chance that ZREP is pulling in a different version of the zfs command, than you use on the command line?

…

On Wed, Jul 31, 2024 at 12:08 PM Brett Johnson ***@***.***> wrote: I'm running into this same error trying to set up zrep with existing datasets I've been syncing manually. But I have no problem doing a send/receive of the zrep "unsent" snapshot using only "zfs send -vwI" (i.e. without -L). I don't understand what zrep is doing under the covers, so I'm having a hard time figuring out what's going on. DEBUG=1 doesn't give any additional information. Here's the whole sequence if that's helpful: ># zrep sync pond/Media DEBUG: lock is no longer held by 45689 overiding stale lock on pond/Media from pid 45689 DEBUG: zrep_lock_fs: set lock on pond/Media sending ***@***.***_000002 to nandi.bejfam.net:pond/Media cannot receive incremental stream: incremental send stream requires -L (--large-block), to match previous receive. Error: Problem doing sync for ***@***.***_000002. Renamed to ***@***.***_000002_unsent Then syncing manually: ># zfs send -vw -I zrep_000001 ***@***.***_000002_unsent | ssh nandi zfs recv -Fs pond/Media send from @zrep_000001 to ***@***.***_000002_unsent estimated size is 125K total estimated size is 125K TIME SENT SNAPSHOT ***@***.***_000002_unsent Any help/guidance in figuring out what's happening would be appreciated :) — Reply to this email directly, view it on GitHub <#199 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANEV6OFFH5Y5Y5G5YY5HILZPEY35AVCNFSM6AAAAABLZCTT7WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRRGIZDGOJTGU> . You are receiving this because you commented.Message ID: ***@***.***>

[linuxturtle]

Any chance that ZREP is pulling in a different version of the zfs command, than you use on the command line?

I can't think of any way it could. Both machines are vanilla Proxmox 8/debian 12 installs, and only have one zfs executable I know of (from the zfsutils-linux package installed by default)

> zfs --version
zfs-2.2.4-pve1
zfs-kmod-2.2.4-pve1

Is there any way to get zrep to spit out the actual command line it's using? Maybe that would offer a clue?

[ppbrown]

well sure. stuff "set -x" in the script, and then redirect stderr 2>/tmp/zrep.debug you'll want to put it in the actual function getting called to do the push. the "easy" way is to do one one at the top level, then it will print out the functions it is using. Then put the set -x inside the most relevant looking function. or.. just look for all instances of "zfs send" and put it in those functions. or... make a wrapper script for zrep #!/bin/bash echo "args are $@" >>/tmp/logfile zrep "$@" although zrep does some fancy things with arg passing, so the wrapper approach probably may break in certain use cases.

…

On Wed, Jul 31, 2024 at 12:55 PM Brett Johnson ***@***.***> wrote: Any chance that ZREP is pulling in a different version of the zfs command, than you use on the command line? I can't think of any way it could. Both machines are vanilla Proxmox 8/debian 12 installs, and only have one zfs executable I know of (from the zfsutils-linux package installed by default) > zfs --version zfs-2.2.4-pve1 zfs-kmod-2.2.4-pve1 Is there any way to get zrep to spit out the actual command line it's using? Maybe that would offer a clue? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[linuxturtle]

Just to update, I attempted to debug the script, then started getting errors about the destination dataset having changed since the last sync, and some other errors which made no sense to me, so I decided to start with a clean "zrep create", and now the syncs are working as expected, and I can no longer recreate the problem.