Re: btrfs RAID5 or btrfs on md RAID5?

[DanglingPointer <danglingpointerexception@gmail.com>]

Just going back to the original question I posted...

Will the BTRFS project decide to fix once and for all RAID56 to fix the 
write-hole even if the result is a slower-latent result?

At least that would be a fully functional production ready offering as 
version 1.0?

Future optimisations and improvements on that version 1.0 will obviously 
happen for the life of BTRFS and linux which will improve the 
performance from the impact of adding whatever is needed to fix the 
write-hole.  Just like everything else!  At least everyone can say it is 
done, although slower now!  But feature complete!   Making it faster 
will then incrementally happen as it evolves like everything else.



On 22/10/25 06:32, Goffredo Baroncelli wrote:
> On 21/10/2025 18.45, Mark Harmstone wrote:
>> On 21/10/2025 4.53 pm, Christoph Anton Mitterer wrote:
>>> On Tue, 2025-10-21 at 16:46 +0100, Mark Harmstone wrote:
>>>> The brutal truth is probably that RAID5/6 is an idea whose time has
>>>> passed.
>>>> Storage is cheap enough that it doesn't warrant the added latency,
>>>> CPU time,
>>>> and complexity.
>>>
>>> That doesn't seem to be generally the case. We have e.g. large storage
>>> servers with 24x 22 TB HDDs.
>>>
>>> RAID6 is plenty enough redundancy for these, loosing 2 HDDs.
>>> RAID1 would loose half.
>>>
>>>
>>> Cheers,
>>> Chris.
>> So for every sector you want to write, you actually need to write three
>> and read 21. That seems a very quick way to wear out all those disks.
>> And then one starts operating more slowly, which slows down every 
>> write...
>
> Yes, it is true that the classic raid5/6 doesn't scale well when the 
> number
> of disks grows.
>
> However I still think that there is room to a different approach. Like 
> putting
> the redundancy inside the extent to avoid an RMW cycles. This and the
> fact that in BTRFS the extents are immutable, would avoid the slowness
> that you mention.
>
>> I'd still use RAID1 in this case.
>>
> This is faster, but also doesn't scale well (== expensive) when the 
> storage
>  size grows.
>
> BR
> G.Baroncelli
>