* FS_IOC_FIEMAP fe_physical discrepancies on btrfs
@ 2018-10-27 15:45 Lennert Buytenhek
2018-10-27 16:50 ` Andrei Borzenkov
2018-10-28 2:15 ` Qu Wenruo
0 siblings, 2 replies; 3+ messages in thread
From: Lennert Buytenhek @ 2018-10-27 15:45 UTC (permalink / raw)
To: linux-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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: FS_IOC_FIEMAP fe_physical discrepancies on btrfs
2018-10-27 15:45 FS_IOC_FIEMAP fe_physical discrepancies on btrfs Lennert Buytenhek
@ 2018-10-27 16:50 ` Andrei Borzenkov
2018-10-28 2:15 ` Qu Wenruo
1 sibling, 0 replies; 3+ messages in thread
From: Andrei Borzenkov @ 2018-10-27 16:50 UTC (permalink / raw)
To: Lennert Buytenhek, linux-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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: FS_IOC_FIEMAP fe_physical discrepancies on btrfs
2018-10-27 15:45 FS_IOC_FIEMAP fe_physical discrepancies on btrfs Lennert Buytenhek
2018-10-27 16:50 ` Andrei Borzenkov
@ 2018-10-28 2:15 ` Qu Wenruo
1 sibling, 0 replies; 3+ messages in thread
From: Qu Wenruo @ 2018-10-28 2:15 UTC (permalink / raw)
To: Lennert Buytenhek, linux-btrfs
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-10-28 2:20 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-27 15:45 FS_IOC_FIEMAP fe_physical discrepancies on btrfs Lennert Buytenhek
2018-10-27 16:50 ` Andrei Borzenkov
2018-10-28 2:15 ` Qu Wenruo
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.