[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <783233a5-dbf5-402d-9670-8e2a7ee421c5@wdc.com>
Date: Fri, 15 Sep 2023 10:46:12 +0000
From: Johannes Thumshirn <Johannes.Thumshirn@....com>
To: Qu Wenruo <quwenruo.btrfs@....com>, Qu Wenruo <wqu@...e.com>,
Chris Mason <clm@...com>, Josef Bacik <josef@...icpanda.com>,
David Sterba <dsterba@...e.com>
CC: Christoph Hellwig <hch@....de>,
Naohiro Aota <Naohiro.Aota@....com>,
Damien Le Moal <dlemoal@...nel.org>,
"linux-btrfs@...r.kernel.org" <linux-btrfs@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v9 01/11] btrfs: add raid stripe tree definitions
On 15.09.23 12:34, Qu Wenruo wrote:
>> [snip]
>>
>> item 0 key (XXXXXX RAID_STRIPE_KEY 32768) itemoff XXXXX itemsize 32
>> encoding: RAID0
>> stripe 0 devid 1 physical XXXXXXXXX length 32768
>> item 1 key (XXXXXX RAID_STRIPE_KEY 131072) itemoff XXXXX
>> itemsize 80
> Maybe you want to put the whole RAID_STRIPE_KEY definition into the headers.
>
> In fact my initial assumption of such case would be something like this:
>
> item 0 key (X+0 RAID_STRIPE 32K)
> stripe 0 devid 1 physical XXXXX len 32K
> item 1 key (X+32K RAID_STRIPE 32K)
> stripe 0 devid 1 physical XXXXX + 32K len 32K
> item 2 key (X+64K RAID_STRIPE 64K)
> stripe 0 devid 2 physical YYYYY len 64K
> item 3 key (X+128K RAID_STRIPE 32K)
> stripe 0 devid 1 physical XXXXX + 64K len 32K
> ...
>
> AKA, each RAID_STRIPE_KEY would only contain a continous physical stripe.
> And in above case, item 0 and item 1 can be easily merged, also length
> can be removed.
>
> And this explains why the lookup code is more complex than I initially
> thought.
>
> BTW, would the above layout make the code a little easier?
> Or is there any special reason for the existing one layout?
It would definitely make the code easier to the cost of more items. But
of cause smaller items, as we can get rid of the stride length.
Let me think about it.
Powered by blists - more mailing lists