From: Brian Foster <bfoster@redhat.com>
To: linux-bcachefs@vger.kernel.org
Subject: [PATCH v4 4/4] bcachefs: add fiemap delalloc extent detection
Date: Fri, 19 Apr 2024 14:15:38 -0400 [thread overview]
Message-ID: <20240419181538.1411082-5-bfoster@redhat.com> (raw)
In-Reply-To: <20240419181538.1411082-1-bfoster@redhat.com>
bcachefs currently populates fiemap data from the extents btree.
This works correctly when the fiemap sync flag is provided, but if
not, it skips all delalloc extents that have not yet been flushed.
This is because delalloc extents from buffered writes are first
stored as reservation in the pagecache, and only become resident in
the extents btree after writeback completes.
Update the fiemap implementation to process holes between extents by
scanning pagecache for data, via seek data/hole. If a valid data
range is found over a hole in the extent btree, fake up an extent
key and flag the extent as delalloc for reporting to userspace.
Note that this does not necessarily change behavior for the case
where there is dirty pagecache over already written extents, where
when in COW mode, writeback will allocate new blocks for the
underlying ranges. The existing behavior is consistent with btrfs
and it is recommended to use the sync flag for the most up to date
extent state from fiemap.
Signed-off-by: Brian Foster <bfoster@redhat.com>
---
fs/bcachefs/fs.c | 119 ++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 112 insertions(+), 7 deletions(-)
diff --git a/fs/bcachefs/fs.c b/fs/bcachefs/fs.c
index 5c6af360a61f..b5f95a929bb2 100644
--- a/fs/bcachefs/fs.c
+++ b/fs/bcachefs/fs.c
@@ -989,6 +989,87 @@ static int bch2_fiemap_extent(struct btree_trans *trans,
return 0;
}
+/*
+ * Scan a range of an inode for data in pagecache.
+ *
+ * Intended to be retryable, so don't modify the output params until success is
+ * imminent.
+ */
+static int
+bch2_fiemap_hole_pagecache(struct inode *vinode, u64 *start, u64 *end,
+ bool nonblock)
+{
+ loff_t dstart, dend;
+
+ dstart = bch2_seek_pagecache_data(vinode, *start, *end, 0, nonblock);
+ if (dstart < 0)
+ return dstart;
+ if (dstart >= *end)
+ return -ENOENT;
+
+ dend = bch2_seek_pagecache_hole(vinode, dstart, *end, 0, nonblock);
+ if (dend < 0)
+ return dend;
+
+ *start = dstart;
+ *end = dend;
+ return 0;
+}
+
+/*
+ * Scan a range of pagecache that corresponds to a file mapping hole in the
+ * extent btree. If data is found, fake up an extent key so it looks like a
+ * delalloc extent to the rest of the fiemap processing code.
+ *
+ * Returns 0 if cached data was found, -ENOENT if not.
+ */
+static int
+bch2_fiemap_hole(struct btree_trans *trans, struct inode *vinode, u64 start,
+ u64 end, struct bch_fiemap_extent *cur)
+{
+ struct bch_fs *c = vinode->i_sb->s_fs_info;
+ struct bch_inode_info *ei = to_bch_ei(vinode);
+ struct bkey_i_extent *delextent;
+ struct bch_extent_ptr ptr = {};
+ loff_t dstart = start, dend = end;
+ int ret;
+
+ /*
+ * We hold btree locks here so we cannot block on folio locks without
+ * dropping trans locks first. Run a nonblocking scan for the common
+ * case of no folios over holes and fall back on failure.
+ *
+ * Note that dropping locks like this is technically racy against
+ * writeback inserting to the extent tree, but a non-sync fiemap scan is
+ * fundamentally racy with writeback anyways. Therefore, just report the
+ * range as delalloc regardless of whether we have to cycle trans locks.
+ */
+ ret = bch2_fiemap_hole_pagecache(vinode, &dstart, &dend, true);
+ if (ret == -EAGAIN) {
+ /* open coded drop_locks_do() to relock even on error */
+ bch2_trans_unlock(trans);
+ ret = bch2_fiemap_hole_pagecache(vinode, &dstart, &dend, false);
+ bch2_trans_relock(trans);
+ }
+ if (ret < 0)
+ return ret;
+
+ /*
+ * Create a fake extent key in the buffer. We have to add a dummy extent
+ * pointer for the fill code to add an extent entry. It's explicitly
+ * zeroed to reflect delayed allocation (i.e. phys offset 0).
+ */
+ bch2_bkey_buf_realloc(&cur->kbuf, c, sizeof(*delextent) / sizeof(u64));
+ delextent = bkey_extent_init(cur->kbuf.k);
+ delextent->k.p = POS(ei->v.i_ino, dstart >> 9);
+ bch2_key_resize(&delextent->k, (dend - dstart) >> 9);
+ bch2_bkey_append_ptr(&delextent->k_i, ptr);
+
+ cur->flags = FIEMAP_EXTENT_DELALLOC;
+
+ return 0;
+}
+
static int bch2_fiemap(struct inode *vinode, struct fiemap_extent_info *info,
u64 start, u64 len)
{
@@ -1028,16 +1109,40 @@ static int bch2_fiemap(struct inode *vinode, struct fiemap_extent_info *info,
while (!(ret = btree_trans_too_many_iters(trans)) &&
(k = bch2_btree_iter_peek_upto(&iter, end)).k &&
!(ret = bkey_err(k))) {
+ bool have_delalloc = false;
- if (!bkey_extent_is_data(k.k) &&
- k.k->type != KEY_TYPE_reservation) {
- bch2_btree_iter_advance(&iter);
- continue;
+ /*
+ * If a hole exists before the start of the extent key, scan the
+ * range for pagecache data that might be pending writeback and
+ * thus not yet exist in the extent tree.
+ */
+ if (iter.pos.offset > start) {
+ ret = bch2_fiemap_hole(trans, vinode, start << 9,
+ iter.pos.offset << 9, &cur);
+ if (!ret)
+ have_delalloc = true;
+ else if (ret != -ENOENT)
+ break;
}
- ret = bch2_fiemap_extent(trans, &iter, k, &cur);
- if (ret)
- break;
+ /* process the current key if there's no delalloc to report */
+ if (!have_delalloc) {
+ if (!bkey_extent_is_data(k.k) &&
+ k.k->type != KEY_TYPE_reservation) {
+ start = bkey_start_offset(k.k) + k.k->size;
+ bch2_btree_iter_advance(&iter);
+ continue;
+ }
+
+ ret = bch2_fiemap_extent(trans, &iter, k, &cur);
+ if (ret)
+ break;
+ }
+
+ /*
+ * Store the current extent in prev so we can flag the last
+ * extent on the way out.
+ */
bch2_bkey_buf_realloc(&prev.kbuf, c, cur.kbuf.k->k.u64s);
start = cur.kbuf.k->k.p.offset;
--
2.44.0
prev parent reply other threads:[~2024-04-19 18:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-19 18:15 [PATCH v4 0/4] bcachefs: fiemap delalloc support and cleanup Brian Foster
2024-04-19 18:15 ` [PATCH v4 1/4] bcachefs: drop duplicate fiemap sync flag Brian Foster
2024-04-19 18:15 ` [PATCH v4 2/4] bcachefs: track current fiemap offset in start variable Brian Foster
2024-04-19 18:15 ` [PATCH v4 3/4] bcachefs: refactor fiemap processing into extent helper and struct Brian Foster
2024-04-19 18:15 ` Brian Foster [this message]
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=20240419181538.1411082-5-bfoster@redhat.com \
--to=bfoster@redhat.com \
--cc=linux-bcachefs@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 read-only IMAP folder(s) and NNTP newsgroup(s).