Date: Mon, 23 Aug 2021 09:39:44 +1000 From: George Michaelson <ggm@algebras.org> To: Ben RUBSON <ben.rubson@gmx.com> Cc: freebsd-fs@freebsd.org Subject: Re: ZFS on high-latency devices Message-ID: <CAKr6gn0r8xG9HNGOFh1A_usU4tPAYezeZv1chOG_bBMqy_HtXw@mail.gmail.com> In-Reply-To: <023225AD-2A97-47C5-9FE4-3ABF1BFD66F1@gmx.com> References: <YR4mY%2Bb6o7fBJqEN@server.rulingia.com> <023225AD-2A97-47C5-9FE4-3ABF1BFD66F1@gmx.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAKr6gn0r8xG9HNGOFh1A_usU4tPAYezeZv1chOG_bBMqy_HtXw>