Re: Physical address offset of the inline extent

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 2020/6/18 下午9:21, Rebraca Dejan (BSOT/PJ-ES1-Bg) wrote:
> Hi,
> 
> Does anybody know how to get an address offset of the file data inline extent?

Since it's inline, it's inlined into metadata (tree block), thus makes
no sense to get the "address".

The address will be inside a tree block anyway.

If you really want the address, you can check it with dump-tree.

$ btrfs ins dump-tree -t 5 /dev/nvme/btrfs
fs tree key (FS_TREE ROOT_ITEM 0)
leaf 5324800 items 7 free space 13619 generation 6 owner FS_TREE
leaf 5324800 flags 0x1(WRITTEN) backref revision 1
     ^^^^^^^ Tree block bytenr
...
        item 6 key (257 EXTENT_DATA 0) itemoff 13794 itemsize 2069
                generation 6 type 0 (inline)
                inline extent data size 2048 ram_bytes 2048 compression
0 (none)

You need to use extent_buffer to grab the inline file extent item, and
use the btrfs_file_extent_inline_start() to get the inline file extent
offset inside the leaf.

Anyway, you need a solid understanding of btrfs on-disk format to grasp
the above dump.

> Kernel returns 0 trough FS_IOC_FIEMAP ioctl, but I would really like to get real physical offset if possible, most probably meaning:
> 
> In FS tree - on-disk address of the extent data item for the relevant file object + the offset within that item (0x15).
> 
> I was hoping that the key.objectid of key.type = EXTENT_ITEM would give me such an information, but apparently this is not the case.

Key.objectid of EXTENT_ITEM only means the inode number.
Key.offset of EXTENT_ITEM means the file offset, for inline file extent
it's always 0.

So it looks like you're not familiar with btrfs on-disk format, thus I
doubt the usefulness of known the inline file extent offset inside the
tree block.

Thanks,
Qu

> 
> Thanks very much,
> 
> Dejan
> 
> 
> 

Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux