Btrfs disk layout question

Btrfs disk layout question

[Amin Hassani]

Hi,

I am working on a project with Btrfs and I was wondering if there is
any way to see the disk layout of the btrfs image. Let's assume I have
a read-only btrfs image with compression on and only using one disk
(no raid or anything). Is it possible to get a set of offset-lengths
for each file or metadata parts of the image. I know there is an
unfinished documentation for On-disk Formant in here:
https://btrfs.wiki.kernel.org/index.php/On-disk_Format
But it is not complete and does not show what I am looking for. Is
there any other documentation on this? Is there any public API that I
can use to get this information. For example can I iterate on all
files starting from the root node and get all offset-lengths? This way
any part that doesn't come can be assumed as metadata. I don't really
care what is inside the metadata, I just want to know their
offset-lengths in the file system.

Thank you,
Amin.

Re: Btrfs disk layout question

[Chris Murphy]

On Tue, Apr 11, 2017 at 1:15 PM, Amin Hassani <ahassani@chromium.org> wrote:
> Hi,
>
> I am working on a project with Btrfs and I was wondering if there is
> any way to see the disk layout of the btrfs image. Let's assume I have
> a read-only btrfs image with compression on and only using one disk
> (no raid or anything). Is it possible to get a set of offset-lengths
> for each file or metadata parts of the image. I know there is an
> unfinished documentation for On-disk Formant in here:
> https://btrfs.wiki.kernel.org/index.php/On-disk_Format
> But it is not complete and does not show what I am looking for. Is
> there any other documentation on this? Is there any public API that I
> can use to get this information. For example can I iterate on all
> files starting from the root node and get all offset-lengths? This way
> any part that doesn't come can be assumed as metadata. I don't really
> care what is inside the metadata, I just want to know their
> offset-lengths in the file system.


btrfs-debug-tree contains this information in human readable form.
There's also btrfs-heatmap

https://github.com/knorrie/btrfs-heatmap



-- 
Chris Murphy

Re: Btrfs disk layout question

[Adam Borowski]

On Tue, Apr 11, 2017 at 12:15:32PM -0700, Amin Hassani wrote:
> I am working on a project with Btrfs and I was wondering if there is
> any way to see the disk layout of the btrfs image. Let's assume I have
> a read-only btrfs image with compression on and only using one disk
> (no raid or anything). Is it possible to get a set of offset-lengths
> for each file

While btrfs-specific ioctls give more information, you might want to look at
FIEMAP (Documentation/filesystems/fiemap.txt) as it works on most
filesystems, not just btrfs.  One interface to FIEMAP is provided in
"/usr/sbin/filefrag -v".

-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄⠀⠀⠀⠀ preimage for double rot13!

Re: Btrfs disk layout question

[Chris Murphy]

On Tue, Apr 11, 2017 at 3:00 PM, Adam Borowski <kilobyte@angband.pl> wrote:
> On Tue, Apr 11, 2017 at 12:15:32PM -0700, Amin Hassani wrote:
>> I am working on a project with Btrfs and I was wondering if there is
>> any way to see the disk layout of the btrfs image. Let's assume I have
>> a read-only btrfs image with compression on and only using one disk
>> (no raid or anything). Is it possible to get a set of offset-lengths
>> for each file
>
> While btrfs-specific ioctls give more information, you might want to look at
> FIEMAP (Documentation/filesystems/fiemap.txt) as it works on most
> filesystems, not just btrfs.  One interface to FIEMAP is provided in
> "/usr/sbin/filefrag -v".

Good idea. Although, on Btrfs I'm pretty sure it reports the Btrfs
(internal) logical addressing; not the actual physical sector address
on the drive. So it depends on what the original poster is trying to
discover.

-- 
Chris Murphy

Re: Btrfs disk layout question

[Austin S. Hemmelgarn]

On 2017-04-12 00:18, Chris Murphy wrote:
> On Tue, Apr 11, 2017 at 3:00 PM, Adam Borowski <kilobyte@angband.pl> wrote:
>> On Tue, Apr 11, 2017 at 12:15:32PM -0700, Amin Hassani wrote:
>>> I am working on a project with Btrfs and I was wondering if there is
>>> any way to see the disk layout of the btrfs image. Let's assume I have
>>> a read-only btrfs image with compression on and only using one disk
>>> (no raid or anything). Is it possible to get a set of offset-lengths
>>> for each file
>>
>> While btrfs-specific ioctls give more information, you might want to look at
>> FIEMAP (Documentation/filesystems/fiemap.txt) as it works on most
>> filesystems, not just btrfs.  One interface to FIEMAP is provided in
>> "/usr/sbin/filefrag -v".
>
> Good idea. Although, on Btrfs I'm pretty sure it reports the Btrfs
> (internal) logical addressing; not the actual physical sector address
> on the drive. So it depends on what the original poster is trying to
> discover.
>
That said, there is a tool to translate that back, and depending on how 
detailed you want to get, that may be more efficient than debug tree.

Re: Btrfs disk layout question

[Andrei Borzenkov]

12.04.2017 14:20, Austin S. Hemmelgarn пишет:
> On 2017-04-12 00:18, Chris Murphy wrote:
>> On Tue, Apr 11, 2017 at 3:00 PM, Adam Borowski <kilobyte@angband.pl>
>> wrote:
>>> On Tue, Apr 11, 2017 at 12:15:32PM -0700, Amin Hassani wrote:
>>>> I am working on a project with Btrfs and I was wondering if there is
>>>> any way to see the disk layout of the btrfs image. Let's assume I have
>>>> a read-only btrfs image with compression on and only using one disk
>>>> (no raid or anything). Is it possible to get a set of offset-lengths
>>>> for each file
>>>
>>> While btrfs-specific ioctls give more information, you might want to
>>> look at
>>> FIEMAP (Documentation/filesystems/fiemap.txt) as it works on most
>>> filesystems, not just btrfs.  One interface to FIEMAP is provided in
>>> "/usr/sbin/filefrag -v".
>>
>> Good idea. Although, on Btrfs I'm pretty sure it reports the Btrfs
>> (internal) logical addressing; not the actual physical sector address
>> on the drive. So it depends on what the original poster is trying to
>> discover.
>>
> That said, there is a tool to translate that back, and depending on how
> detailed you want to get, that may be more efficient than debug tree.

Could you give pointer to this tool? I use filefrag on bootinfoscript to
display physical disk offset of files of interest to bootloader. I was
not aware it shows logical offset which makes it kinda pointless.

Re: Btrfs disk layout question

[Amin Hassani]

Hi, Thanks for responses.

I actually need the physical addresses. FIEMAP I believe (and I
tested) gives logical address which as Andrei mentioned is useless.
I'm assuming btfs-debug-tree gives the physical addresses right? I
also need to know the compression method used on each extent and I
don't think I can get that with the fiemap stuff. It seems that fiemap
capability is not implemented in Btrfs as I'm looking at the Btrfs
implementation and based on documentation of fiemap:

"File systems wishing to support fiemap must implement a ->fiemap
callback on their inode_operations structure. The fs ->fiemap call is
responsible for
defining its set of supported fiemap flags, and calling a helper function on
each discovered extent:"

Thanks,
Amin.



On Wed, Apr 12, 2017 at 9:44 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
> 12.04.2017 14:20, Austin S. Hemmelgarn пишет:
>> On 2017-04-12 00:18, Chris Murphy wrote:
>>> On Tue, Apr 11, 2017 at 3:00 PM, Adam Borowski <kilobyte@angband.pl>
>>> wrote:
>>>> On Tue, Apr 11, 2017 at 12:15:32PM -0700, Amin Hassani wrote:
>>>>> I am working on a project with Btrfs and I was wondering if there is
>>>>> any way to see the disk layout of the btrfs image. Let's assume I have
>>>>> a read-only btrfs image with compression on and only using one disk
>>>>> (no raid or anything). Is it possible to get a set of offset-lengths
>>>>> for each file
>>>>
>>>> While btrfs-specific ioctls give more information, you might want to
>>>> look at
>>>> FIEMAP (Documentation/filesystems/fiemap.txt) as it works on most
>>>> filesystems, not just btrfs.  One interface to FIEMAP is provided in
>>>> "/usr/sbin/filefrag -v".
>>>
>>> Good idea. Although, on Btrfs I'm pretty sure it reports the Btrfs
>>> (internal) logical addressing; not the actual physical sector address
>>> on the drive. So it depends on what the original poster is trying to
>>> discover.
>>>
>> That said, there is a tool to translate that back, and depending on how
>> detailed you want to get, that may be more efficient than debug tree.
>
> Could you give pointer to this tool? I use filefrag on bootinfoscript to
> display physical disk offset of files of interest to bootloader. I was
> not aware it shows logical offset which makes it kinda pointless.



-- 
Amin Hassani.

Re: Btrfs disk layout question

[Austin S. Hemmelgarn]

On 2017-04-12 12:44, Andrei Borzenkov wrote:
> 12.04.2017 14:20, Austin S. Hemmelgarn пишет:
>> On 2017-04-12 00:18, Chris Murphy wrote:
>>> On Tue, Apr 11, 2017 at 3:00 PM, Adam Borowski <kilobyte@angband.pl>
>>> wrote:
>>>> On Tue, Apr 11, 2017 at 12:15:32PM -0700, Amin Hassani wrote:
>>>>> I am working on a project with Btrfs and I was wondering if there is
>>>>> any way to see the disk layout of the btrfs image. Let's assume I have
>>>>> a read-only btrfs image with compression on and only using one disk
>>>>> (no raid or anything). Is it possible to get a set of offset-lengths
>>>>> for each file
>>>>
>>>> While btrfs-specific ioctls give more information, you might want to
>>>> look at
>>>> FIEMAP (Documentation/filesystems/fiemap.txt) as it works on most
>>>> filesystems, not just btrfs.  One interface to FIEMAP is provided in
>>>> "/usr/sbin/filefrag -v".
>>>
>>> Good idea. Although, on Btrfs I'm pretty sure it reports the Btrfs
>>> (internal) logical addressing; not the actual physical sector address
>>> on the drive. So it depends on what the original poster is trying to
>>> discover.
>>>
>> That said, there is a tool to translate that back, and depending on how
>> detailed you want to get, that may be more efficient than debug tree.
>
> Could you give pointer to this tool? I use filefrag on bootinfoscript to
> display physical disk offset of files of interest to bootloader. I was
> not aware it shows logical offset which makes it kinda pointless.
>
Looking again, I think I was thinking of `btrfs inspect-internal 
logical-resolve`, which actually is more like a reverse fiemap (you give 
it a logical address, and it spits out paths to all the files that 
include that logical address), so such a tool may not actually exist (at 
least, not in the standard tools).

Re: Btrfs disk layout question

[Chris Murphy]

btrfs-map-logical is the tool that will convert logical to physical
and also give what device it's on; but the device notation is copy 1
and copy 2, so you have to infer what device that is, it's not
explicit.


Chris Murphy

Re: Btrfs disk layout question

[Andrei Borzenkov]

12.04.2017 20:21, Chris Murphy пишет:
> btrfs-map-logical is the tool that will convert logical to physical
> and also give what device it's on; but the device notation is copy 1
> and copy 2, so you have to infer what device that is, it's not
> explicit.
> 

Quickly checking output - for my purposes it looks OK, as BIS just tries
to warn if file is too far to be accessible by BIOS, so I am not even
interested in specific device, just max physical offset. Thank you!

Re: Btrfs disk layout question

[Andrei Borzenkov]

12.04.2017 20:21, Chris Murphy пишет:
> btrfs-map-logical is the tool that will convert logical to physical
> and also give what device it's on; but the device notation is copy 1
> and copy 2, so you have to infer what device that is, it's not
> explicit.
> 

Actually I just checked with btrfsprogs 4.5.3 on RAID5 and it does print
OS device name for each data chunk. It does not show checksum chunk for
RAID56 though.

Re: Btrfs disk layout question

[Chris Murphy]

On Sat, Apr 15, 2017 at 12:14 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
> 12.04.2017 20:21, Chris Murphy пишет:
>> btrfs-map-logical is the tool that will convert logical to physical
>> and also give what device it's on; but the device notation is copy 1
>> and copy 2, so you have to infer what device that is, it's not
>> explicit.
>>
>
> Actually I just checked with btrfsprogs 4.5.3 on RAID5 and it does print
> OS device name for each data chunk. It does not show checksum chunk for
> RAID56 though.

There is no checksum chunk. The data csums are in their own tree, and
only data is csum'd. The parity strip is contained within a raid56
chunk but is itself not csum'd.

Another thing that I just thought of might be useful is btrfs-debugfs
which is a python script in btrfs-progs, but typically not packaged.
The -f option pointed at a file will show extents with Btrfs logical
bytenr. So that'd be a way to get all the extents, their addresses and
lengths, to then dump into btrfs-map-logical.

For what it's worth, btrfs-map-logical's physical address it reports
is not device LBA. It's a byte offset on the selected device. So if
the device is a partition, the value is the number of bytes from the
start of that partition.



-- 
Chris Murphy

Re: Btrfs disk layout question

[Hans van Kranenburg]

On 04/11/2017 09:15 PM, Amin Hassani wrote:
> 
> I am working on a project with Btrfs and I was wondering if there is
> any way to see the disk layout of the btrfs image. Let's assume I have
> a read-only btrfs image with compression on and only using one disk
> (no raid or anything).

> Is it possible to get a set of offset-lengths
> for each file or metadata parts of the image.

These are two very different things, and it's unclear to me what you
actually want.

Do you want:

1. a layout of physical disk space, and then for each range see if it's
used for data, metadata or not used?

2. a list of files and how they're split up (or not) in one or multiple
extents, and how long those are?

Remember that multiple files can reuse part of each others data in
btrfs. So if you follow the files, and you have reflinked copies or
subvolume snapshots, then you see actual disk usage multiple times.

> I know there is an
> unfinished documentation for On-disk Formant in here:
> https://btrfs.wiki.kernel.org/index.php/On-disk_Format
> But it is not complete and does not show what I am looking for. Is
> there any other documentation on this? Is there any public API that I
> can use to get this information.

...

> For example can I iterate on all
> files starting from the root node and get all offset-lengths? This way
> any part that doesn't come can be assumed as metadata. I don't really
> care what is inside the metadata, I just want to know their
> offset-lengths in the file system.

No, that's not how it works.

To learn more about how btrfs organizes data internally, you need a good
understanding of these concepts:

* how btrfs allocates "chunks" (often 256MiB or 1GiB size) of raw disk
space and dedicate them to either data or metadata.
* how btrfs uses a "virtual address space" and how that maps back from
(dev tree) and forth (chunk tree) to raw physical disk space on either
of the disks that is attached to the filesystem.
* how btrfs stores the administration of exactly with part in that
virtual address space is in use (extent tree).
* how btrfs stores files and directories, and how it does so for
multiple directory trees (subvolumes), (the fs tree and all 256 <= trees
<= -256).
* how files in these file trees reference data from data extents.
* how extents reference back to which (can be multiple!) files they're
used in.

IOW, there are likely multiple levels of indirection that you need to
follow to find things out.

Currently there's no perfect tutorial that explains exactly all those
things in a nice way.

The btrfs wiki can help with this, the btrfs-heatmap tool which was
already meantioned is nice to play around with, and get a better
understanding of all address space and usage.

If you know exactly what the end result would be, then it's probably
possible to build something that uses the SEARCH IOCTL with which you
can search in all metadata (containing info of above mentioned trees) of
a live filesystem. At least for C and for python there's enough example
code around to do so.

-- 
Hans van Kranenburg