Re: [PATCH 00/18] btrfs: migrate to "block size" to describe the

[David Sterba <dsterba@suse.cz>]

On Thu, Dec 19, 2024 at 06:43:38AM +1030, Qu Wenruo wrote:
> 
> 
> 在 2024/12/19 05:01, David Sterba 写道:
> > On Wed, Dec 18, 2024 at 08:11:16PM +1030, Qu Wenruo wrote:
> >> [IMPEMENTATION]
> >> To reduce the confusion, this patchset will do such a huge migration in
> >> different steps:
> > 
> > With some many changes everywhere this is going to make backports even
> > more tedious. I think it would be best to do the conversion gradually or
> > selectively to code that does not change so often. As you've split it to
> > files we can first pick a few obvious ones (like file-item.c) or gather
> > stats from stable.git.
> 
> For the backports, we can put the btrfs_fs_info union to older kernels 
> and call it a day without the remaining part.
> 
> So that both newer and older terminology can co-exist without any conflicts.
> 
> Although backport conflicts will still happen in the context.

This is what I'm concerned about. If patches don't apply cleanly they're
rejected from the automated stable workflow and have to be handled
manually.

> > A quick and rough estimate for all 6.x.y releases counting file
> > backports in the individual patches in the list below. This is period of
> > 2 years, 104 weeks (roughly matching number of releases). So if there
> > are 88 patches touching inode.c that's quite likely a conflict in every
> > backport.
> > 
> > This should be also correlated agains number of 'sectorsize' per file,
> > so it many not be that bad, for example in ioctl.c there are only 4
> > occurences so that's fine. The point is we can't do the renames without
> > some sensibility and respect to backports.
> 
> But at least, when a backport fails, we can easily fix the conflict.
> It will always be sectorsize -> blocksize, either in the context or the 
> modified lines.

Easily yes, but multiply that by number of failed patches and number of
stable trees to backport. This takes time and currently the upstream
backports are best-effort only, not all patches that fail to apply get
manually backported. Enough that there are CVEs of everything and we
have to care about them at $job so I'm not going to create more problems
with backports than we already have just to fix a naming inconvenience.