possibility to add additional rcve parameters

[crispyduck00]

One more feature request/enhancement from my side. ;-)

Would be nice to have also the option to set additional receive flags for zrep, so a $ZREP_RECV_FLAGS, like it is there for send too.

Would like to set some properties via -o for the received fs.

PS: maybe also a idea to set the zrep:src-host prop via -o when receiving a stream, had it now several times when testing and recovering from a disaster takeover that I only inherited the master on the previous faild host not checking correct src/dest properties. So sync from the other node was working again, but later trying a takeover failed, as the src prop was still pointing to itself.

[ppbrown]

I'm a bit confused...why would you need to use zrep for this? Is it because you are using -F, aka "zrep sync -f" ?

[crispyduck00]

I need to set some properties on the received datasets for some other things. Would be nice to set this directly with "-o prop=value" when syncing it with zrep.

And for test I also added -o ${ZREPTAG}:src-host=$ZREP_SRC_HOST to be sure src-host is set correct even after a forced failover.

[ppbrown]

If you are not using zrep sync -f, then ZREP_INIT_REMOTE_PROPERTIES already exists

(I just added this to the documentation)

[crispyduck00]

Ah, okay. Did not see it. But I am using -f as I want that datasets that no more exist on the src are also destroyed on the recv side.

But beside this it would also be nice to be able to set additional recv parameters.

[ppbrown]

hrm. I dislike this. hacks on top of hacks :-/ but I can see the need.

Okay, this issue is now,

"need to add ZREP_SYNC_REMOTE_PROPERTIES, similar to ZREP_INIT_REMOTE_PROPERTIES"

EDIT: this wont transfer over well for all situations. given that for our other case where we want to allow multiple properties set, we say, use a syntax like

PROPLIST="prop1=x prop2=y"

that is to say, SPACE separated. (which is almost mandatory since "," and ":" are reserved for property uses)

[ppbrown]

wait... I was going by memory, that "zrep sync -f" wil push properties as well. But.. can you confirm that it actually does, in your system? also, what properties were you looking to set on the remote side using this?

[crispyduck00]

At the moment I have no access to the system, but will try if I can do it tomorrow.

But I tested several times the same scenario. host1: zrep -i tank/fs1 host2 tank/fs1 host1: zrep -S -f tank/fs1 host1: ifdown nic to host2 host2: zrep takeover tank/fs1 (fails) host2: zrep takeover -L tank/fs1 host1: ifup nic to host2 host2: zrep -S -f tank/fs1 (fails; split brain) host1: zrep -S -f tank/fs1 (fails; split brain) host1: zfs inherit zrep:master tank/fs1 host2: zrep -S -f tank/fs1 (sync works again) host1: zrep takeover tank/fs1 (fails) host1: zfs get all tank/fs1 (dest and src host are host1)

From my mind, it was always after the split brain that even after successful sync host1 had still as src host1 in the props.

The other properties are custom ones I would like to use for other purposes. But could also be used with -x, -h,... user is responsible for what he adds here. I am doing the same for send (e.g. -h)

[ppbrown]

What I think you are saying, is that you like to set very specific, custom properties on your master vs slave. And when you do failovers, then master/slave has inveted properties from what you woud like. Seems to me though, that if you are doing very custom, non-standard ZFS stuff like that.. then maybe it would be more appropriate for you to do that in your failover/takeover scripts, rather than have zrep do it?

I am open to hearing another viewpoint on this. The limited information you have shared so far, however, makes me think so.

[crispyduck00]

Sure it may be something very specific, that is also the reason why it would be nice to be able to add custom recv parameters. As said, not limited to -o, could be -x, -h, -m,...

Just like for the send part:

# Sometimes, people may want to add extra flags to "zfs send".
#   If your system supports it, then adding -c means that
#   compressed filesystems will be sent in compressed form, rather
#   then autouncompressing
#    --raw is sometime used for encrypted filesystems
#ZREP_SEND_FLAGS="-c --raw"

And as it seemed the src-host is not updated when using -f, I also thought it would be a good idea to use -o to set the src-host on the receiving host = the sending host.

Both are suggestions or feature requests.

[ppbrown]

well, the trouble is, it is not so easy as ZREP_SEND. because that is SENDING side. the side you invoke zrep on. that can automatically see environment variables you set. But remote side is over ssh. which removes environment variables.

Message ID: @.***>

[ppbrown]

perhaps for clarity's sake (and also to make my task list more granular :) you could open a new issue specific to the src-host not updating, that you refer to. with as much details as possible please.

On Sat, Mar 19, 2022 at 2:06 PM Philip Brown @.***> wrote:

well, the trouble is, it is not so easy as ZREP_SEND. because that is SENDING side. the side you invoke zrep on. that can automatically see environment variables you set. But remote side is over ssh. which removes environment variables.

Message ID: @.***>

[crispyduck00]

Isn't receive also always invoked by the side where zrep is executed? So shouldn't it be fine to have it locally and pass the parameters? For test I added it on just some places, but thought it would be enough to search for "zfs recv", maybe to be sure also "recv" through the script and maybe after a cross check add $ZREP_RECV_FLAGS.

[crispyduck00]

EDIT: this wont transfer over well for all situations. given that for our other case where we want to allow multiple properties set, we say, use a syntax like

PROPLIST="prop1=x prop2=y"

that is to say, SPACE separated. (which is almost mandatory since "," and ":" are reserved for property uses)

Just tested it, you can add it like: zfs recv -o prop1=value -o prop2=value -o prop3=value .... And also zfs recv -o prop1=value -h -o prop2=value .... works well.

So best way would be to add each property with own -o, so it should not conflict with maybe other properties set by zrep, or other recv arguments.

[ppbrown]

I think you're missing the point. how would that be actually coded?

On Sat, Mar 19, 2022 at 11:07 PM crispyduck00 @.***> wrote:

EDIT: this wont transfer over well for all situations. given that for our other case where we want to allow multiple properties set, we say, use a syntax like

PROPLIST="prop1=x prop2=y"

that is to say, SPACE separated. (which is almost mandatory since "," and ":" are reserved for property uses)

Just tested it, you can add it like: zfs recv -o prop1=value -o prop2=value -o prop3=value .... And also zfs recv -o prop1=value -h -o prop2=value .... works well.

So best way would be to add each property with own -o, so it should not conflict with maybe other properties set by zrep, or other recv arguments.

— Reply to this email directly, view it on GitHub https://github.com/bolthole/zrep/issues/186#issuecomment-1073175793, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANEV6J7OQIBAAJA62USVGDVA26BHANCNFSM5RBEHBVA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were assigned.Message ID: @.***>