Re: [PATCH v3] btrfs: remove v0 extent handling

[David Sterba <dsterba@suse.cz>]

On Sat, Aug 12, 2023 at 07:08:39AM +0800, Qu Wenruo wrote:
> 
> 
> On 2023/8/11 22:43, David Sterba wrote:
> > On Fri, Aug 11, 2023 at 07:02:11PM +0800, Qu Wenruo wrote:
> >> The v0 extent item has been deprecated for a long time, and we don't have
> >> any report from the community either.
> >>
> >> So it's time to remove the v0 extent specific error handling, and just
> >> treat them as regular extent tree corruption.
> >>
> >> This patch would remove the btrfs_print_v0_err() helper, and enhance the
> >> involved error handling to treat them just as any extent tree
> >> corruption.
> >
> > We added the helper in 2018, so it's about 5 years ago, without any
> > reports so yeah let's remove it for good, thanks.
> >
> > There are still remaining references to BTRFS_EXTENT_REF_V0_KEY in the
> > tracepoints and in ctree.h,
> 
> Tracepoints are what I missed, but I didn't hit any "_V0" or "_v0"
> inside fs/btrfs/ directory.

Yeah, I got me a few times in the past, compilation errors, so I know
that I have to look there too.
> 
> > at least the tracepiont should be deleted
> > but we may need to  keep the ctree.h defintion documented so we don't
> > reuse the key number yet. I can fix that in the commit.
> 
> We need the definition for sure, but IIRC it's in uapi now.

I moved the definition to a comment so it's greppable but it would
create a build error. I've checked debian code search and it seems that
there's only strace using the direct definition so this might break it
but I'd rather let them fix it once than we keep the definition around.