Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers)

[David Sterba]

On Mon, Jul 11, 2016 at 11:00:55AM -0400, Chris Mason wrote:
> So, the real bug is that we're letting some delalloc stat hang around 
> after the truncate, probably related to IO in progress.  We do already 
> account for delalloc in what we return to stat, but there's a corner 
> case involving truncate where we screw it up.

So the original testcase:

> >>     a) some "tool" creates sparse file
> >>     b) that tool does not sync explicitly and exits ..
> >>     c) tar is called immediately after that to archive the sparse file
> >>     d) tar considers [2] the file is completely sparse (because st_blocks 
> >> is
> >>        zero) and archives no data.  Here comes data loss.

will not happen. The application would basically have to mimick the
provided reproducer script and do the truncate/write loop and be lucky
enough to let tar hit the short race window.