Bug 12305 - --fallocate and --sparse work wrong
--fallocate and --sparse work wrong
Status: RESOLVED DUPLICATE of bug 11588
Product: rsync
Classification: Unclassified
Component: core
3.1.1
All Linux
: P5 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-10-01 13:58 UTC by Коренберг Марк
Modified: 2016-10-19 01:41 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Коренберг Марк 2016-10-01 13:58:26 UTC
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)
Comment 1 Коренберг Марк 2016-10-01 14:00:02 UTC
typo: very important "attribute" is NOT copied
Comment 2 Andrey Gursky 2016-10-01 19:20:30 UTC
Hi Марк,

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

Regards,
Andrey
Comment 3 Wayne Davison 2016-10-01 22:07:29 UTC

*** This bug has been marked as a duplicate of bug 11588 ***
Comment 4 Carson Gaspar 2016-10-08 16:12:14 UTC
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.
Comment 5 Коренберг Марк 2016-10-08 19:44:32 UTC
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 )