rsync behavior on copy-on-write filesystems

Allen Supynuk allen.supynuk at
Wed May 22 15:25:01 MDT 2013

Sorry for the churn and thanks for the suggestions. When I redid my
experiments over the network everything worked just as I dreamed it
would. Changing the first 4K bytes only caused a 4K change in the
copy. Changing meta-data (time stamp) only caused the time stamp to
change in the copy.

This is very nice and I expect it to save 10's of GB per archive going forward.

Kevin was right. --whole-file was the default when source and
destination are specified as local paths.

On 5/22/13, Allen Supynuk <allen.supynuk at> wrote:
> Kevin,
> I will try again over a remote connection to see if that makes a
> difference. Not expecting -z to day much of anything based on the
> random data, just wanting to be consistent with the flags in the
> finished solution.
> Chris,
> You only get --whole-file if you specify it (or -W).
> Paul,
> For my first couple of days of testing I dutifully did both 'df -h .'
> and 'btrfs filesystem df .' until I saw that they give the same answer
> after you wait for background cleanup. In this case we are only adding
> files so no background cleanup applies.
> On 5/22/13, Paul Slootman <paul+rsync at> wrote:
>> On Tue 21 May 2013, Allen Supynuk wrote:
>>> ## 1) Start with an empty filesystem
>>> $ df -h .
>> Note that you need to be using "btrfs filesystem df ."
>> for reliable numbers; the normal df does not take into account
>> background cleanups etc.
>> Paul
>> --
>> Please use reply-all for most replies to avoid omitting the mailing list.
>> To unsubscribe or change options:
>> Before posting, read:
> --
> Allen.Supynuk at

Allen.Supynuk at

More information about the rsync mailing list