linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>, Qu Wenruo <wqu@suse.com>,
	Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
	David Sterba <dsterba@suse.com>
Cc: Christoph Hellwig <hch@lst.de>,
	Naohiro Aota <Naohiro.Aota@wdc.com>,
	Damien Le Moal <dlemoal@kernel.org>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v9 01/11] btrfs: add raid stripe tree definitions
Date: Fri, 15 Sep 2023 10:46:12 +0000	[thread overview]
Message-ID: <783233a5-dbf5-402d-9670-8e2a7ee421c5@wdc.com> (raw)
In-Reply-To: <e2b069ba-deff-4cfc-992e-ad8e1d9b6f02@gmx.com>

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.

  reply	other threads:[~2023-09-15 10:46 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-14 16:06 [PATCH v9 00/11] btrfs: introduce RAID stripe tree Johannes Thumshirn
2023-09-14 16:06 ` [PATCH v9 01/11] btrfs: add raid stripe tree definitions Johannes Thumshirn
2023-09-15  0:22   ` Qu Wenruo
2023-09-15  0:26     ` Qu Wenruo
2023-09-15  9:55       ` Johannes Thumshirn
2023-09-15 10:33         ` Qu Wenruo
2023-09-15 10:46           ` Johannes Thumshirn [this message]
2023-10-02  9:32           ` Johannes Thumshirn
2023-09-14 16:06 ` [PATCH v9 02/11] btrfs: read raid-stripe-tree from disk Johannes Thumshirn
2023-09-14 16:06 ` [PATCH v9 03/11] btrfs: add support for inserting raid stripe extents Johannes Thumshirn
2023-09-14 18:07   ` David Sterba
2023-09-15 10:03     ` Geert Uytterhoeven
2023-09-14 18:10   ` David Sterba
2023-09-15  0:55   ` Qu Wenruo
2023-09-19 12:13     ` Johannes Thumshirn
2023-09-14 16:06 ` [PATCH v9 04/11] btrfs: delete stripe extent on extent deletion Johannes Thumshirn
2023-09-14 16:07 ` [PATCH v9 05/11] btrfs: lookup physical address from stripe extent Johannes Thumshirn
2023-09-14 17:57   ` David Sterba
2023-09-14 16:07 ` [PATCH v9 06/11] btrfs: implement RST version of scrub Johannes Thumshirn
2023-09-15  0:58   ` Qu Wenruo
2023-09-15 14:11     ` David Sterba
2023-09-14 16:07 ` [PATCH v9 07/11] btrfs: zoned: allow zoned RAID Johannes Thumshirn
2023-09-14 17:59   ` David Sterba
2023-09-14 16:07 ` [PATCH v9 08/11] btrfs: add raid stripe tree pretty printer Johannes Thumshirn
2023-09-14 16:07 ` [PATCH v9 09/11] btrfs: announce presence of raid-stripe-tree in sysfs Johannes Thumshirn
2023-09-14 16:07 ` [PATCH v9 10/11] btrfs: add trace events for RST Johannes Thumshirn
2023-09-14 16:07 ` [PATCH v9 11/11] btrfs: add raid-stripe-tree to features enabled with debug Johannes Thumshirn
2023-09-14 18:25 ` [PATCH v9 00/11] btrfs: introduce RAID stripe tree David Sterba
2023-09-20 16:23   ` David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=783233a5-dbf5-402d-9670-8e2a7ee421c5@wdc.com \
    --to=johannes.thumshirn@wdc.com \
    --cc=Naohiro.Aota@wdc.com \
    --cc=clm@fb.com \
    --cc=dlemoal@kernel.org \
    --cc=dsterba@suse.com \
    --cc=hch@lst.de \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.com \
    --cc=wqu@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).