Kernel/Ext2FS: Allocate blocks lazily + support writing holes #24149
+346
−461
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This removes removes the need to know the last block in advance, and makes the loops slightly easier to reason about by depending on fewer conditions.
github-actions
bot
added
the
👀 pr-needs-review
Since we now only store blocks that are actually allocated, it is entirely valid for the block list to be empty, so this commit lifts the restrictions on accessing inodes with an empty block list.
This is a large commit, since this is essentially a complete rewrite of the key low-level functions that handle reading/writing blocks. This is, however, a necessary prerequisite of being able to write holes. The previous version of `flush_block_list()` (along with its numerous helper functions) was entirely reliant on all blocks being sequential. In contrast to the previous implementation, the new version of `flush_block_list()` simply writes out the difference between the old block list and the new block list by calculating the correct indirect block(s) to update based on the relevant block's logical index. `compute_block_list()` has also been rewritten, since the estimated amount of meta blocks was incorrectly calculated for files with holes as a result of the estimated amount of blocks being a function of the file size. Since it isn't possible to accurately compute the shape of the block list without traversing it, we no longer try to perform such a computation, and instead simply search through all of the allocated indirect blocks. `compute_block_list_with_meta_blocks()` has also been removed in favor of the new `compute_meta_blocks()`, since meta blocks are fundamentally distinct from data blocks due to there being no mapping between any logical block index and the physical block index.
With this change, we no longer preallocate blocks when an inode's size is updated, and instead only allocate the minimum amount of blocks when the inode is actually written to.
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
... and also do a thorough refactor to be able to accomplish that, because the old implementation was extremely dependent on all blocks being sequential. There's a fairly long explanation of that in the relevant commit message.
This also accidentally fixes various situations where the filesystem would get slightly corrupted, such as when running the second of the following two commands:
Here's a more complete script that I used to test the correctness of this PR:
Closes #6236.