Bug 11651 - Can we allow --inplace and --sparse to coexist when --whole-file is in play?
Can we allow --inplace and --sparse to coexist when --whole-file is in play?
Status: NEW
Product: rsync
Classification: Unclassified
Component: core
3.1.2
All All
: P5 enhancement
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-26 04:33 UTC by Kevin Korb
Modified: 2016-02-13 11:55 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Korb 2015-12-26 04:33:56 UTC
I have read and understand why --inplace and --sparse can't normally coexist.

However, those reasons don't seem to apply to a case where --whole-file is in play.  Consider the use case of a 10GB VM image with 512MB of sparseness.  On the source the file uses 9.5GB of storage.  But on the target, rsync forces me to choose between 10GB of permanent storage or 9.5GB of permanent storage + another 9.5GB of temporary storage while the file is updated.

If --whole-file --sparse --inplace were all in play then rsync could write out an entirely new sparse sparse file over the existing file without requiring any temporary storage space.

IOW, I would like 'rsync --whole-file --sparse --inplace srcfile tgtfile' to be equivalent to 'rm tgtfile ; rsync --sparse srcfile tgtfile' but with rsync's --inplace handling of the new file rather than making a .tgtfile.rsync.randomstring file.
Comment 1 Peter Wu 2016-02-13 11:55:26 UTC
What is the technical limitation exactly? Different transfer algorithms? This comes from OLDNEWS:

 - Reject the combination of --inplace and --sparse since the sparse-output
   algorithm doesn't work when overwriting existing data.

The --inplace --sparse combination was rejected since
https://git.samba.org/rsync.git/?p=rsync.git;a=commitdiff;h=cfce9f6dc353a013ab8d07c20a392aeaf6cab5ea

For a local full system backup, I would prefer a best-effort transfer where 99% of all files are copied with --inplace (such that btrfs COW still works) while that single sparse Docker file of 100G (in reality 0 bytes) does not eat all space (apply --sparse).

Would that be a possibility? Maybe a --sparse=try option besides --sparse[=always]?