On Wed, Aug 18, 2021 at 06:59:24PM +0200, David Sterba wrote:

On Wed, Aug 18, 2021 at 12:38:19AM +0000, Sidong Yang wrote:

quoted

On Tue, Aug 17, 2021 at 03:30:22PM +0200, David Sterba wrote:

quoted

On Sun, Jul 18, 2021 at 06:46:01AM +0000, Sidong Yang wrote:

quoted

This patch adds an subcommand in inspect-internal. It dumps file extents of
the file that user provided. It helps to show the internal information
about file extents comprise the file.

Do you have an example of the output? That's the most interesting part.
Thanks.

Thanks for reply.
This is an example of the output below.

# ./btrfs inspect-internal dump-file-extent /mnt/test1
type = regular, start = 2097152, len = 3227648, disk_bytenr = 0, disk_num_bytes = 0, offset = 0, compression = none
type = regular, start = 5324800, len = 16728064, disk_bytenr = 0, disk_num_bytes = 0, offset = 0, compression = none
type = regular, start = 22052864, len = 8486912, disk_bytenr = 0, disk_num_bytes = 0, offset = 0, compression = none
type = regular, start = 30572544, len = 36540416, disk_bytenr = 0, disk_num_bytes = 0, offset = 0, compression = none
type = regular, start = 67112960, len = 5299630080, disk_bytenr = 0, disk_num_bytes = 0, offset = 0, compression = none

This resembles a debugging output, something like we have for
tracepoints but I think this should be more human readable, with
possiblity of parsing by scripts/tools.

Yes, I agree. I think It would be text or json.

So to not just duplicate what filefrag or xfs_io -c fiemap do, we can
optionally enhance the information with the specifics of btrfs, like on
which devices the extents are, which compression is there etc. But the
basic output should be more or less like filefrag.

Yeah, this is the limit for this patch. for more than filefrag or
xfs_io, it should provide more specifics. compression type is already
included. But it would be better that it describe which device 
has the extents. it goes to v2.