Skip to contentSkip to conversation

Another 'traling page extent' observation

DISCUSSION Holger Hoffstätte 1 participant 1 message Jun 14, 2016 Btrfs file system

lore
Share & tools
lore
#0 lore raw

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"