[Devel] bug#21790: [PATCH] coreutils/cp: handle EOF extents correctly

[Pádraig Brady]

On 30/10/15 16:57, Pádraig Brady wrote:
> On 30/10/15 09:02, Dmitry Monakhov wrote:
>> fallocate can allocate extens beyond EOF via FALLOC_FL_KEEP_SIZE.
>> Currenly sparse engine tries to copy such extents which is wrong and
>> result in silent data corruption (leave file with incorrect size).
>>
>> ##TESTCASE
>> echo blabla > sparse_falloc.in
>> truncate -s 2M sparse_falloc.in
>> fallocate -n -o 4M -l 1M sparse_falloc.in
>> cp sparse_falloc.in sparse_falloc.out
>> cmp sparse_falloc.in sparse_falloc.out
> 
> Ouch.  Thanks for the analysis and patch.
> It looks correct.  I'll analyze further before applying.

This doesn't handle the --sparse==never case
(which is broken with and without the patch).

Also one might have an extent spanning the file size boundary,
in which this patch could miss the remaining data?

Also currently if the source file is being extended
while being copied, we continue to read, whereas we now wont.
Theoretically this is an issue when st_size doesn't match
what's available to be read, though maybe not a practical issue
since we don't use this path for a zero st_size, nor
sources that don't support fiemap anyway.

This might be an opportune time to rip out the fiemap stuff
in favor of SEEK{DATA,HOLE} anyway, which I intended to do
during this cycle.  For fix backporting sake though,
we should apply the minimal fix to the fiemap code first.

Attached is the current minimally tested patch.

thanks,
Pádraig.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cp-trailing-extents.patch
Type: text/x-patch
Size: 1419 bytes
Desc: not available
URL: <http://lists.openvz.org/pipermail/devel/attachments/20151030/68394a66/attachment-0001.bin>