linux.git/fs/bcachefs/btree_write_buffer.c, branch v6.15 Linux kernel source tree bcachefs: Use sort_nonatomic() instead of sort() 2025-04-06T23:33:53+00:00 Kent Overstreet kent.overstreet@linux.dev 2025-03-26T15:44:30+00:00 55fd97fbc4744a43fb2d134908e481266cf33bda Fixes "task out to lunch" warnings during recovery on large machines with lots of dirty data in the journal. Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev> 
Fixes "task out to lunch" warnings during recovery on large machines
with lots of dirty data in the journal.

Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
bcachefs: Kill btree_iter.trans 2025-04-02T14:24:34+00:00 Kent Overstreet kent.overstreet@linux.dev 2025-03-21T19:18:51+00:00 9180ad2e161b7030e0af78fd2266cbcefe81e652 This was planned to be done ages ago, now finally completed; there are places where we have quite a few btree_trans objects on the stack, so this reduces stack usage somewhat. Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev> 
This was planned to be done ages ago, now finally completed; there are
places where we have quite a few btree_trans objects on the stack, so
this reduces stack usage somewhat.

Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
bcachefs: Change btree wb assert to runtime error 2025-03-14T14:25:25+00:00 Kent Overstreet kent.overstreet@linux.dev 2025-03-14T13:54:43+00:00 90fd9ad5b0c981693c8512d9da01f14fb6596e9d We just had a report of the assert for "btree in write buffer for non-write buffer btree" popping during the 6.14 upgrade. - 150TB filesystem, after a reboot the upgrade was able to continue from where it left off, so no major damage. But with 6.14 about to come out we want to get this tracked down asap, and need more data if other users hit this. Convert the BUG_ON() to an emergency read-only, and print out btree, the key itself, and stack trace from the original write buffer update (which did not have this check before). Reported-by: Stijn Tintel <stijn@linux-ipv6.be> Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev> 
We just had a report of the assert for "btree in write buffer for
non-write buffer btree" popping during the 6.14 upgrade.

- 150TB filesystem, after a reboot the upgrade was able to continue from
  where it left off, so no major damage.

But with 6.14 about to come out we want to get this tracked down asap,
and need more data if other users hit this.

Convert the BUG_ON() to an emergency read-only, and print out btree, the
key itself, and stack trace from the original write buffer update (which
did not have this check before).

Reported-by: Stijn Tintel <stijn@linux-ipv6.be>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
bcachefs: Assert that btree write buffer only touches the right btrees 2025-01-10T04:38:41+00:00 Kent Overstreet kent.overstreet@linux.dev 2024-12-24T21:57:24+00:00 cb3f34982c9dfccf1aadde4e69043c7da3107c92 More asserts, more better. Also, clean up the per-btree flags a bit. Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev> 
More asserts, more better.

Also, clean up the per-btree flags a bit.

Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
bcachefs: trace_write_buffer_maybe_flush 2024-12-21T06:36:23+00:00 Kent Overstreet kent.overstreet@linux.dev 2024-12-10T15:29:12+00:00 3f57171d8ddd792a0367e05395a6266e5fc011e0 Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev> 
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
bcachefs: btree_write_buffer_flush_seq() no longer closes journal 2024-12-21T06:36:19+00:00 Kent Overstreet kent.overstreet@linux.dev 2024-04-23T06:18:18+00:00 0eaac0b44fa93a5bf8bd5d79c557ca5e04d2dc16 Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev> 
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
bcachefs: trivial btree write buffer refactoring 2024-12-21T06:36:19+00:00 Kent Overstreet kent.overstreet@linux.dev 2024-11-23T23:21:12+00:00 f4d67f6d5a4c042a28fa1d67f756e3d24ba60888 Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev> 
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
bcachefs: bch2_btree_write_buffer_flush_going_ro() 2024-11-08T04:31:11+00:00 Kent Overstreet kent.overstreet@linux.dev 2024-11-08T02:48:33+00:00 ca43f73cd1720e3b0b9c49deec1a13c89c0ca1e8 The write buffer needs to be specifically flushed when going RO: keys in the journal that haven't yet been moved to the write buffer don't have a journal pin yet. This fixes numerous syzbot bugs, all with symptoms of still doing writes after we've got RO. Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev> 
The write buffer needs to be specifically flushed when going RO: keys in
the journal that haven't yet been moved to the write buffer don't have a
journal pin yet.

This fixes numerous syzbot bugs, all with symptoms of still doing writes
after we've got RO.

Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
bcachefs: silence silly kdoc warning 2024-07-18T22:33:30+00:00 Kent Overstreet kent.overstreet@linux.dev 2024-07-16T20:43:59+00:00 f05a0b9c73bc1728b130ac8d1d76b7bbf3f0241d Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev> 
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
bcachefs: Eytzinger accumulation for accounting keys 2024-07-14T23:00:14+00:00 Kent Overstreet kent.overstreet@linux.dev 2023-12-27T16:33:21+00:00 b9efa9673e1d3fee530b582dbde1827d336513a8 The btree write buffer takes as input keys from the journal, sorts them, deduplicates them, and flushes them back to the btree in sorted order. The disk space accounting rewrite is moving accounting to normal btree keys, with update (in this case deltas) accumulated in the write buffer and then flushed to the btree; but this is going to increase the number of keys handled by the write buffer by perhaps as much as a factor of 3x-5x. The overhead from copying around and sorting this many keys would cause a significant performance regression, but: there is huge locality in updates to accounting keys that we can take advantage of. Instead of appending accounting keys to the list of keys to be sorted, this patch adds an eytzinger search tree of recently seen accounting keys. We look up the accounting key in the eytzinger search tree and apply the delta directly, adding it if it doesn't exist, and periodically prune the eytzinger tree of unused entries. Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev> 
The btree write buffer takes as input keys from the journal, sorts them,
deduplicates them, and flushes them back to the btree in sorted order.

The disk space accounting rewrite is moving accounting to normal btree
keys, with update (in this case deltas) accumulated in the write buffer
and then flushed to the btree; but this is going to increase the number
of keys handled by the write buffer by perhaps as much as a factor of
3x-5x.

The overhead from copying around and sorting this many keys would cause
a significant performance regression, but: there is huge locality in
updates to accounting keys that we can take advantage of.

Instead of appending accounting keys to the list of keys to be sorted,
this patch adds an eytzinger search tree of recently seen accounting
keys. We look up the accounting key in the eytzinger search tree and
apply the delta directly, adding it if it doesn't exist, and
periodically prune the eytzinger tree of unused entries.

Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>