Hi, I have made another observation regarding extra extents; it seems I'm good at finding these things. Sorry. ;-)
This time it's with rsync. I found it when I started to use the --inplace option, which doesn't do rsync's usual write-to-temporary/rename cycle, but instead writes to a destination file directly. All of a sudden many newly backed up files had a traling 4k extent, for no good reason. This has nothing to do with extending overwrites (where new extents would of course be fine); it happens when the file is new. It is also independent of the file size or the filesystem state: it does not seem to be caused by fragmented free space. Reproducer example (current dir is btrfs): $ls -al /tmp/data -rw-r--r-- 1 root root 17569552 Jun 14 16:33 /tmp/data $rm -f data && rsync /tmp/data . && sync && filefrag -ek data Filesystem type is: 9123683e File size of data is 17569552 (17160 blocks of 1024 bytes) ext: logical_offset: physical_offset: length: expected: flags: 0: 0.. 17159: 53918020.. 53935179: 17160: last,eof data: 1 extent found $rm -f data && rsync --inplace /tmp/data . && sync && filefrag -ek data Filesystem type is: 9123683e File size of data is 17569552 (17160 blocks of 1024 bytes) ext: logical_offset: physical_offset: length: expected: flags: 0: 0.. 17155: 48133532.. 48150687: 17156: 1: 17156.. 17159: 36734592.. 36734595: 4: 48150688: last,eof data: 2 extents found This is repeatable and independent of the file, so I suspect that after Liu Bo's fix for the previously reported stray extents in the middle of the file with slow buffered writes [1] there's an edge case where a page is still treated differently at the end after close()-ing the file - which rsync does correctly. This is on my 4.4.x++ kernel with btrfs ~4.7 and space_cache=v2, but since it also happens on a fresh volume with v1 it's probably just another off-by-one somewhere in the writeback/page handling. thanks, Holger [1] commit a91326679f aka "Btrfs: make mapping->writeback_index point to the last written page" -- 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
