Re: [PATCH DRAFT] btrfs: RAID56J journal on-disk format draft

From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: dsterba@suse.cz, Qu Wenruo <wqu@suse.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH DRAFT] btrfs: RAID56J journal on-disk format draft
Date: Wed, 25 May 2022 17:35:37 +0800	[thread overview]
Message-ID: <b8cbcac2-7e8b-e0fd-67a9-8a782e0afe23@gmx.com> (raw)
In-Reply-To: <Yo32VXWO81PlccWH@infradead.org>

On 2022/5/25 17:26, Christoph Hellwig wrote:
> On Wed, May 25, 2022 at 05:13:11PM +0800, Qu Wenruo wrote:
>> The problem is, we can have partial write for RAID56, no matter if we
>> use NODATACOW or not.
>>
>> For example, we have a very typical 3 disks RAID5:
>>
>> 	0	32K	64K
>> Disk 1  |DDDDDDD|       |
>> Disk 2  |ddddddd|ddddddd|
>> Disk 3  |PPPPPPP|PPPPPPP|
>>
>>
>> D = old data, it's there for a while.
>> d = new data, we want to write.
>
> Oh.  I keep forgetting that the striping is entirely on the physіcal
> block basis and not logic block basis.  Which makes the whole idea
> of btrfs integrated raid5/6 not all that useful compared to just using
> mdraid :(

Yep, that's why I have to go the old journal way.

But you may want to explore the super awesome idea of raid stripe tree
from Johannes.

The idea is we introduce a new layer of logical addr -> internal mapping
-> physical addr.
By that, we get rid of the strict physical address requirement.

And when we update the new stripe, we just insert two new mapping for
(dddd), and two new mapping for the new (PPPPP).

If power loss happen, we still see the old internal mapping, and can get
the correct recovery.

But it still seems to have a lot of things to resolve for now.

Thanks,
Qu