mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Johannes Thumshirn <Johannes.Thumshirn@wdc.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>, Qu Wenruo <wqu@suse.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 v8 03/11] btrfs: add support for inserting raid stripe extents
Date: Thu, 14 Sep 2023 19:36:53 +0930	[thread overview]
Message-ID: <2f9f3e43-8a4b-4dbd-9e10-2637bf7079ec@gmx.com> (raw)
In-Reply-To: <2ad7c49b-89ff-4f10-b671-6b2ba4ccbef7@wdc.com>



On 2023/9/14 19:21, Johannes Thumshirn wrote:
> On 14.09.23 11:25, Qu Wenruo wrote:
>>> +static int btrfs_insert_one_raid_extent(struct btrfs_trans_handle *trans,
>>> +				 int num_stripes,
>>> +				 struct btrfs_io_context *bioc)
>>> +{
>>> +	struct btrfs_fs_info *fs_info = trans->fs_info;
>>> +	struct btrfs_key stripe_key;
>>> +	struct btrfs_root *stripe_root = btrfs_stripe_tree_root(fs_info);
>>> +	u8 encoding = btrfs_bg_type_to_raid_encoding(bioc->map_type);
>>> +	struct btrfs_stripe_extent *stripe_extent;
>>> +	size_t item_size;
>>> +	int ret;
>>> +
>>> +	item_size = struct_size(stripe_extent, strides, num_stripes);
>>
>> I guess David has already pointed out this can be done at initialization
>> and make it const.
>
> Will do
>
>>
>>> +
>>> +	stripe_extent = kzalloc(item_size, GFP_NOFS);
>>> +	if (!stripe_extent) {
>>> +		btrfs_abort_transaction(trans, -ENOMEM);
>>> +		btrfs_end_transaction(trans);
>>> +		return -ENOMEM;
>>> +	}
>>> +
>>> +	btrfs_set_stack_stripe_extent_encoding(stripe_extent, encoding);
>>> +	for (int i = 0; i < num_stripes; i++) {
>>> +		u64 devid = bioc->stripes[i].dev->devid;
>>> +		u64 physical = bioc->stripes[i].physical;
>>> +		u64 length = bioc->stripes[i].length;
>>> +		struct btrfs_raid_stride *raid_stride =
>>> +						&stripe_extent->strides[i];
>>> +
>>> +		if (length == 0)
>>> +			length = bioc->size;
>>> +
>>> +		btrfs_set_stack_raid_stride_devid(raid_stride, devid);
>>> +		btrfs_set_stack_raid_stride_physical(raid_stride, physical);
>>> +		btrfs_set_stack_raid_stride_length(raid_stride, length);
>>> +	}
>>> +
>>> +	stripe_key.objectid = bioc->logical;
>>> +	stripe_key.type = BTRFS_RAID_STRIPE_KEY;
>>> +	stripe_key.offset = bioc->size;
>>> +
>>> +	ret = btrfs_insert_item(trans, stripe_root, &stripe_key, stripe_extent,
>>> +				item_size);
>>
>> Have you tested in near-real-world on how continous the RST items could
>> be for RAID0/RAID10?
>>
>> My concern here is, we may want to try our best to reduce the size of
>> RST, due to the 64K BTRFS_STRIPE_LEN.
>>
>
> There are two things I can do for it. First is trying to merge contiguus
> RST items

This is much easier, as the RST lookup code is already taking the length
into consideration, thus only the add path need some work.

Although I'm not sure how effective it would be in real world.
As if the merge rate is only 5%, then it barely makes a difference.

Maybe you don't need to implement a full merge in this version, but just
do some trace events to see the merge rate?

> and second make BTRFS_STRIPE_LEN a mkfs time constant instead
> of a compile time constant.

Please be very careful about this, we have quite some bitmap relying on
this. (IIRC RAID56 and scrub)

Currently unsigned long can only support up to 64 bits, thus the maximum
stripe length would be 256K, but I'm pretty sure there would be other
hidden traps somewhere else.

Otherwise the main workflow of RST looks good to me.

Thanks,
Qu
>
> But both can be done in a second step.
>
>>> +	switch (map_type & BTRFS_BLOCK_GROUP_PROFILE_MASK) {
>>> +	case BTRFS_BLOCK_GROUP_DUP:
>>> +	case BTRFS_BLOCK_GROUP_RAID1:
>>> +	case BTRFS_BLOCK_GROUP_RAID1C3:
>>> +	case BTRFS_BLOCK_GROUP_RAID1C4:
>>> +		ret = btrfs_insert_mirrored_raid_extents(trans, ordered_extent,
>>> +							 map_type);
>>> +		break;
>>> +	case BTRFS_BLOCK_GROUP_RAID0:
>>> +		ret = btrfs_insert_striped_raid_extents(trans, ordered_extent,
>>> +							map_type);
>>> +		break;
>>> +	case BTRFS_BLOCK_GROUP_RAID10:
>>> +		ret = btrfs_insert_striped_mirrored_raid_extents(trans, ordered_extent, map_type);
>>> +		break;
>>> +	default:
>>> +		ret = -EINVAL;
>>
>> Maybe we want to be a little more noisy?
>
> OK.
>

  reply	other threads:[~2023-09-14 10:07 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-11 12:52 [PATCH v8 00/11] btrfs: introduce RAID stripe tree Johannes Thumshirn
2023-09-11 12:52 ` [PATCH v8 01/11] btrfs: add raid stripe tree definitions Johannes Thumshirn
2023-09-11 21:00   ` Damien Le Moal
2023-09-12  6:09     ` Johannes Thumshirn
2023-09-12 20:32   ` David Sterba
2023-09-13  6:02     ` Johannes Thumshirn
2023-09-13 14:49       ` David Sterba
2023-09-13 14:57         ` Johannes Thumshirn
2023-09-13 16:06           ` David Sterba
2023-09-11 12:52 ` [PATCH v8 02/11] btrfs: read raid-stripe-tree from disk Johannes Thumshirn
2023-09-14  9:27   ` Qu Wenruo
2023-09-14  9:33     ` Johannes Thumshirn
2023-09-11 12:52 ` [PATCH v8 03/11] btrfs: add support for inserting raid stripe extents Johannes Thumshirn
2023-09-13 16:50   ` David Sterba
2023-09-13 16:57   ` David Sterba
2023-09-14  9:25   ` Qu Wenruo
2023-09-14  9:51     ` Johannes Thumshirn
2023-09-14 10:06       ` Qu Wenruo [this message]
2023-09-14 15:35         ` Johannes Thumshirn
2023-09-11 12:52 ` [PATCH v8 04/11] btrfs: delete stripe extent on extent deletion Johannes Thumshirn
2023-09-11 12:52 ` [PATCH v8 05/11] btrfs: lookup physical address from stripe extent Johannes Thumshirn
2023-09-14  9:18   ` Qu Wenruo
2023-09-14  9:45     ` Johannes Thumshirn
2023-09-14 14:16     ` Johannes Thumshirn
2023-09-11 12:52 ` [PATCH v8 06/11] btrfs: implement RST version of scrub Johannes Thumshirn
2023-09-13  9:51   ` Qu Wenruo
2023-09-13 16:59   ` David Sterba
2023-09-11 12:52 ` [PATCH v8 07/11] btrfs: zoned: allow zoned RAID Johannes Thumshirn
2023-09-12 20:49   ` David Sterba
2023-09-13  5:41     ` Johannes Thumshirn
2023-09-13 14:52       ` David Sterba
2023-09-13 14:59         ` Johannes Thumshirn
2023-09-11 12:52 ` [PATCH v8 08/11] btrfs: add raid stripe tree pretty printer Johannes Thumshirn
2023-09-12 20:42   ` David Sterba
2023-09-13  5:34     ` Johannes Thumshirn
2023-09-11 12:52 ` [PATCH v8 09/11] btrfs: announce presence of raid-stripe-tree in sysfs Johannes Thumshirn
2023-09-11 12:52 ` [PATCH v8 10/11] btrfs: add trace events for RST Johannes Thumshirn
2023-09-12 20:46   ` David Sterba
2023-09-11 12:52 ` [PATCH v8 11/11] btrfs: add raid-stripe-tree to features enabled with debug Johannes Thumshirn

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=2f9f3e43-8a4b-4dbd-9e10-2637bf7079ec@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=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=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®