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

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 <[email protected]>
> > ---
> > 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.

Thanks,
Logan Finley