- 22 Oct, 2023 40 commits
-
-
Kent Overstreet authored
This patch starts treating the bpos.snapshot field like part of the key in the btree code: * bpos_successor() and bpos_predecessor() now include the snapshot field * Keys in btrees that will be using snapshots (extents, inodes, dirents and xattrs) now always have their snapshot field set to U32_MAX The btree iterator code gets a new flag, BTREE_ITER_ALL_SNAPSHOTS, that determines whether we're iterating over keys in all snapshots or not - internally, this controlls whether bkey_(successor|predecessor) increment/decrement the snapshot field, or only the higher bits of the key. We add a new member to struct btree_iter, iter->snapshot: when BTREE_ITER_ALL_SNAPSHOTS is not set, iter->pos.snapshot should always equal iter->snapshot, which will be 0 for btrees that don't use snapshots, and alsways U32_MAX for btrees that will use snapshots (until we enable snapshot creation). This patch also introduces a new metadata version number, and compat code for reading from/writing to older versions - this isn't a forced upgrade (yet). Signed-off-by:
Kent Overstreet <kent.overstreet@gmail.com> Signed-off-by:
Kent Overstreet <kent.overstreet@linux.dev>
-
Kent Overstreet authored
With snapshots, we're going to need to differentiate between comparisons that should and shouldn't include the snapshot field. bpos_cmp is now the comparison function that does include the snapshot field, used by core btree code. Upper level filesystem code generally does _not_ want to compare against the snapshot field - that code wants keys to compare as equal even when one of them is in an ancestor snapshot. Signed-off-by:
-
Kent Overstreet authored
Signed-off-by:
-
Kent Overstreet authored
The btree key cache mutex was becoming a significant bottleneck - it was mainly used to protect the lists of dirty, clean and freed cached keys. This patch eliminates the dirty and clean lists - instead, when we need to scan for keys to drop from the cache we iterate over the rhashtable, and thus we're able to remove most uses of that lock. Signed-off-by:
-
Kent Overstreet authored
Since we now make sure to always generate packed bkey formats that can pack the min_key of a btree node, this path should actually never happen. Signed-off-by:
-
Kent Overstreet authored
When we pass BTREE_INSERT_NOUNLOCK bch2_trans_commit isn't supposed to unlock after a successful commit, but it was calling bch2_trans_cond_resched() - oops. Signed-off-by:
-
Kent Overstreet authored
Signed-off-by:
-
Kent Overstreet authored
We weren't packing the min/max keys, which was a major oversight and completely disabled generating bkey_floats for adjacent nodes. Signed-off-by:
-
Kent Overstreet authored
On btree node split, we weren't ensuring the min_key of the new larger node packs in the new format for this node. This triggers some painful slowpaths in the bset.c aux search tree code - this patch fixes that by calculating a new format for the new node with the new min_key. Signed-off-by:
-
Kent Overstreet authored
Bkey noops were introduced to deal with trimming inline data extents in place in the btree: if the u64s field of a bkey was 0, that u64 was a noop and we'd start looking for the next bkey immediately after it. But extent handling has been lifted above the btree - we no longer modify existing extents in place in the btree, and the compatibilty code for old style extent btree nodes is gone, so we can completely drop this code. Signed-off-by:
-
Kent Overstreet authored
The default was 1/256th of the device and capped at 512MB, which is fairly tiny these days. Signed-off-by:
-
Kent Overstreet authored
Signed-off-by:
-
Kent Overstreet authored
External (to the btree iterator code) users of bch2_btree_iter_traverse expect that on success the iterator will be pointed at iter->pos and have that position locked - but since we split iter->pos and iter->real_pos, that means it has to update iter->real_pos if necessary. Internal users don't expect it to modify iter->real_pos, so we need two separate functions. Signed-off-by:
-
Kent Overstreet authored
It had some silly redundancies. Signed-off-by:
-
Kent Overstreet authored
It was using the method for btree_ptr_v1, but that wasn't checking all the fields. Signed-off-by:
-
Kent Overstreet authored
More prep work for snapshots. Signed-off-by:
-
Kent Overstreet authored
peek() has to update iter->real_pos - there's no need for bch2_btree_iter_set_pos() to update it as well. Signed-off-by:
-
Kent Overstreet authored
Ideally we'll be getting rid of peek_with_updates(), but the callers will need to be checked. Signed-off-by:
-
Kent Overstreet authored
Signed-off-by:
-
Kent Overstreet authored
This just gives some internal helpers some better names. Signed-off-by:
-
Kent Overstreet authored
Since we're no longer doing next() immediately followed by peek(), this optimization isn't doing anything anymore. Signed-off-by:
-
Kent Overstreet authored
This means bch2_btree_iter_traverse_one() can be made more efficient. Signed-off-by:
-
Kent Overstreet authored
btree node iterators need to obey the regular btree node invarionts w.r.t. iter->real_pos; once they do, bch2_btree_iter_traverse will have less that it needs to check. Signed-off-by:
-
Kent Overstreet authored
The way btree iterators work internally has been changing, particularly with the iter->real_pos changes, and bch2_btree_iter_next() is no longer hyper optimized - it's just advance followed by peek, so it's more efficient to just call advance where we're not using the return value of bch2_btree_iter_next(). Signed-off-by:
-
Kent Overstreet authored
Signed-off-by:
-
Kent Overstreet authored
Prep work for snapshots Signed-off-by:
-
Kent Overstreet authored
Signed-off-by:
-
Kent Overstreet authored
comparison was wrong Signed-off-by:
-
Kent Overstreet authored
This is mkfs's job. Also, clean up the handling of feature bits some. Signed-off-by:
-
Kent Overstreet authored
The superblock version fields need to be accurate to know whether a filesystem is supported, thus we should be verifying them. Signed-off-by:
-
Kent Overstreet authored
Signed-off-by:
-
Kent Overstreet authored
This code used to be used for running some assertions on alloc info at runtime, but it long predates fsck and hasn't been good for much in ages - we can delete it now. Signed-off-by:
-
Kent Overstreet authored
Signed-off-by:
-
Kent Overstreet authored
We keep running into occasional bugs with btree transaction iterators overflowing - this will make those bugs more visible. Signed-off-by:
-
Kent Overstreet authored
This is a bit clearer than using bch2_btree_iter_free(). Signed-off-by:
-
Kent Overstreet authored
Change fsck code to always put btree iterators - also, make some flow control improvements to deal with lock restarts better, and refactor check_extents() to not walk extents twice for counting/checking i_sectors. Signed-off-by:
-
Kent Overstreet authored
Signed-off-by:
-
Kent Overstreet authored
Signed-off-by:
-
Kent Overstreet authored
Signed-off-by:
-
Kent Overstreet authored
this is used in only one place now, so just inline it into the caller. Signed-off-by:
-
