From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yb1-f174.google.com (mail-yb1-f174.google.com [209.85.219.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 918335FEED for ; Wed, 21 Aug 2024 17:15:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724260549; cv=none; b=bYkeIG/1MC7TUZcuQPeEarWDqCeR+p+Ye0tEkDF+5pR3BwhLHAL+VyGXVFtKhCx7liD6lEL6DYvHdV/gXNpwkVpDF6DcmO1n2GRogjz57pg3aqiy/AYat3Z79Y/R+kOMKDXYq2YNU8USE2wzgAlr0eM3A+2UTTpHO393uewgFyM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724260549; c=relaxed/simple; bh=CXUZMTfR+ctY64S4wLWT95QPyMLbTeVBl9F9I/RbGzE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=AXEJYVu6gcmwJIqRA4ECFQPFplX86xJ08SkLJL98BWkL3hgfWwdhikChpt4qmnqySs29rpoW1FevzqFHVl3Pavn61gzaEBi7e5FAasQe729P5gVM9Yc6S1Rl4j405xHQCWTEvZRYCXWmfJoUUKsvYycZp5qIqsj0mp7UxH5z+as= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=toxicpanda.com; spf=none smtp.mailfrom=toxicpanda.com; dkim=pass (2048-bit key) header.d=toxicpanda-com.20230601.gappssmtp.com header.i=@toxicpanda-com.20230601.gappssmtp.com header.b=oKf/3zOm; arc=none smtp.client-ip=209.85.219.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=toxicpanda.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=toxicpanda.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=toxicpanda-com.20230601.gappssmtp.com header.i=@toxicpanda-com.20230601.gappssmtp.com header.b="oKf/3zOm" Received: by mail-yb1-f174.google.com with SMTP id 3f1490d57ef6-e16582cb9f9so838073276.0 for ; Wed, 21 Aug 2024 10:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20230601.gappssmtp.com; s=20230601; t=1724260546; x=1724865346; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=nnz/9bRfV4eCE7Gj4szszeqMiVZN0a+HcNTY9eR9KK4=; b=oKf/3zOmfbmjL28EvUdVtlIBWWa0T7hBI2wPbqeoCXt8d7SW+azEVy+zwq8r67P5D8 NP+ycpstC1ugfFMDVZFKxfGbDPsGz24jgMBI1E5Ik7PHcRPRVL74L9NWIQktPAniNIF/ 1BpJ9P9tSYaMaZANul2tHW9Vy3o22NDJPW9f6wx+g/O05WcLE/c2YWFHiHD4i9sJzJaf 0x4tIGXx90lQlRVnnC91UxWeLUgFPYN8FjQBa4GGHThyhn+V6HlEqUtTgNoBhOtTgHhD 7+VzESlA1jMt25bmYdWULsVsam7X0pnk0qiya/WyTar02/n9cTvzt7Ll7SOPAExT24RZ i0wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724260546; x=1724865346; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=nnz/9bRfV4eCE7Gj4szszeqMiVZN0a+HcNTY9eR9KK4=; b=F5gEVEI9HKoDfflBvUkaT8DgKH+b3bGmhEZwTTOSQFzkuRBAWmRlGY1LhL2oWZQpTa d5fHo02RQUdVXY2DS44O6mAmghJMWaSkJTzC6/+G7TjrlVVx9klqJgrJvZ0ixuWUT9ye sdRzrpkFpye0tCSy6yhIbr7JtUwLepTSFuoFoy8KyU6py4cLDZzW0oqcTzHL7HkTs55H NFZwDqg+g3/K2PqZBQea1NNLIDbx04Z2gifw1C6nI3GU2fJR5r3fkDaNBcujXAU43bQ+ eFeQ5/A6s9kTCOETrTXDnN54thj+gZMmQFOovCXHnM+nHVlIR7u+fUSxJkWVhJRJ8RKG BJTg== X-Forwarded-Encrypted: i=1; AJvYcCUeA92HyYhvzFrvCOxwxil58OclSkgMYTogWEpvL0hP+4WjSv/vFwKS+J5Z9aOCxL3Y3Vq/WSEjrvSCN1w=@vger.kernel.org X-Gm-Message-State: AOJu0Yz/7aY6gh6VREclayRpdHgYPtLzJ40G/l8tO67dITIai6YrhFYI pysfQHvD1F3B09pb7NDxV57n+wA/pOL5hePQLsO8oKgbbnyiMFgmoiapMpxk+w8= X-Google-Smtp-Source: AGHT+IH/k3XRCeN1yFBxEuJh7fGjWPwPN5ESb1A5WZiWw5eWEfWhdrnOx6PA8oM/9J1Kjpjv36J3lw== X-Received: by 2002:a05:6902:a90:b0:e11:446b:d43b with SMTP id 3f1490d57ef6-e17762890a5mr359370276.16.1724260546569; Wed, 21 Aug 2024 10:15:46 -0700 (PDT) Received: from localhost (syn-076-182-020-124.res.spectrum.com. [76.182.20.124]) by smtp.gmail.com with ESMTPSA id 3f1490d57ef6-e1172006e05sm2943867276.43.2024.08.21.10.15.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Aug 2024 10:15:46 -0700 (PDT) Date: Wed, 21 Aug 2024 13:15:45 -0400 From: Josef Bacik To: Johannes Thumshirn Cc: Chris Mason , David Sterba , "open list:BTRFS FILE SYSTEM" , open list , Johannes Thumshirn Subject: Re: [PATCH] btrfs: stripe-tree: correctly truncate stripe extents on delete Message-ID: <20240821171545.GA1998418@perftesting> References: <20240820143434.25332-1-jth@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240820143434.25332-1-jth@kernel.org> On Tue, Aug 20, 2024 at 04:34:33PM +0200, Johannes Thumshirn wrote: > From: Johannes Thumshirn > > In our CI system, we're seeing the following ASSERT()ion to trigger when > running RAID stripe-tree tests on non-zoned devices: > > assertion failed: found_start >= start && found_end <= end, in fs/btrfs/raid-stripe-tree.c:64 > > This ASSERT()ion triggers, because for the initial design of RAID stripe-tree, > I had the "one ordered-extent equals one bio" rule of zoned btrfs in mind. > > But for a RAID stripe-tree based system, that is not hosted on a zoned > storage device, but on a regular device this rule doesn't apply. > > So in case the range we want to delete starts in the middle of the > previous item, grab the item and "truncate" it's length. That is, subtract > the deleted portion from the key's offset. > > In case the range to delete ends in the middle of an item, we have to > adjust both the item's key as well as the stripe extents. > > Signed-off-by: Johannes Thumshirn > --- > fs/btrfs/raid-stripe-tree.c | 50 ++++++++++++++++++++++++++++++++++++- > 1 file changed, 49 insertions(+), 1 deletion(-) > > diff --git a/fs/btrfs/raid-stripe-tree.c b/fs/btrfs/raid-stripe-tree.c > index 4c859b550f6c..c8365d14271f 100644 > --- a/fs/btrfs/raid-stripe-tree.c > +++ b/fs/btrfs/raid-stripe-tree.c > @@ -61,7 +61,55 @@ int btrfs_delete_raid_extent(struct btrfs_trans_handle *trans, u64 start, u64 le > trace_btrfs_raid_extent_delete(fs_info, start, end, > found_start, found_end); > > - ASSERT(found_start >= start && found_end <= end); > + if (found_start < start) { > + struct btrfs_key prev; > + u64 diff = start - found_start; > + > + ret = btrfs_previous_item(stripe_root, path, start, > + BTRFS_RAID_STRIPE_KEY); This is only safe if we're not path->slots[0] == 0, otherwise we'll do btrfs_prev_leaf(), which doesn't modify anything, adn then we'll be in trouble. If this is safe then a comment indicating why we expect this to only back up one slot, and maybe an ASSERT(path->slots[0] > 0); before the btrfs_previous_item to make sure we don't screw this up later. Thanks, Josef