- 22 Oct, 2023 40 commits
-
-
Kent Overstreet authored
A bkey_on_stack_realloc() call was in the wrong place, and broken for indirect extents Signed-off-by:
Kent Overstreet <kent.overstreet@gmail.com> Signed-off-by:
Kent Overstreet <kent.overstreet@linux.dev>
-
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:
-
Kent Overstreet authored
__bch2_truncate_page() will mark some of the blocks in a page as unallocated. But, if the page is mmapped (and writable), every block in the page needs to be marked dirty, else those blocks won't be written by __bch2_writepage(). The solution is to change those userspace mappings to RO, so that we force bch2_page_mkwrite() to be called again. Signed-off-by:
-
Kent Overstreet authored
We also need to update the journal's bloom filter of inode numbers that each journal write has upudates for - in case the inode gets evicted before it gets fsynced. Signed-off-by:
-
Kent Overstreet authored
There was a long standing race in the mount/unmount code - the VFS intends for mount/unmount synchronizatino to be handled by the list of superblocks, but we were still holding devices open after tearing down our superblock in the unmount path. Signed-off-by: -
Kent Overstreet authored
Also - make sure to show the devices we actually have open in /proc Signed-off-by:
-
Kent Overstreet authored
- Print out more information in error messages - On checksum error, keep the journal entry but mark it bad so that we can prefer entries from other devices that don't have bad checksums Signed-off-by:
-
Kent Overstreet authored
The paths where we delete or truncate inodes don't pass commit flags for BTREE_INSERT_LAZY_RW, so just go rw if necessary in the fsck code. Signed-off-by:
-
Kent Overstreet authored
Inode options that are accessible via the xattr interface are stored with a +1 bias, so that a value of 0 means unset. We weren't handling this consistently. Signed-off-by:
-
Kent Overstreet authored
We don't have a limit on the number of inodes in a filesystem, so this is apparently the right way to report that. Signed-off-by:
-
Kent Overstreet authored
Signed-off-by:
-
Kent Overstreet authored
Normally successfully parsing a target means disk groups should exist, but we don't want a BUG() or null ptr deref if we end up with an invalid target. Signed-off-by:
-
Kent Overstreet authored
Signed-off-by:
-
Kent Overstreet authored
When devices have different sized buckets this is more correct. Signed-off-by:
-
Kent Overstreet authored
Since the copygc thread is now global and not per device, we're not freeing up space on any one device in bounded time - and indeed we never really were, since rebalance wasn't moving data around between devices with that objective. Signed-off-by:
-
