From: David Sterba <dsterba@suse.cz>
To: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Cc: Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
David Sterba <dsterba@suse.com>, Christoph Hellwig <hch@lst.de>,
Naohiro Aota <naohiro.aota@wdc.com>, Qu Wenruo <wqu@suse.com>,
Damien Le Moal <dlemoal@kernel.org>,
linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v9 00/11] btrfs: introduce RAID stripe tree
Date: Thu, 14 Sep 2023 20:25:34 +0200 [thread overview]
Message-ID: <20230914182534.GD20408@twin.jikos.cz> (raw)
In-Reply-To: <20230914-raid-stripe-tree-v9-0-15d423829637@wdc.com>
On Thu, Sep 14, 2023 at 09:06:55AM -0700, Johannes Thumshirn wrote:
> Updates of the raid-stripe-tree are done at ordered extent write time to safe
> on bandwidth while for reading we do the stripe-tree lookup on bio mapping
> time, i.e. when the logical to physical translation happens for regular btrfs
> RAID as well.
>
> The stripe tree is keyed by an extent's disk_bytenr and disk_num_bytes and
> it's contents are the respective physical device id and position.
>
> For an example 1M write (split into 126K segments due to zone-append)
> rapido2:/home/johannes/src/fstests# xfs_io -fdc "pwrite -b 1M 0 1M" -c fsync /mnt/test/test
> wrote 1048576/1048576 bytes at offset 0
> 1 MiB, 1 ops; 0.0065 sec (151.538 MiB/sec and 151.5381 ops/sec)
>
> The tree will look as follows (both 128k buffered writes to a ZNS drive):
>
> RAID0 case:
> bash-5.2# btrfs inspect-internal dump-tree -t raid_stripe /dev/nvme0n1
> btrfs-progs v6.3
> raid stripe tree key (RAID_STRIPE_TREE ROOT_ITEM 0)
> leaf 805535744 items 1 free space 16218 generation 8 owner RAID_STRIPE_TREE
> leaf 805535744 flags 0x1(WRITTEN) backref revision 1
> checksum stored 2d2d2262
> checksum calced 2d2d2262
> fs uuid ab05cfc6-9859-404e-970d-3999b1cb5438
> chunk uuid c9470ba2-49ac-4d46-8856-438a18e6bd23
> item 0 key (1073741824 RAID_STRIPE_KEY 131072) itemoff 16243 itemsize 56
> encoding: RAID0
> stripe 0 devid 1 offset 805306368 length 131072
> stripe 1 devid 2 offset 536870912 length 131072
> total bytes 42949672960
> bytes used 294912
> uuid ab05cfc6-9859-404e-970d-3999b1cb5438
>
> RAID1 case:
> bash-5.2# btrfs inspect-internal dump-tree -t raid_stripe /dev/nvme0n1
> btrfs-progs v6.3
> raid stripe tree key (RAID_STRIPE_TREE ROOT_ITEM 0)
> leaf 805535744 items 1 free space 16218 generation 8 owner RAID_STRIPE_TREE
> leaf 805535744 flags 0x1(WRITTEN) backref revision 1
> checksum stored 56199539
> checksum calced 56199539
> fs uuid 9e693a37-fbd1-4891-aed2-e7fe64605045
> chunk uuid 691874fc-1b9c-469b-bd7f-05e0e6ba88c4
> item 0 key (939524096 RAID_STRIPE_KEY 131072) itemoff 16243 itemsize 56
> encoding: RAID1
> stripe 0 devid 1 offset 939524096 length 65536
> stripe 1 devid 2 offset 536870912 length 65536
> total bytes 42949672960
> bytes used 294912
> uuid 9e693a37-fbd1-4891-aed2-e7fe64605045
>
> A design document can be found here:
> https://docs.google.com/document/d/1Iui_jMidCd4MVBNSSLXRfO7p5KmvnoQL/edit?usp=sharing&ouid=103609947580185458266&rtpof=true&sd=true
Please also turn it to developer documentation file (in
btrfs-progs/Documentation/dev), it can follow the same structure.
>
> The user-space part of this series can be found here:
> https://lore.kernel.org/linux-btrfs/20230215143109.2721722-1-johannes.thumshirn@wdc.com
>
> Changes to v8:
> - Changed tracepoints according to David's comments
> - Mark on-disk structures as packed
> - Got rid of __DECLARE_FLEX_ARRAY
> - Rebase onto misc-next
> - Split out helpers for new btrfs_load_block_group_zone_info RAID cases
> - Constify declarations where possible
> - Initialise variables before use
> - Lower scope of variables
> - Remove btrfs_stripe_root() helper
> - Pick different BTRFS_RAID_STRIPE_KEY constant
> - Reorder on-disk encoding types to match the raid_index
> - And possibly more, please git range-diff the versions
> - Link to v8: https://lore.kernel.org/r/20230911-raid-stripe-tree-v8-0-647676fa852c@wdc.com
v9 will be added as topic branch to for-next, I did several style
changes so please send any updates as incrementals if needed.
next prev parent reply other threads:[~2023-09-14 18:25 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-14 16:06 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
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 ` David Sterba [this message]
2023-09-20 16:23 ` [PATCH v9 00/11] btrfs: introduce RAID stripe tree 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=20230914182534.GD20408@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=clm@fb.com \
--cc=dlemoal@kernel.org \
--cc=dsterba@suse.com \
--cc=hch@lst.de \
--cc=johannes.thumshirn@wdc.com \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=naohiro.aota@wdc.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
all inboxes | Powered by JetHome®