Re: FS_IOC_FIEMAP fe_physical discrepancies on btrfs

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1411 bytes --]



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
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]