Bug 11651 - Can we allow --inplace and --sparse to coexist when --whole-file is in play?
Summary: Can we allow --inplace and --sparse to coexist when --whole-file is in play?
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.1.2
Hardware: All All
: P5 enhancement (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
Depends on:
Reported: 2015-12-26 04:33 UTC by Kevin Korb
Modified: 2020-07-26 09:05 UTC (History)
0 users

See Also:


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

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]?
Comment 2 Wayne Davison 2020-07-26 09:05:10 UTC
There was not a way to punch holes in existing files in the past, but that has been fixes in modern OSes and rsync now takes advantage of it.