From: Boris Burkov <boris@bur.io>
To: linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: [PATCH v4 12/18] btrfs: inline owner ref lookup helper
Date: Wed, 26 Jul 2023 13:38:39 -0700 [thread overview]
Message-ID: <c43550d1d5068ca8a596704bcd25d2ec1ea6f3bb.1690403768.git.boris@bur.io> (raw)
In-Reply-To: <cover.1690403768.git.boris@bur.io>
Inline ref parsing is a bit tricky and relies on a decent amount of
implicit information, so I think it is beneficial to have a helper
function for reading the owner ref, if only to "document" the format,
along with the write path.
The main subtlety of note which I was missing by open-coding this was
that it is important to check whether or not inline refs are present
*at all*. i.e., if we are writing out a new extent under squotas, we
will always use a big enough item for the inline ref and have it.
However, it is possible that some random item predating squotas will not
have any inline refs. In that case, trying to read the "type" field of
the first inline ref will just be reading garbage in the form of
whatever is in the next item.
This will be used by the extent free-ing path, which looks up data
extent owners as well as a relocation path which needs to grab the owner
before relocating an extent.
Signed-off-by: Boris Burkov <boris@bur.io>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
---
fs/btrfs/extent-tree.c | 51 ++++++++++++++++++++++++++++++++++++++++++
fs/btrfs/extent-tree.h | 3 +++
2 files changed, 54 insertions(+)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index d3b09e2269b0..9b44fb85eed4 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -2804,6 +2804,57 @@ int btrfs_finish_extent_commit(struct btrfs_trans_handle *trans)
return 0;
}
+/*
+ * Helper to parse an extent item's inline extents looking for a simple
+ * quotas owner ref.
+ *
+ * @fs_info - the btrfs_fs_info for this mount
+ * @leaf - a leaf in the extent tree containing the extent item
+ * @slot - the slot in the leaf where the extent item is found
+ *
+ * Returns the objectid of the root that originally allocated the extent item
+ * if the inline owner ref is expected and present, otherwise 0.
+ *
+ * If an extent item has an owner ref item, it will be the first
+ * inline ref item. Therefore the logic is to check whether there are
+ * any inline ref items, then check the type of the first one.
+ *
+ */
+u64 btrfs_get_extent_owner_root(struct btrfs_fs_info *fs_info,
+ struct extent_buffer *leaf,
+ int slot)
+{
+ struct btrfs_extent_item *ei;
+ struct btrfs_extent_inline_ref *iref;
+ struct btrfs_extent_owner_ref *oref;
+ unsigned long ptr;
+ unsigned long end;
+ int type;
+
+ if (!btrfs_fs_incompat(fs_info, SIMPLE_QUOTA))
+ return 0;
+
+ ei = btrfs_item_ptr(leaf, slot, struct btrfs_extent_item);
+ ptr = (unsigned long)(ei + 1);
+ end = (unsigned long)ei + btrfs_item_size(leaf, slot);
+
+ /* No inline ref items of any kind, can't check type */
+ if (ptr == end)
+ return 0;
+
+ iref = (struct btrfs_extent_inline_ref *)ptr;
+ type = btrfs_get_extent_inline_ref_type(leaf, iref, BTRFS_REF_TYPE_ANY);
+
+ /* We found an owner ref, get the root out of it */
+ if (type == BTRFS_EXTENT_OWNER_REF_KEY) {
+ oref = (struct btrfs_extent_owner_ref *)(&iref->offset);
+ return btrfs_extent_owner_ref_root_id(leaf, oref);
+ }
+
+ /* We have inline refs, but not an owner ref */
+ return 0;
+}
+
static int do_free_extent_accounting(struct btrfs_trans_handle *trans,
u64 bytenr, u64 num_bytes, bool is_data)
{
diff --git a/fs/btrfs/extent-tree.h b/fs/btrfs/extent-tree.h
index b9e148adcd28..7c27652880a2 100644
--- a/fs/btrfs/extent-tree.h
+++ b/fs/btrfs/extent-tree.h
@@ -141,6 +141,9 @@ int btrfs_set_disk_extent_flags(struct btrfs_trans_handle *trans,
struct extent_buffer *eb, u64 flags);
int btrfs_free_extent(struct btrfs_trans_handle *trans, struct btrfs_ref *ref);
+u64 btrfs_get_extent_owner_root(struct btrfs_fs_info *fs_info,
+ struct extent_buffer *leaf,
+ int slot);
int btrfs_free_reserved_extent(struct btrfs_fs_info *fs_info,
u64 start, u64 len, int delalloc);
int btrfs_pin_reserved_extent(struct btrfs_trans_handle *trans, u64 start, u64 len);
--
2.41.0
next prev parent reply other threads:[~2023-07-26 20:41 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-26 20:38 [PATCH v4 00/18] btrfs: simple quotas Boris Burkov
2023-07-26 20:38 ` [PATCH v4 01/18] btrfs: introduce quota mode Boris Burkov
2023-07-26 20:38 ` [PATCH v4 02/18] btrfs: add new quota mode for simple quotas Boris Burkov
2023-07-26 20:38 ` [PATCH v4 03/18] btrfs: expose quota mode via sysfs Boris Burkov
2023-07-26 20:38 ` [PATCH v4 04/18] btrfs: add simple_quota incompat feature to sysfs Boris Burkov
2023-07-26 20:38 ` [PATCH v4 05/18] btrfs: flush reservations during quota disable Boris Burkov
2023-07-26 20:38 ` [PATCH v4 06/18] btrfs: create qgroup earlier in snapshot creation Boris Burkov
2023-07-26 20:38 ` [PATCH v4 07/18] btrfs: function for recording simple quota deltas Boris Burkov
2023-07-26 20:38 ` [PATCH v4 08/18] btrfs: rename tree_ref and data_ref owning_root Boris Burkov
2023-07-26 20:38 ` [PATCH v4 09/18] btrfs: track owning root in btrfs_ref Boris Burkov
2023-07-26 20:38 ` [PATCH v4 10/18] btrfs: track original extent owner in head_ref Boris Burkov
2023-07-26 20:38 ` [PATCH v4 11/18] btrfs: new inline ref storing owning subvol of data extents Boris Burkov
2023-07-26 20:38 ` Boris Burkov [this message]
2023-07-26 20:38 ` [PATCH v4 13/18] btrfs: record simple quota deltas Boris Burkov
2023-07-26 20:38 ` [PATCH v4 14/18] btrfs: simple quota auto hierarchy for nested subvols Boris Burkov
2023-07-26 20:38 ` [PATCH v4 15/18] btrfs: check generation when recording simple quota delta Boris Burkov
2023-07-26 20:38 ` [PATCH v4 16/18] btrfs: track metadata relocation cow with simple quota Boris Burkov
2023-07-26 20:38 ` [PATCH v4 17/18] btrfs: track data relocation " Boris Burkov
2023-07-26 20:38 ` [PATCH v4 18/18] btrfs: only set QUOTA_ENABLED when done reading qgroups Boris Burkov
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=c43550d1d5068ca8a596704bcd25d2ec1ea6f3bb.1690403768.git.boris@bur.io \
--to=boris@bur.io \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@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;
as well as URLs for NNTP newsgroup(s).