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. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
