mbuffer at the wrong place in a send-pipe

[Grinzold]

When using the options --buffer <> and --send-pipe "ncat ..." the full zfs-send-pipe is wrong.

It is as follow

zfs send... | ncat <host> <port> | mbuffer... (wrong)

but it should be

zfs send... | mbuffer ... | ncat ....

In the current (wrong) version, mbuffer never gets any data to buffer.

[psy0rz]

yeah, the buffer was designed to be the last in the pipe, never expecting this usecase. :)

its documented here: https://github.com/psy0rz/zfs_autobackup/wiki/Piping#putting-it-all-together

i have to think about it, it might be more logical to make the custom stuff the last in the pipe.

[Grinzold]

Yes, when using the (standard) ssh-pipe, all is fine: zfs send | mbuffer | ssh 'mbuffer | zfs recv'...

Best is maybe to completely drop this when --send-pipe is used, as users can then just specify it themselves, like:

... --send-pipe mbuffer --send-pipe '<compress>...' --send-pipe 'ncat <host> <port>'

Same for --recv-pipe, of course.

This also avoids the hardcoded mbuffer setting, like -s or adding -L, when running as root.

Maybe still better would be a new option: --insert-in-send-pipe. Then you can drop mbuffer (and any other external command in the pipe) completely. If people want to use mbuffer with ssh, they do

--insert-in-send-pipe mbuffer

And for mbuffer with ncat` they do

--insert-in-send-pipe mbuffer --send-pipe 'ncat...'

In this case --send-pipe must only be specified once and must contain a 'sending command', which ends the pipe.

[psy0rz]

You could also solve this by using multiple —send-pipe commands?

And have the first one be mbuffer (and omit —buffer)