On 30/10/15 18:54, Pádraig Brady wrote: > 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.
I'll apply the attached in your name soon. Please review. thanks, Pádraig.
_______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel