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

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

在 2024/12/19 07:06, David Sterba 写道:
> 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.
>

But I have to argue, that will only leave the problem untouched forever
(even if it's just a naming scheme problem).

Yes, it will cause backport problems, but as you also mentioned, the
frequency should not be that high (ssunless it's scrub/raid56).

With the compatible union, it should further reduce the conflict chance.

We have leave the naming problem untouched for over a decade, I think
it's time to finish it once for all.

And I'm pretty happy to handle the backports if it's just the renaming
causing the conflicts.


I also thought about the more progressive solution, just put the union
into all involved structures, and call it a day with future usage
migrated to blocksize.

But it's really no different than the current one backport wise, every
time a sectorsize is changed to blocksize, future backport will be affected.

It's just changing the short huge pain into a long small pain, the
amount of pain is not changed. And there will be a way longer window
where we have mixed terminology, causing more chaos and confusion.


Thus I recommend to take this chance to solve our long existing
problems. Or it will really never be fixed.

Thanks,
Qu