Re: ZFS on high-latency devices

I don't want to abuse the subject line too much, but I can highly
recommend the mbuffer approach, I've used this repeatedly, BSD-BSD and
BSD-Linux. It definitely feels faster than SSH, since the 'no cipher'
options were removed, and in the confusion of the HPC buffer changes.
But, its not crypted on-the-wire.

Mbuffer tuning is a bit of a black art: it would help enormously if
there was some guidance on this, and personally I've never found the
mbuffer -v option to work well: I get no real sense of how full or
empty the buffer "is" or, if the use of sendmsg/recvmsg type buffer
chains is better or worse.

-G

On Fri, Aug 20, 2021 at 6:19 PM Ben RUBSON <ben.rubson@gmx.com> wrote:
>
> > On 19 Aug 2021, at 11:37, Peter Jeremy <peter@rulingia.com> wrote:
> >
> > (...) or a way to improve throughput doing "zfs recv" to a pool with a high RTT.
>
> You should use zfs send/receive through mbuffer, which will allow to sustain better throughput over high latency links.
> Feel free to play with its buffer size parameters to find the better settings, depending on your link characteristics.
>
> Ben
>
>