[LU-15985] e2fsck looping "Inode NNN block BBB conflicts with critical metadata" Created: 29/Jun/22 Updated: 04/Oct/23 Resolved: 04/Oct/23 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Andreas Dilger | Assignee: | WC Triage |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Labels: | e2fsck | ||
| Issue Links: |
|
||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||
| Description |
|
In some cases it appears that e2fsck can become stuck in pass1 block checking with messages similar to: Inode 8304551 block 32881 conflicts with critical metadata, skipping block checks. Inode 8304551 block 32881 conflicts with critical metadata, skipping block checks. Inode 8304551 block 32881 conflicts with critical metadata, skipping block checks. Inode 8304551 block 32881 conflicts with critical metadata, skipping block checks. These repeat hundreds or thousands of times for a single inode, but eventually finish and the inode is marked as having too many errors and is cleared. It doesn't seem to be skipping the block checks at all, unless it is one or more blocks full of the same (bad) 32-bit block numbers and it is checking and ignoring all of them. It would be better if the handling of these errors short-circuited the thousands of lines of output and just cleared the inode (or at last the parent indirect block) immediately, since it will happen in the end anyway. This should probably be part of the inode badness functionality. |
| Comments |
| Comment by Andreas Dilger [ 21/Oct/22 ] |
|
I think patch: https://review.whamcloud.com/48620 " |