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

From: David Sterba <dsterba@suse.cz>
To: Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH DRAFT] btrfs: RAID56J journal on-disk format draft
Date: Tue, 24 May 2022 19:02:34 +0200	[thread overview]
Message-ID: <20220524170234.GW18596@twin.jikos.cz> (raw)
In-Reply-To: <f6679e0b681f9b1a74dfccbe05dcb5b6eb0878f6.1653372729.git.wqu@suse.com>

On Tue, May 24, 2022 at 02:13:47PM +0800, Qu Wenruo wrote:
> This is the draft version of the on-disk format for RAID56J journal.
> 
> The overall idea is, we have the following elements:
> 
> 1) A fixed header
>    Recording things like if the journal is clean or dirty, and how many
>    entries it has.
> 
> 2) One or at most 127 entries
>    Each entry will point to a range of data in the per-device reserved
>    range.
> 
> 3) Data in the remaining reserved space
> 
> The write time and recovery workflow is embedded into the on-disk
> format.
> 
> Unfortunately we will not have any optimization for the RAID56J, every
> write will be journaled, no exception.
> 
> Furthermore due to current write behavior of RAID56, we always submit a
> full 64K stripe no matter what, we have every limited size for the data
> part (at most 15 64K stripe).
> 
> So far, I don't believe we will have a fast RAID56J at all.

Well, that does not sound encouraging. One option discussed in the past
how to fix the write hole was to always do full RMW cycle. Having a "not
fast journal at all" would require a format change and have probably a
comparable performance drop.