rsync - Oct 2016 - [Bug 12305] New: --fallocate and --sparse works wrong

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

            Bug ID: 12305
           Summary: --fallocate and --sparse works wrong
           Product: rsync
           Version: 3.1.1
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: core
          Assignee: wayned at samba.org
          Reporter: socketpair at gmail.com
        QA Contact: rsync-qa at samba.org

1.If I specify --fallocate without --sparse:
Sparse areas of SRC become fallocated on DST. This is not what I expect.


2. If I specify --sparse without --fallocate:
Fallocated areas of SRC become sparse areas on DST, meaning that very important
 "attribute" is copied.

3. If I specify both --sparse and --fallocate:
Fallocate will win. see 1.

4. If I specify none of these flags:
sparse/preallocate information will be lost on DST.

This all is very sad.

So, during synchronisation, rsync should send type of the each area, which
should be on of:

1) containig user-data
2) sparse (contains zeroes)
3) preallocated (contain zeroes)

And receiver should apply that information on target file.

Note, that plain file may have preallocated space AFTER END OF FILE -- it is
not a bug, and should be transferred.

Also, receiver side may not handle all that features, so it should be
controllable what rsync receiver will do if making sparse or preallocated area
fails with EOPNOTSUPP or so.


Detecting holes and preallocated areas may give wrong information since some
FSes fake answer. So it should be controllable 

see:
man 2 fallocate for possible modern operations.
man 2 lseek: detecting that areas (SEEK_HOLE/SEEK_DATA)

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

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

--- Comment #1 from Коренберг Марк <socketpair at gmail.com> ---
typo: very important "attribute" is NOT copied

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

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

Andrey Gursky <andrey.gursky at e-mail.ua> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrey.gursky at e-mail.ua

--- Comment #2 from Andrey Gursky <andrey.gursky at e-mail.ua> ---
Hi Марк,

I stumbled over this almost a year ago. See
https://bugzilla.samba.org/show_bug.cgi?id=11588

Regards,
Andrey

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

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

Wayne Davison <wayned at samba.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #3 from Wayne Davison <wayned at samba.org> ---


*** This bug has been marked as a duplicate of bug 11588 ***

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

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

--- Comment #4 from Carson Gaspar <carson at taltos.org> ---
Please define what you mean by 'fallocated' in (1) and (2). Please also
specify
how you're determining that something has been 'fallocated'. I agree
that (3)
is a bug, and as the only real one that I can see, and is correctly marked a s
a dup.

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

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

--- Comment #5 from Коренберг Марк <socketpair at gmail.com> ---
Fallocated: areas of the file that has been fallocate()d, but stillnot written.
Technically, on sender, even written parts that was written, but contain zeroes
may be considered as fallocated areas. I mean that receiver should call
fallocate() on that region instead writing zeroes.

How to determine: How to determine if area is alocated: lseek() +
SEEK_DATA/SEEK_HOLE. And after that, check if non-sparse area contains zeroes.
Another way - is to examine fiemap (
https://www.kernel.org/doc/Documentation/filesystems/fiemap.txt )

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