rsync behavior on copy-on-write filesystems
allen.supynuk at gmail.com
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 gmail.com> wrote:
> 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.
> You only get --whole-file if you specify it (or -W).
> 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.
>> Please use reply-all for most replies to avoid omitting the mailing list.
>> To unsubscribe or change options:
>> Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
> Allen.Supynuk at gmail.com
Allen.Supynuk at gmail.com
More information about the rsync