rsync - Dec 2015 - [Bug 11651] New: Can we allow --inplace and --sparse to coexist when --whole-file is in play?

https://bugzilla.samba.org/show_bug.cgi?id=11651

            Bug ID: 11651
           Summary: Can we allow --inplace and --sparse to coexist when
                    --whole-file is in play?
           Product: rsync
           Version: 3.1.2
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: core
          Assignee: wayned at samba.org
          Reporter: rsync at sanitarium.net
        QA Contact: rsync-qa at samba.org

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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

https://bugzilla.samba.org/show_bug.cgi?id=11651

--- Comment #1 from Peter Wu <peter at lekensteyn.nl> ---
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]?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.