FS_IOC_FIEMAP fe_physical discrepancies on btrfs

FS_IOC_FIEMAP fe_physical discrepancies on btrfs

[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.)


Thanks,
Lennert

Re: FS_IOC_FIEMAP fe_physical discrepancies on btrfs

[Andrei Borzenkov]

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.

Re: FS_IOC_FIEMAP fe_physical discrepancies on btrfs

[Qu Wenruo]

[-- 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 --]