On Thu, Oct 17, 2024 at 08:42:59PM +0800, Baokun Li wrote:Yes, there is now block group level isolation. Our goal is to further
Indeed, our rough plan is to first implement isolation of abnormal fileWe have some of this already; if a block group has obvious
system resources, so that the system can continue to run normally even
when there is an error; then implement online scanning, so that the
maintainer can see the health report at any time; and finally implement
the most difficult online repair.
inconsistencies --- for example, if there is an attempt to mark a
block or inode as free, but it's already marked as free as the
allocation bitmap, we can mark the block group as inconsistent, and
then avoid allocating from the block group. That's easy because it's
the kind of inconsistency which can be detected locally.
The problem comes with those inconsistencies which require a globalIndeed, consistency is a tricky issue, and we'll focus on that piece of
examination of the file system data structures. For example, is the
refcount of an inode correct? Or is a block claimed by more than one
inode? The e2scrub approach requires creating a read-only snapshot
(which is why we need LVM) and then running e2fsck in userspace,
because it does a global examination of all file system data
structures.
Of course, we have to make sure that the metadata modification and the treeWe do need to establish the mapping of physical blocks to inodes andWhen we allocate a block, we need to journal the changes to the
inodes to parent dir. By tree managed by jbd2 do you mean updating
the tree when committing to journal? Or are updates to the tree
logged to journal?
allocation bitmap. If we are going to also update the reverse mapping
data structure, that needs to be journalled also, so that after a
crash, the data structures are consistent.
- Ted