Summary: rsync should support reflink similar to cp --reflink
AssignedTo: [hidden email] ReportedBy: [hidden email] QAContact: [hidden email]
new filesystems support the reflink system call...
the standard GNU cp utility now supports this too.
this functionality is invaluable for future rsync.
@BasketCase recommended I write this as a feature.
I have written a rough draft of a patch to enable support for (Btrfs) reflinks
in rsync. It is very lightly tested.
Only Btrfs is supported (using BTRFS_IOC_CLONE), and this is intended to
provide a better alternative to --inplace for updating a backup which will be
snapshotted repeatedly. It avoids the problems of --inplace with
partial updates and stale hardlinks.
It adds two new options:
When updating an existing file, rather than creating an entirely new temporary
file, rsync will create a 'reflink' copy of the original file and update it in
place. When creating a backup copy of a file, rsync will also create a
'reflink' copy rather than rewriting the file. If a 'reflink' copy cannot be
performed it will fall back to the normal, non-reflink behaviour.
--reflink-always behaves like --reflink, but disables the fallback if a reflink
according to strace, rsync does not call the clone ioctl at all (none of the
$ rsync --reflink-always subv1/testfile subv2
240,475,844 100% 43.54MB/s 0:00:05 (xfr#1, to-chk=0/1)
rsync: open "/subv2/testfile": No such file or directory (2)
rsync: reflink of "/subv2/.testfile.8bxNk0" failed: No such file or directory
rsync error: some files/attrs were not transferred (see previous errors) (code
23) at main.c(1165) [sender=3.1.2dev]
and the target file is not created, the same command without --reflink works.
* for speed comparison, I did 'cp --reflink subv1/testfile subv2' and it takes
near to no time, compared to 5 seconds for bare copy, I'm expecting that rsync
--reflink would take comparable time to cp+reflink