summaryrefslogtreecommitdiff
path: root/fs/bcachefs/ec.c
diff options
context:
space:
mode:
authorKent Overstreet <kent.overstreet@gmail.com>2021-08-29 19:34:37 -0400
committerKent Overstreet <kent.overstreet@linux.dev>2023-10-22 17:09:11 -0400
commit5f8077cca89bdcc3d7660567462b17831356826d (patch)
tree20291e4a1674b0a38be2ff525bc66f16f4389597 /fs/bcachefs/ec.c
parent638c6ff951bfebbecde5b6912ce22a02a77fafc1 (diff)
downloadlwn-5f8077cca89bdcc3d7660567462b17831356826d.tar.gz
lwn-5f8077cca89bdcc3d7660567462b17831356826d.zip
bcachefs: Kill BTREE_ITER_SET_POS_AFTER_COMMIT
BTREE_ITER_SET_POS_AFTER_COMMIT is used internally to automagically advance extent btree iterators on sucessful commit. But with the upcomnig btree_path patch it's getting more awkward to support, and it adds overhead to core data structures that's only used in a few places, and can be easily done by the caller instead. Signed-off-by: Kent Overstreet <kent.overstreet@gmail.com>
Diffstat (limited to 'fs/bcachefs/ec.c')
-rw-r--r--fs/bcachefs/ec.c5
1 files changed, 5 insertions, 0 deletions
diff --git a/fs/bcachefs/ec.c b/fs/bcachefs/ec.c
index c20c80bd344d..7ad74987757f 100644
--- a/fs/bcachefs/ec.c
+++ b/fs/bcachefs/ec.c
@@ -824,6 +824,7 @@ static int ec_stripe_update_ptrs(struct bch_fs *c,
struct bkey_s_c k;
struct bkey_s_extent e;
struct bkey_buf sk;
+ struct bpos next_pos;
int ret = 0, dev, block;
bch2_bkey_buf_init(&sk);
@@ -863,10 +864,14 @@ static int ec_stripe_update_ptrs(struct bch_fs *c,
extent_stripe_ptr_add(e, s, ec_ptr, block);
bch2_btree_iter_set_pos(iter, bkey_start_pos(&sk.k->k));
+ next_pos = sk.k->k.p;
+
ret = bch2_btree_iter_traverse(iter) ?:
bch2_trans_update(&trans, iter, sk.k, 0) ?:
bch2_trans_commit(&trans, NULL, NULL,
BTREE_INSERT_NOFAIL);
+ if (!ret)
+ bch2_btree_iter_set_pos(iter, next_pos);
if (ret == -EINTR)
ret = 0;
if (ret)