Re: [PATCH v2 0/4] btrfs: move some features out of experimental

[Qu Wenruo <wqu@suse.com>]

在 2026/3/4 14:27, David Sterba 写道:
> On Fri, Feb 27, 2026 at 02:03:42PM +1030, Qu Wenruo wrote:
>> [CHANGELOG]
>> v2:
>> - Move bs < ps && bs != 4K out of experimental
>>    That feature is a pretty small niche though.
>>    The basis is already there from the bs < ps support for a while.
>>
>> - Remove 2K block size support
>>    That is too niche, considering how easy to trigger subpage routine
>>    with the larger data folio support, there is not much need for it.
>>
>> The following features can be moved out of experimental in v7.1:
>>
>> - Large data folios
>>    It's introduced in v6.17, but we still have a bug fix related for it
>>    in v6.19.
>>    If there is no new bug exposed I believe it's time to expose this
>>    feature to end users.
>>
>> - Shutdown and remove_bdev callbacks
>>    It's introduced in v6.19, but there is no major known bug exposed yet.
>>    Furthermore the remove_bdev callback, aka auto-shutdown/degradation
>>    when a device is missing, can affect end users.
>>
>>    Thus we want some feedbacks from early adopters.
>>
>> - Block size smaller than page size but not 4K support
>>    The requirement for 4K block size is purely artificial to reduce our
>>    test load.
>>    But since we're moving towards supporting all block sizes, the
>>    artifical limit can be lifted now.
> 
> Adding all of them at once feels a bit risky. I don't think that it has
> enough exposure and testing because of number of the possible
> combinations.
> 
> The shutdown is orthogonal to the rest so this can be enabled by
> default.

So can I add that shutdown one into for-next branch?

> For the rest the bs/ps is namely an ARM thing with the 64K
> pages,

Thus I'd say it shouldn't affect most end users (if any).

> and large folios is using an internal API in a new way.

That one has been there for testing for a while, and we have exposed 
bugs related to that (on x86_64).
(That's also why I tend to remove 2K block size, since we can reach the 
same result without subpage/2K bs on x86_64)

So it should have been tested by us.
Although I'm fine delaying this to be extra safe, I still prefer this to 
be enabled sooner than later (hopefully 7.2 merge window).

Thanks,
Qu

> Here I'd pick just one and make sure we have it covered by CI. I'm
> setting it up again on github actions but it's going slower than
> expected.