rsync behavior on copy-on-write filesystems

[Allen Supynuk]

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 gmail.com> 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 wurtel.net> 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:
>> https://lists.samba.org/mailman/listinfo/rsync
>> Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
>>
>
>
> --
> Allen.Supynuk at gmail.com
>


-- 
Allen.Supynuk at gmail.com