Another 'traling page extent' observation

Another 'traling page extent' observation

[Holger Hoffstätte]

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"