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

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

On 17/05/2022 09: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?
> 

That's the reason for my early RFC here.

I think both solutions have benefits and drawbacks. 

The stripe tree adds complexity, metadata (though at the moment only 16 
bytes per drive in the stripe per extent) and another address translation /
lookup layer, it adds the benefit of being always able to do CoW and close
the write-hole here. Also it can work with zoned devices and the Zone Append
write command.

The raid56j code will be simpler in the end I suspect, but it still doesn't
do full CoW and isn't Zone Append capable. Two factors that can't work on
zoned filesystems. And given that capacity drives will likely be more and more
zoned drives, even outside of the hyperscale sector, I see this problematic.

Both Qu and I are aware of each others patches and I would really like to get
the work converged here. The raid56j code for sure is a stop gap solution for
the users that already have a raid56 setup and want to get rid of the write
hole.

Thanks,
	Johannes