Date: Fri, 11 Nov 2022 14:51:06 -0600 (CST) From: Bob Friesenhahn <bfriesen@simple.dallas.tx.us> To: andy thomas <andy@time-domain.co.uk> Cc: freebsd-fs@FreeBSD.org Subject: Re: Odd behaviour of two identical ZFS servers mirroring via rsync Message-ID: <alpine.GSO.2.20.2211111444320.16889@scrappy.simplesystems.org> In-Reply-To: <alpine.BSF.2.22.395.2211112008220.30520@mail0.time-domain.net> References: <alpine.BSF.2.22.395.2211111709230.29479@mail0.time-domain.net> <CAOgwaMuoLQ9Er67Y%2B=q%2Bf9724v2WT3L5v5TZaRVXq%2B=1vEyJ%2BA@mail.gmail.com> <alpine.BSF.2.22.395.2211112008220.30520@mail0.time-domain.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 11 Nov 2022, andy thomas wrote: > > It seems almost as if ZFS is not freeing up blocks when rsync has deleted or > shrank files, leaving unwanted blocks lurking around in the folder that 'du' > then discovers and adds to its tally when it works out the space usage of > that folder! This would be completely expected behavior if zfs snapshots are used. The rsync block sizes can be adjusted to be a better match for zfs block sizes (e.g. 128k). For example, zfs will do a 'sync' to write new data to disk and it will help if all of the data in an new/updated zfs block is provided at the time of the 'sync' (rather than 1/4 or 1/2 of the block). Network buffering can also be a factor since it effects the timing of data delivery to the backup server. If the sending side tends to stall, then add more buffering. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.GSO.2.20.2211111444320.16889>