Re: [RFC ONLY 0/8] btrfs: introduce raid-stripe-tree

[Johannes Thumshirn <Johannes.Thumshirn@wdc.com>]

On 17/05/2022 09:32, Qu Wenruo wrote:
> 
> 
> On 2022/5/17 15:23, Nikolay Borisov wrote:
>>
>>
>> On 16.05.22 г. 17:31 ч., Johannes Thumshirn wrote:
>>> Introduce a raid-stripe-tree to record writes in a RAID environment.
>>>
>>> In essence this adds another address translation layer between the
>>> logical
>>> and the physical addresses in btrfs and is designed to close two gaps.
>>> The
>>> first is the ominous RAID-write-hole we suffer from with RAID5/6 and the
>>> second one is the inability of doing RAID with zoned block devices due
>>> to the
>>> constraints we have with REQ_OP_ZONE_APPEND writes.
>>>
>>> Thsi is an RFC/PoC only which just shows how the code will look like
>>> for a
>>> zoned RAID1. Its sole purpose is to facilitate design reviews and is not
>>> intended to be merged yet. Or if merged to be used on an actual
>>> file-system.
>>>
>>> Johannes Thumshirn (8):
>>>    btrfs: add raid stripe tree definitions
>>>    btrfs: move btrfs_io_context to volumes.h
>>>    btrfs: read raid-stripe-tree from disk
>>>    btrfs: add boilerplate code to insert raid extent
>>>    btrfs: add code to delete raid extent
>>>    btrfs: add code to read raid extent
>>>    btrfs: zoned: allow zoned RAID1
>>>    btrfs: add raid stripe tree pretty printer
>>>
>>>   fs/btrfs/Makefile               |   2 +-
>>>   fs/btrfs/ctree.c                |   1 +
>>>   fs/btrfs/ctree.h                |  29 ++++
>>>   fs/btrfs/disk-io.c              |  12 ++
>>>   fs/btrfs/extent-tree.c          |   9 ++
>>>   fs/btrfs/file.c                 |   1 -
>>>   fs/btrfs/print-tree.c           |  21 +++
>>>   fs/btrfs/raid-stripe-tree.c     | 251 ++++++++++++++++++++++++++++++++
>>>   fs/btrfs/raid-stripe-tree.h     |  39 +++++
>>>   fs/btrfs/volumes.c              |  44 +++++-
>>>   fs/btrfs/volumes.h              |  93 ++++++------
>>>   fs/btrfs/zoned.c                |  39 +++++
>>>   include/uapi/linux/btrfs.h      |   1 +
>>>   include/uapi/linux/btrfs_tree.h |  17 +++
>>>   14 files changed, 509 insertions(+), 50 deletions(-)
>>>   create mode 100644 fs/btrfs/raid-stripe-tree.c
>>>   create mode 100644 fs/btrfs/raid-stripe-tree.h
>>>
>>
>>
>> So if we choose to go with raid stripe tree this means we won't need the
>> raid56j code that Qu is working on ? So it's important that these two
>> work streams are synced so we don't duplicate effort, right?
> 
> I believe the stripe tree is going to change the definition of RAID56.
> 
> It's no longer strict RAID56, as it doesn't contain the fixed device
> rotation, thus it's kinda between RAID4 and RAID5.

Well I think it can still contain the device rotation. The stripe tree only
records the on-disk location of each sub-stripe, after it has been written.
The data placement itself doesn't get changed at all. But for this to work,
there's still a lot to do. There's also other plans I have. IIUC btrfs raid56
uses all available drives in a raid set, while raid1,10,0 etc permute the
drives the data is placed. Which is a way better solution IMHO as it reduces
rebuild stress in case we need to do rebuild. Given we have two digit TB
drives these days, rebuilds do a lot of IO which can cause more drives failing
while rebuilding.

> Personally speaking, I think both features can co-exist, especially the
> raid56 stripe tree may need extra development and review, since the
> extra translation layer is a completely different monster when comes to
> RAID56.
> 
> Don't get me wrong, I like stripe-tree too, the only problem is it's
> just too new, thus we may want a backup plan.
> 

Exactly, as I already wrote to Nikolay, raid56j is for sure the simpler
solution and some users might even prefer it for this reason.

Byte,
	Johannes