Re: [PATCH] btrfs: print-tree: print header owner as signed

sun k <[email protected]>
Newsgroups org.kernel.vger.linux-btrfs
Message-ID <CAAuSuOphPez=WPHA-r8oP7kXOffV8Z00YXscd0kUFZE9pAjUSg@mail.gmail.com>
On Tue, Jun 23, 2026 at 8:08 AM David Sterba <[email protected]> wrote:
>
> On Mon, Jun 22, 2026 at 08:00:06PM +0800, sun k wrote:
> > Looks good.
> >
> > Reviewed-by: Sun YangKai <[email protected]>
> >
> > BTW, this reminds me the print-tree result of dir items that points to a
> > subvol, which currently looks like this:
> >
> > item 4 key (256 DIR_ITEM 224155391) itemoff 15967 itemsize 48
> >                 location key (43123 ROOT_ITEM 18446744073709551615) type DIR
> >                 transid 896627 data_len 0 name_len 18
> >                 name: home.20260621T2000
> >
> > And I wonder if we can also print the location key's offset field as s64
> > to make it easier to read.
>
> It should be consistent for the ROOT_ITEM and references and we can
> actually print the name of the tree, as is done in dump-tree output.

Hi David,

I'm not sure if I follow you here. The offset field of a dir item
which points to a subvol is
a little special. Its offset field will always be `0` for subvolume or
`-1` for snapshot instead
of other values. While in root tree, the offset field will always be
`0` for subvol and `generation`
for snapshot. So take this as an example, when location key is (43123
ROOT_ITEM -1) in dir item,
there's no such an item in root tree, but something like (43123
ROOT_ITEM 8750971) instead.
8750971 is the generation when the snapshot is created. So I'm not
sure what is `the name of the tree`.

BTW, it might be a little off-topic: IMO this design is used to search
the last snapshot when the
object ids of multiple snapshots of the same subvol, which are created
in different generations,
is shared. But we never allow this and always allocate a new object id
for snapshots in reality.
I wonder if we can use this to make snapshots really snapshots instead
of a read-only subvol.

Thanks,
Sun YangKai
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.