Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upCheck next #155
Closed
Check next #155
Conversation
…ch hash For DIR_ITEM with mismatch hash, we could just remove the offending dir item. Lowmem mode will handle the rest part (either re-create the correct dir_item or move the orphan inode to lost+found). This is especially important for old btrfs, since later kernel introduces restrict tree-checker, which could detect such hash mismatch and refuse to read the corrupted leaf. With this repair ability, user could repair with btrfs check --mode=lowmem --repair. Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1111991 Signed-off-by: Qu Wenruo <wqu@suse.com>
…ad dir items This allow us to report the error better, from old in-place report like: ERROR: DIR_ITEM[256 751495445] name foor.WvG1c1TdU namelen 13 filetype 1 mismatch with its hash, wanted 751495445 have 2870353892 root 5 root dir 256 error To new centralized report: root 5 root dir 256 error root 5 inode 256 errors 40000 Dir items with mismatch hash: name: foor.WvG1c1Td namelen: 13 wanted 0xab161fe4 has 0x2ccae915 Also, with mismatch_dir_hash_record structure, it provides the basis for later original mode repair. Signed-off-by: Qu Wenruo <wqu@suse.com>
…lid hash The repair function is reusing delete_corrupted_dir_item(). Since the error can happen for root dir inode, also call try_repair_inode() on root dir inode. This is especially important for old btrfs, since later kernel introduces restrict tree-checker, which could detect such hash mismatch and refuse to read the corrupted leaf. With this repair ability, user could repair with btrfs check --repair. Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1111991 Signed-off-by: Qu Wenruo <wqu@suse.com>
…fy if btrfs-check can also repair it Just remove the customized 'test.sh', then generic fsck test will do the check-repair-check. Signed-off-by: Qu Wenruo <wqu@suse.com>
For case where we exceed qgroup limits, we should also report it as an error. Signed-off-by: Qu Wenruo <wqu@suse.com>
kdave
force-pushed the
kdave:devel
branch
3 times, most recently
from
c4cd1df
to
c8d3986
kdave
force-pushed the
kdave:devel
branch
3 times, most recently
from
f16f983
to
4e8eb31
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.
adam900710 commentedNov 26, 2018
Hi David,
Please merge this branch.
This small patchset contains 2 check related functionality:
Ability to repair dir item with mismatch hash
Both lowmem and original check, along with test case update.
Check qgroup limit exceed
The patch to deprecate BTRFS_QGROUP_LIMIT_RSV_RFER|EXCL is dropped
for this pull request, as it's still uncertain if it's OK or not, and
it's very easy to rebase that patch.
The patchset passes all selftest with one exception:
misc-tests/021-image-multi-devices
That test case failure is caused by poorly recovered multi-device
btrfs-image.
The problem exists from the very beginning, just recent enhanced kernel
code will refuse to mount and I'll address it later in another patchset.
There is some other check related patches, naming "btrfs-progs: fixes of
file extent in original and lowmem check" from Fujitsu, which is still
being updated. I'll push them in next update.
Thanks.