- 22 Oct, 2023 40 commits
-
-
Matthew Wilcox (Oracle) authored
This is dead code; delete the function. Signed-off-by:
Matthew Wilcox (Oracle) <willy@infradead.org> Signed-off-by:
Kent Overstreet <kent.overstreet@linux.dev>
-
Kent Overstreet authored
PAGE_SIZE and size_t are not unsigned longs on 32 bit, annoying... also switch to atomic64_cmpxchg instead of cmpxchg() for journal_seq_copy, as atomic64_cmpxchg has a fallback that uses spinlocks for when it's not supported. Signed-off-by:
Kent Overstreet <kent.overstreet@gmail.com> Signed-off-by:
-
Kent Overstreet authored
This shards new inodes into different btree nodes by using the processor ID for the high bits of the new inode number. Much faster than the previous inode create optimization - this also helps with sharding in the other btrees that index by inode number. Signed-off-by:
-
Kent Overstreet authored
Took awhile to figure out exactly what statfs wanted... Signed-off-by:
-
Kent Overstreet authored
perhaps a bit silly, but some debug assertions we want to add need const propagated a bit more. Signed-off-by:
-
Kent Overstreet authored
These haven't been in used since reallocing iterators has been disabled, and saves us a lot of stack if we get rid of it. Signed-off-by:
-
Kent Overstreet authored
This check is very expensive Signed-off-by:
-
Kent Overstreet authored
It's not used much anymore, the module paramter interface is better. Signed-off-by:
-
Kent Overstreet authored
With the btree key cache code, journal reclaim now has a lot more work to do. It could be the case that after journal reclaim has finished one iteration there's already more work to do, so put it in a loop to check for that. Signed-off-by:
-
Kent Overstreet authored
On workloads that do a lot of multithreaded creates all at once, lock contention on the inodes btree turns out to still be an issue. This patch adds a small buffer of inode numbers that are known to be free, so that we can avoid touching the btree on every create. Also, this changes inode creates to update via the btree key cache for the initial create. Signed-off-by:
-
Kent Overstreet authored
Signed-off-by:
-
Kent Overstreet authored
The check for whether locking a btree node would deadlock was wrong - we have to check that interior nodes are locked before descendents, but this check was wrong when consider cached vs. non cached iterators. Signed-off-by:
-
Kent Overstreet authored
We have a bug where we can get stuck with a process spinning in transaction restarts - need more information. Signed-off-by:
-
Kent Overstreet authored
A bkey_on_stack_realloc() call was in the wrong place, and broken for indirect extents Signed-off-by:
-
Kent Overstreet authored
This switches inode updates to use cached btree iterators - which should be a nice performance boost, since lock contention on the inodes btree can be a bottleneck on multithreaded workloads. Signed-off-by:
-
Kent Overstreet authored
- fiemap didn't know about inline extents, fixed - advancing to the next extent after we'd chased a pointer to the reflink btree was wrong, fixed Signed-off-by:
-
Kent Overstreet authored
There was a bug where bch2_trans_update() would incorrectly delete a pending update where the new update did not actually overwrite the existing update, because we were incorrectly using BTREE_ITER_TYPE when sorting pending btree updates. This affects the pending patch to use cached iterators for inode updates. Signed-off-by:
-
Kent Overstreet authored
Signed-off-by:
-
Kent Overstreet authored
This is to fix a (harmless) bug where the read clock hand in the superblock doesn't match the journal. Signed-off-by:
-
Kent Overstreet authored
This fixes a bug where we'd pop an assertion due to replaying a key for an interior btree node when that node no longer exists. Signed-off-by:
-
Kent Overstreet authored
When inline data extents were added, reflink was forgotten about - we need indirect inline data extents for reflink + inline data to work correctly. This patch adds them, and a new feature bit that's flipped when they're used. Signed-off-by:
-
Kent Overstreet authored
If the bkey_on_stack_reassemble() call in __bch2_read_indirect_extent() reallocates the buffer, k in bch2_read - which we pointed at the bkey_on_stack buffer - will now point to a stale buffer. Whoops. Signed-off-by:
-
Kent Overstreet authored
Signed-off-by:
-
Kent Overstreet authored
Some options can't be parsed until the filesystem initialized; previously, passing these options to mount or remount would cause mount to fail. This changes the mount path so that we parse the options passed in twice, and just ignore any options that can't be parsed the first time. Signed-off-by:
-
Kent Overstreet authored
There's no reason not to always recalculate these fields Signed-off-by:
-
Kent Overstreet authored
Signed-off-by:
-
Kent Overstreet authored
Instead of trying to charge EC parity to the data within the stripe (which is subject to rounding errors), let's charge it to the stripe itself. It should also make -ENOSPC issues easier to deal with if we charge for parity blocks up front, and means we can also make more fine grained accounting available to the user. Signed-off-by:
-
Kent Overstreet authored
The allocator usually doesn't increment bucket gens right away on buckets that it's about to hand out (for reasons that need to be documented), instead deferring that to whatever extent update first references that bucket. But stripe pointers reference buckets without changing bucket sector counts, meaning we could end up with a pointer in a stripe with a gen newer than the bucket it points to. Fix this by adding a transactional trigger for KEY_TYPE_stripe that just writes out the keys in the alloc btree for the buckets it points to. Also - consolidate the code that checks pointer validity. Signed-off-by:
-
Kent Overstreet authored
This fixes a bug where the clock hands in the journal and superblock didn't match, because we were still incrementing the read clock hand while read-only. Signed-off-by:
-
Kent Overstreet authored
Now that we've got transactional alloc info updates (and have for awhile), we don't need to write it out on shutdown, and we don't need to write it out on startup except when GC found errors - this is a big improvement to mount/unmount performance. This patch also fixes a few bugs where we weren't writing out alloc info (on new filesystems, and new devices) and should have been. Signed-off-by:
-
Kent Overstreet authored
We can't be holding read locks on btree nodes when we go to take write locks: this would deadlock if another thread is holding an intent lock on the node we have a read lock on, and it tries to commit and upgrade to a write lock. But instead of triggering an assertion, if this happens we can just upgrade the read lock to an intent lock. Signed-off-by:
-
Kent Overstreet authored
On large filesystems reading in the alloc info takes a significant amount of time. But we don't need to be calling into the fully general bch2_mark_key() path, just open code what we need in bch2_alloc_read_fn(). Signed-off-by:
-
Kent Overstreet authored
The copygc threads errors out and makes the filesystem go RO if it ever tries to run and discovers it has no reserve allocated - which is a problem if it races with the allocator thread and its reserve hasn't been filled yet. The allocator thread doesn't start filling the copygc reserve until after BCH_FS_STARTED has been set, so make sure to wake up the allocator threads after setting that and before starting copygc. Signed-off-by:
-
Kent Overstreet authored
The check for when we need to get a disk reservation was wrong. Signed-off-by:
-
Kent Overstreet authored
vfree() can allocate memory, so we need to call memalloc_nofs_save(). Signed-off-by:
-
Kent Overstreet authored
At some point bch2_fs_alloc() was changed to always call bch2_fs_free() in the error path, which means we need c->cl to always be initialized. Signed-off-by:
-
Kent Overstreet authored
Signed-off-by:
-
Kent Overstreet authored
Awhile back, gcing of stale pointers was split out from full mark-and-sweep gc - but, the bit to actually drop those stale pointers wasn't implemnted. Whoops. Signed-off-by:
-
Kent Overstreet authored
Signed-off-by:
-
Kent Overstreet authored
We can't allocate memory with GFP_FS while holding the btree cache lock, and vfree() can allocate memory. Signed-off-by:
-
