Re: FS_IOC_FIEMAP fe_physical discrepancies on btrfs
On 2018/10/27 下午11:45, Lennert Buytenhek wrote: > Hello! > > FS_IOC_FIEMAP on btrfs seems to be returning fe_physical values that > don't always correspond to the actual on-disk data locations. For some > files the values match, but e.g. for this file: > > # filefrag -v foo > Filesystem type is: 9123683e > File size of foo is 4096 (1 block of 4096 bytes) > ext: logical_offset:physical_offset: length: expected: flags: >0:0.. 0:5774454.. 5774454: 1: last,eof > foo: 1 extent found > # > > The file data is actually on disk not in block 5774454 (0x581c76), but > in block 6038646 (0x5c2476), an offset of +0x40800. Is this expected > behavior? Googling didn't turn up much, apologies if this is an FAQ. :( Btrfs uses chunk map to build a logical address space. And all bytenrs in btrfs are in that logical address space, not physical disk bytenr. So you need refer to chunk mapping to get the real on-disk bytenr. You could consider inside btrfs there is another layer like LVM, and btrfs is on a super large virtual device. The result returned by fiemap() is just the bytenr in that virtual device (LV). For real on-disk bytenr (PV), you need to do the mapping calculation. Thanks, Qu > > (This is on 4.18.16-200.fc28.x86_64, the current Fedora 28 kernel.) > > > Thanks, > Lennert > signature.asc Description: OpenPGP digital signature
Re: FS_IOC_FIEMAP fe_physical discrepancies on btrfs
27.10.2018 18:45, Lennert Buytenhek пишет: > Hello! > > FS_IOC_FIEMAP on btrfs seems to be returning fe_physical values that > don't always correspond to the actual on-disk data locations. For some > files the values match, but e.g. for this file: > > # filefrag -v foo > Filesystem type is: 9123683e > File size of foo is 4096 (1 block of 4096 bytes) > ext: logical_offset:physical_offset: length: expected: flags: >0:0.. 0:5774454.. 5774454: 1: last,eof > foo: 1 extent found > # > > The file data is actually on disk not in block 5774454 (0x581c76), but > in block 6038646 (0x5c2476), an offset of +0x40800. Is this expected > behavior? Googling didn't turn up much, apologies if this is an FAQ. :( > > (This is on 4.18.16-200.fc28.x86_64, the current Fedora 28 kernel.) > My understanding is that it returns logical block address in btrfs address space. btrfs can span multiple devices so you will need to convert extent address to (device,offset) pair if necessary.
FS_IOC_FIEMAP fe_physical discrepancies on btrfs
Hello! FS_IOC_FIEMAP on btrfs seems to be returning fe_physical values that don't always correspond to the actual on-disk data locations. For some files the values match, but e.g. for this file: # filefrag -v foo Filesystem type is: 9123683e File size of foo is 4096 (1 block of 4096 bytes) ext: logical_offset:physical_offset: length: expected: flags: 0:0.. 0:5774454.. 5774454: 1: last,eof foo: 1 extent found # The file data is actually on disk not in block 5774454 (0x581c76), but in block 6038646 (0x5c2476), an offset of +0x40800. Is this expected behavior? Googling didn't turn up much, apologies if this is an FAQ. :( (This is on 4.18.16-200.fc28.x86_64, the current Fedora 28 kernel.) Thanks, Lennert
