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

From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Wang Yugui <wangyugui@e16-tech.com>, Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH DRAFT] btrfs: RAID56J journal on-disk format draft
Date: Wed, 1 Jun 2022 10:55:18 +0800	[thread overview]
Message-ID: <49fb1216-189d-8801-d134-596284f62f1f@gmx.com> (raw)
In-Reply-To: <20220601102532.D262.409509F4@e16-tech.com>

On 2022/6/1 10:25, Wang Yugui wrote:
> Hi,
>
>> On 2022/6/1 10:06, Wang Yugui wrote:
>>> Hi,
>>>
>>>> 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.
>>>
>>> Can we put this journal in a device just like 'mke2fs -O journal_dev'
>>> or 'mkfs.xfs -l logdev'?
>>>
>>> A fast & small journal device may help the performance.
>>
>> Then that lacks the ability to lose one device.
>>
>> The journal device must be there no matter what.
>>
>> Furthermore, this will still need a on-disk format change for a special type of device.
>
> If we save journal on every RAID56 HDD, it will always be very slow,
> because journal data is in a different place than normal data, so HDD
> seek is always happen?
>
> If we save journal on a device just like 'mke2fs -O journal_dev' or 'mkfs.xfs
> -l logdev', then this device just works like NVDIMM?  We may not need
> RAID56/RAID1 for journal data.

That device is the single point of failure. You lost that device, write
hole come again.

RAID56 can tolerant one or two device failures for sure.
Thus one point failure is against RAID56.

If one is not bothered with writehole, then they doesn't need any
journal at all.

Thanks,
Qu
>
> Best Regards
> Wang Yugui (wangyugui@e16-tech.com)
> 2022/06/01
>
>