Re: [RFC PATCH] btrfs: Write as many copies as possible if the current RAID1 profile is unreachable

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

在 2026/8/13 03:05, Logan Finley 写道:
> On Wed, Aug 12, 2026 at 09:02:24AM +0930, Qu Wenruo wrote:
>>> I'm not sure of a good way to fill up the System and Metadata block groups
>>> enough to trigger a new chunk to be allocated, so I wasn't able to see
>>> whether they also allocate "single"-profile chunks.
>>
>> For meta, go fill a subvolume with inlined data, that will easily bump up
>> the metadata usage.
>>
>> For system it's harder, but you can still use fallocate to take a lot of
>> space, which will trigger new chunk allocation that will increase system
>> usage.
>> But it's very hard if your fs has limited space.
>>
> 
> I was able to get a "single" profile metadata chunk to be allocated using
> inline data. I don't think I have enough storage to do the same with
> the system block group, but I'll wager the behavior would be the same.
> 
>>> This (admittedly naive) patch modifies this behavior so that the RAID1
>>> family of profiles writes as many copies as possible in a degraded state
>>> when there are not enough disks present to write data in the configured
>>> RAID profile.
>>>
>>> Signed-off-by: Logan Finley <logan_finley@selinc.com>
>>> ---
>>> What I'm looking for is feedback on whether this sort of patch is
>>> desired upstream, whether the approach is valid, and whether or not
>>> there are any gotchas I may have missed in the implementation.
>>
>> I think this downgrade from RAID1C4 to C3/C2 and from C3 to C2 is safe, and
>> it's a good middle ground solution.
>>
>> Although it has the side effect that there will be new RAID1* profiles which
>> will require balance to remove after the missing device is dealt with.
> 
> Good to know, thank you. I think for now we'll go with maintaining this
> mid-term patch internally, since it seems to do what we need. You're right
> that it requires a balance be performed once the missing disk is taken care
> of, but I can live with that.
> 
>> The root problem is in how we handle chunk allocation in degraded mode.
>> When a device is missing, it's very instinctive to assume we should not use
>> that device for new chunks.
>>
>> But that may not be the case, we may still want to allocate chunk on that
>> missing device, and rely on the chunk's mirrors/duplications to handle it.
>>
>> There will be extra problems involved for using such missing device, e.g. we
>> should not use the missing device for profiles without duplication on other
>> devices, like SINGLE/DUP on that missing device.
>>
>> In the long run, that would allow us to still use whatever profile even if
>> there is a missing device, and requires no extra balance after all devices
>> are online again.
>>
>>
>> Now the question is, should we go the long-term solution directly (if some
>> one is going to work on it), or go the middle ground first?
> 
> In my free time I would like to spend some time working on the long-term
> solution you proposed and eventually send it upstream.

After some quick digging, the blockage for the long term solution is 
that, we can no longer consider a device RW status as a simple binary.

E.g. a missing device can still be considered as allocation source for 
new chunks as long as missing devices do not exceed the tolerance.
But we should not try to read from such missing device either.

This will change the device management code quite a lot, so I do not 
expect the long term solution to be easy.

With that said, I think your RFC patch would be good to be merged upstream.

Reviewed-by: Qu Wenruo <wqu@suse.com>

I guess most btrfs developers are on vacation, so I'll leave this patch 
for more reviews before pushing it into for-next.

Thanks,
Qu

> 
> Thanks,
> Logan Finley
>