speeding up zfs send | recv

[mike tancsa]

On 5/13/2021 11:37 AM, Alan Somers wrote:
> On Thu, May 13, 2021 at 8:45 AM mike tancsa <mike at sentex.net
> <mailto:mike at sentex.net>> wrote:
>
>     For offsite storage, I have been doing a zfs send across a 10G
>     link and
>     <trim>
>     Why would the mail spool send be so slow compared to the sends where
>     datasets only have a few large files ?
>
>
> Is this a high latency link?  ZFS send streams can be bursty.  Piping
> the stream through mbuffer helps with that.  Just google "zfs send
> mbuffer" for some examples.  And be aware that your speed may be
> limited by the sender.  Especially if those small files are randomly
> spread across the platter, your sending server's disks may be the
> limiting factor.  Use gstat to check.
> -Alan

Thanks for the mbuffer suggestion, I will give it a try!  The fiber is
just over to the next building and connected via layer 2 switch so very
low latency.

5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.042/0.057/0.087/0.015 ms

zfs is all "black box" to me, but I don't understand why the contents of
the dataset would make a difference ?  I am sending from my backup
server to my offsite backup server. i.e. the mail server sends its
incremental snaphots to the backup server. I then once a week focus on
the latest snapshot on the backup server and send it to my offsite
server.  Would not that zfs send just be sending blocks of data from the
zfs dataset ? and wouldn't all contents have an equal chance of being
spread across the platters on the backup server ?

    ---Mike