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

[Josef Bacik <josef@toxicpanda.com>]

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,

Josef