From: Josef Bacik <josef@toxicpanda.com>
To: Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
Cc: Johannes Thumshirn <jth@kernel.org>, Chris Mason <clm@fb.com>,
David Sterba <dsterba@suse.com>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 1/5] btrfs: replace stripe extents
Date: Mon, 1 Jul 2024 16:34:51 -0400 [thread overview]
Message-ID: <20240701203451.GB510298@perftesting> (raw)
In-Reply-To: <0819d7c2-bb91-4dea-ac20-09191c0b2240@wdc.com>
On Mon, Jul 01, 2024 at 03:08:22PM +0000, Johannes Thumshirn wrote:
> On 01.07.24 15:58, Josef Bacik wrote:
> > On Mon, Jul 01, 2024 at 12:25:15PM +0200, Johannes Thumshirn wrote:
> >> From: Johannes Thumshirn <johannes.thumshirn@wdc.com>
> >>
> >> If we can't insert a stripe extent in the RAID stripe tree, because
> >> the key that points to the specific position in the stripe tree is
> >> already existing, we have to remove the item and then replace it by a
> >> new item.
> >>
> >> This can happen for example on device replace operations.
> >>
> >> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
> >> ---
> >> fs/btrfs/raid-stripe-tree.c | 34 ++++++++++++++++++++++++++++++++++
> >> 1 file changed, 34 insertions(+)
> >>
> >> diff --git a/fs/btrfs/raid-stripe-tree.c b/fs/btrfs/raid-stripe-tree.c
> >> index e6f7a234b8f6..3020820dd6e2 100644
> >> --- a/fs/btrfs/raid-stripe-tree.c
> >> +++ b/fs/btrfs/raid-stripe-tree.c
> >> @@ -73,6 +73,37 @@ int btrfs_delete_raid_extent(struct btrfs_trans_handle *trans, u64 start, u64 le
> >> return ret;
> >> }
> >>
> >> +static int replace_raid_extent_item(struct btrfs_trans_handle *trans,
> >> + struct btrfs_key *key,
> >> + struct btrfs_stripe_extent *stripe_extent,
> >> + const size_t item_size)
> >> +{
> >> + struct btrfs_fs_info *fs_info = trans->fs_info;
> >> + struct btrfs_root *stripe_root = fs_info->stripe_root;
> >> + struct btrfs_path *path;
> >> + int ret;
> >> +
> >> + path = btrfs_alloc_path();
> >> + if (!path)
> >> + return -ENOMEM;
> >> +
> >> + ret = btrfs_search_slot(trans, stripe_root, key, path, -1, 1);
> >> + if (ret)
> >> + goto err;
> >
> > This will leak 1 and we'll get an awkward btrfs_abort_transaction() call. This
> > should be
> >
> > if (ret) {
> > ret = (ret == 1) ? -ENOENT : ret;
> > goto err;
> > }
> >
> > or whatever. Thanks,
>
> I wonder why I've never seen this in my testing. Could it be, that due
> to the fact that btrfs_insert_item() returns -EEXIST on the same
> key.objectid, we're more or less guaranteed it'll exist.
Yeah it's fine in the way it is currently, but if anything changes in the future
we're going to figure it out and be super sad we didn't just handle it right in
the first place. Thanks,
Josef
next prev parent reply other threads:[~2024-07-01 20:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-01 10:25 [PATCH v3 0/5] btrfs: rst: updates for RAID stripe tree Johannes Thumshirn
2024-07-01 10:25 ` [PATCH v3 1/5] btrfs: replace stripe extents Johannes Thumshirn
2024-07-01 13:57 ` Josef Bacik
2024-07-01 15:08 ` Johannes Thumshirn
2024-07-01 20:34 ` Josef Bacik [this message]
2024-07-01 20:37 ` Josef Bacik
2024-07-02 5:41 ` Johannes Thumshirn
2024-07-01 10:25 ` [PATCH v3 2/5] btrfs: split RAID stripes on deletion Johannes Thumshirn
2024-07-01 14:07 ` Josef Bacik
2024-07-03 15:47 ` Johannes Thumshirn
2024-07-01 10:25 ` [PATCH v3 3/5] btrfs: stripe-tree: add selftests Johannes Thumshirn
2024-07-01 14:08 ` Josef Bacik
2024-07-01 15:09 ` Johannes Thumshirn
2024-07-01 10:25 ` [PATCH v3 4/5] btrfs: don't hold dev_replace rwsem over whole of btrfs_map_block Johannes Thumshirn
2024-07-01 14:13 ` Josef Bacik
2024-07-01 10:25 ` [PATCH v3 5/5] btrfs: rst: don't print tree dump in case lookup fails Johannes Thumshirn
2024-07-01 14:12 ` Josef Bacik
2024-07-01 15:03 ` 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=20240701203451.GB510298@perftesting \
--to=josef@toxicpanda.com \
--cc=Johannes.Thumshirn@wdc.com \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=jth@kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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