ZFS recv oddity

Peter Jeremy <[email protected]> Tue, 28 Jul 2026 10:12:49 +1000
Newsgroups gmane.os.freebsd.devel.file-systems
Message-ID <[email protected]>
--17BJl2IaFT2CmkOS
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I have noticed that an incremental "zfs recv" to a backup pool consistently
stalls for an extended period (roughly 5 minutes) at the start before it
starts copying data.  During this time, there's basically no IO on the pool
(<1 IOPS) and basically no CPU activity (~0.5% increase vs the background).
I can understand the "zfs recv" needing to do some book-keeping when it
starts but I would expect that to involve non-trivial CPU and/or IO.  Once
the "zfs recv" starts actually writing data, everything transfers as
expected.  Does anyone have any suggestions as to what might be going on?

Overall backup approach:
  zfs import -N -d $DEVICE $POOL_ID bupool
  zfs send -RLeI @$OLD pool@$NEW | <<network and memory buffer>> | zfs recv=
 -Fuv bupool

The pool has just under 23k snapshots and just under 100 filesystems.

Reporting from buffer tool shows that it quickly fills to its 1GB limit and
writes about 1.8KiB to the "zfs recv" then sits for 5 minutes before the
"zfs recv" starts reporting "receiving incremental stream...".

I see similar behaviour whether the receiving side is a one or two HDD pool
on an arm64 system or a 6-HDD pool on a amd64 system.

--=20
Peter Jeremy

--17BJl2IaFT2CmkOS
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQKvBAEBCgCZFiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAmpn8/obFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwzXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25z
Lm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIy
N0UxNkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs09C0P/0kWft3xibHIxSsVAx6Y
u0BgP14jOsmw2VX5o45LyBxMTtpLPFlkqcSBOla3CmKHFbIpYSPDNqmDNzcE/MSM
BI0jXEcjUfV+m5ChTFFQgqZ4od72vq3FGpPK32aMGTgvdhngTdlkm4mf7FcrbLMB
WSl9XFIQ8UcWyJik4qk59wpO4/S14FStBm+fy4zntFPDZ0NdngD9WSU2kwnCvGek
FU5m2KirbSEewJZtzucE4SHjS4a62AasYhurqta6omCFKCKlIRGuoQm5Hk7HcYxD
1uWrZvzpFL1X8su9cEs2WfT4z7O2XtytqwFDKoUeMntus5KQBQioz27nbSjsmo9j
Efno/eEjn9CJomOT5DVVchG8iVrTqRE+xHSUUKSDfW3cfuc+x1W7VG0+t3iUKLNB
IgGeIUXzt7vFYDKAWAknPfUR45XCfJyCB9azjnGH0AFF3OiWD2Xw2D8FwdTJC8vv
FAJJoLaSougfrHHWT5WxKHQOQtg8gq8HBCJZYI/2KzfUICbx0XzkbOQkykqP95wd
QVoxmM9Kvuig2i5mRRZebz41eq1dcYc2CRqIjCBH8264Q2JWqCTvJhOlN7NmfJXZ
YR07ChjxS3Q424CiUlMbIGBo1nvvYsPJJT4xQvyn4HZ+CojAnaaMLXq/P+s3l0QO
vysQraGxGimH/37/y+I8KLsx
=to58
-----END PGP SIGNATURE-----

--17BJl2IaFT2CmkOS--