libocfs2: fix non-zero value in Next Leaf field in the rightmost leaf metadata block #68
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
… metadata block
One of our customers reported read-only filesystem. fsck.ocfs2 -ny showed the
following issue:
Pass 1: Checking inodes and blocks
[EXTENT_LIST_FREE] Extent list in owner 658435 claims 231 as the next free chain record, but fsck believes the largest valid value is 227. Clamp the next record value? n
debugfs.ocfs2 also showed the corruption:
Inode: 658435 Mode: 0644 Generation: 974589382 (0x3a170dc6)
FS Generation: 432631804 (0x19c96ffc)
CRC32: 00000000 ECC: 0000
Type: Regular Attr: 0x0 Flags: Valid
Dynamic Features: (0x0)
User: 0 (root) Group: 0 (root) Size: 121633767424
Links: 1 Clusters: 14848000
ctime: 0x66fa60d8 0x343acc43 -- Mon Sep 30 08:27:04.876268611 2024
atime: 0x66fa5e5d 0x34514ed8 -- Mon Sep 30 08:16:29.877743832 2024
mtime: 0x66fa60d8 0x343acc43 -- Mon Sep 30 08:27:04.876268611 2024
dtime: 0x0 -- Thu Jan 1 00:00:00 1970
Refcount Block: 0
Last Extblk: 539186 Orphan Slot: 0
Sub Alloc Slot: 0 Sub Alloc Bit: 2
Tree Depth: 1 Count: 227 Next Free Rec: 231
## Offset Clusters Block#
0 0 129024 525859
1 129024 129024 526883
The "Next Free Rec" had overshoot the "Count".
Upon running fsck.ocfs2 -fy, the fsck managed to fix only the
root metadata block and updated it with a new "Last Extblk"
Inode: 658435 Mode: 0644 Generation: 974589382 (0x3a170dc6)
FS Generation: 432631804 (0x19c96ffc)
CRC32: 00000000 ECC: 0000
Type: Regular Attr: 0x0 Flags: Valid
Dynamic Features: (0x0)
User: 0 (root) Group: 0 (root) Size: 121633767424
Links: 1 Clusters: 14644224
ctime: 0x66fa60d8 0x343acc43 -- Mon Sep 30 08:27:04.876268611 2024
atime: 0x66fa5e5d 0x34514ed8 -- Mon Sep 30 08:16:29.877743832 2024
mtime: 0x66fa60d8 0x343acc43 -- Mon Sep 30 08:27:04.876268611 2024
dtime: 0x0 -- Thu Jan 1 00:00:00 1970
Refcount Block: 0
Last Extblk: 535090 Orphan Slot: 0
Sub Alloc Slot: 0 Sub Alloc Bit: 2
Tree Depth: 1 Count: 227 Next Free Rec: 227
## Offset Clusters Block#
0 0 129024 525859
1 129024 129024 526883
2 258048 129024 536099
However fsck.ocfs2 did not set "Next Leaf" to zero in the updated "Last Extblk".
SubAlloc Bit: 16 SubAlloc Slot: 0
Blknum: 535090 Next Leaf: 536114
CRC32: 00000000 ECC: 0000
Tree Depth: 0 Count: 252 Next Free Rec: 252
## Offset Clusters Block# Flags
0 29159424 256 7845889 0x0
1 29159936 256 7846145 0x0
This patch addresses this issue by checking the last leaf metadata block
and setting "Next Leaf" to zero if not done.
Signed-off-by: Gautham Ananthakrishna <gautham.ananthakrishna@oracle.com>
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.
One of our customers reported read-only filesystem. fsck.ocfs2 -ny showed the following issue:
Pass 1: Checking inodes and blocks
[EXTENT_LIST_FREE] Extent list in owner 658435 claims 231 as the next free chain record, but fsck believes the largest valid value is 227. Clamp the next record value? n
debugfs.ocfs2 also showed the corruption:
The "Next Free Rec" had overshoot the "Count".
Upon running fsck.ocfs2 -fy, the fsck managed to fix only the root metadata block and updated it with a new "Last Extblk"
However fsck.ocfs2 did not set "Next Leaf" to zero in the updated "Last Extblk".
This patch addresses this issue by checking the last leaf metadata block and setting "Next Leaf" to zero if not done.