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

Johannes Thumshirn
2022-05-16T15:47:48Z

On 16/05/2022 17:10, Josef Bacik wrote:
> On Mon, May 16, 2022 at 03:04:35PM +0000, Johannes Thumshirn wrote:
>> On 16/05/2022 16:58, Josef Bacik wrote:
>>> On Mon, May 16, 2022 at 07:31:35AM -0700, 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.
>>>>
>>>
>>> This is hard to talk about without seeing the code to add the raid extents and
>>> such. Reading it makes sense, but I don't know how often the stripes are meant
>>> to change. Are they static once they're allocated, like dev extents? I can't
>>> quite fit in my head the relationship with the rest of the allocation system.
>>> Are they coupled with the logical extent that gets allocated? Or are they
>>> coupled with the dev extent? Are they somewhere in between?
>>
>> The stripe extents have a 1:1 relationship file the file-extents, i.e:
>>
>> stripe_extent_key.objectid = btrfs_file_extent_item.disk_bytenr;
>> stripe_extent_type = BTRFS_RAID_STRIPE_EXTENT;
>> stripe_extent_offset = btrfs_file_extent_item.disk_num_bytes;
>>
>>
>>> Also I realize this is an RFC, but we're going to need some caching for reads so
>>> we're not having to do a tree search on every IO with the RAID stripe tree in
>>> place.
>>
>> Do we really need to do caching of stripe tree entries? They're read, once the
>> corresponding btrfs_file_extent_item is read from disk, which then gets cached
>> in the page cache. Every override is cached in the page cache as well.
>>
>> If we're flushing the cache, we need to re-read both, the file_extent_item and
>> the stripe extents.
>
> Yup ok if we're 1:1 with the file-extents then we don't want the whole tree
> striped.
>
> Since we're 1:1 with the file-extents please make the stripe tree follow the
> same convention as the global roots, at least put the load code in the same area
> as the csum/fst/extent tree, if your stuff gets merged and turned on before
> extnet tree v2 it'll be easier for me to adapt it. Thanks,

Sure. I know that there once will be the need to have meta-data in the RST, but
then page cache should do the trick for as us well, as it's hanging off the btree
inode, isn't it?