Skip to contentSkip to conversation

FS_IOC_FIEMAP fe_physical discrepancies on btrfs

DISCUSSION Lennert Buytenhek 3 participants 3 messages Oct 27, 2018 – Oct 28, 2018 Btrfs file system

lore
Share & tools
lore

Lennert Buytenhek

author
#0 lore raw

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

#1 lore raw

27.10.2018 18:45, Lennert Buytenhek пишет:

Quoted 14 lines

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
#
Quoted 6 lines

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.

#2 lore raw
In reply to Lennert Buytenhek
Quoted 14 lines · 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
#
Quoted 3 lines

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

Quoted 7 lines

(This is on 4.18.16-200.fc28.x86_64, the current Fedora 28 kernel.)

Thanks,
Lennert