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
