On Monday, July 4, 2016 1:35:25 PM CEST Andreas Dilger wrote: > I think in addition to fixing btrfs (because it needs to work with existing > tar/rsync/etc. tools) it makes sense to *also* fix the heuristics of tar to > handle this situation more robustly.
What I was rather thinking about is to remove the [2] heuristic. As there is now SEEK_HOLE implemented, the need for that check "completely sparse files" might be considered less useful. With [1], I'm not sure -- is it that bad to face some false positive there? (it is documented that tar shouldn't be run concurrently with other processes writing to archived files .., and waiting for flush here is probably a very similar race condition). > One option is if st_blocks == 0 then tar should also check if st_mtime is > less than 60s in the past, and if yes then it should call fsync() on the > file to flush any unwritten data to disk , or assume the file is not sparse > and read the whole file, so that it doesn't incorrectly assume that the file > is sparse and skip archiving the file data. The reported fact 'st_blocks != 0' doesn't mean that the fsync() call is not needed, so I'm not 100% we should special-case the 'st_blocks == 0' files. -- As this effectively breaks tar's testsuite on btrfs, could we also explicitly sync in 'genfile'? Pavel > > Cheers, Andreas > > > [1] > > http://git.savannah.gnu.org/cgit/paxutils.git/tree/lib/system.h?id=ec72abd9dd63bbff4534ec77e97b1a6cadfc3cf8#n392 > > [2] > > http://git.savannah.gnu.org/cgit/tar.git/tree/src/sparse.c?id=ac065c57fdc1788a2769fb119ed0c8146e1b9dd6#n273 -- 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
