waldosr Posted September 21, 2024 Posted September 21, 2024 I have been fighting this error for the past couple of days and have made no headway in fixing it. I have repaired (removed the -n) through the graphical interface. I cannot do a repair in console because the drive is encrypted. I ran memory test and let it do two runs and no errors were found. Any further suggestions would be appreciated. Sep 20 17:02:32 KenServer kernel: XFS (dm-7): Unmount and run xfs_repair Sep 20 17:02:32 KenServer kernel: XFS (dm-7): First 128 bytes of corrupted metadata buffer: Sep 20 17:02:32 KenServer kernel: 00000000: 49 4e 41 ff 03 01 00 00 00 00 00 63 00 00 00 64 INA........c...d Sep 20 17:02:32 KenServer kernel: 00000010: 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 ................ Sep 20 17:02:32 KenServer kernel: 00000020: 63 d7 b3 b1 00 00 00 00 62 fd 73 ac 00 00 00 00 c.......b.s..... Sep 20 17:02:32 KenServer kernel: 00000030: 64 08 0e 8a 35 c0 69 0e 00 00 00 00 00 00 00 2c d...5.i........, Sep 20 17:02:32 KenServer kernel: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Sep 20 17:02:32 KenServer kernel: 00000050: 00 00 00 02 00 00 00 00 00 00 00 00 d0 8e ae 0a ................ Sep 20 17:02:32 KenServer kernel: 00000060: ff ff ff ff b6 76 64 dd 00 00 00 00 00 00 00 09 .....vd......... Sep 20 17:02:32 KenServer kernel: 00000070: 00 00 00 12 00 22 fc 73 00 00 00 00 00 00 00 00 .....".s........ Sep 20 17:04:01 KenServer kernel: XFS (dm-7): Metadata corruption detected at xfs_dinode_verify+0xa0/0x732 [xfs], inode 0x2568a3da2 dinode kenserver-diagnostics-20240920-1910.zip Quote
JorgeB Posted September 21, 2024 Posted September 21, 2024 7 hours ago, waldosr said: I have repaired (removed the -n) through the graphical interface. Do you mean the repair looks successful but it keeps showing errors? Post the full xfs_repair -n output Quote
waldosr Posted September 21, 2024 Author Posted September 21, 2024 (edited) I want to verify that dm-7 is disk 6? Want to make sure I am not making a silly mistake. Here is the output with a "-n" Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 3 - agno = 1 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. While I was there I also ran without the flag: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 1 - agno = 3 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done Edited September 21, 2024 by waldosr Quote
itimpi Posted September 21, 2024 Posted September 21, 2024 5 hours ago, waldosr said: dm-7 is disk 6 I would expect it to be disk7. Quote
waldosr Posted September 21, 2024 Author Posted September 21, 2024 I was always under the assumption that dm-0 would be disk 1 therefore making all of the other disks be disk minus one. Here is the same thing for disk 7. Here is the output with a "-n" Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 1 - agno = 3 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. Without the flag: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 1 - agno = 3 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done Quote
Solution JorgeB Posted September 22, 2024 Solution Posted September 22, 2024 dm-7 should be disk8, if all disks are encrypted, but you can use the GUI and post the output from there. Quote
waldosr Posted September 22, 2024 Author Posted September 22, 2024 So that appears to be the one. Ran the test and found errors. Repaired and checked again with no errors. Will wait a bit and check logs the close if error has not come back. Thanks for the help. with "-n" Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 bad CRC for inode 10041834914 inode identifier 2349400319156879359 mismatch on inode 10041834914 bad CRC for inode 10041834914, would rewrite inode identifier 2349400319156879359 mismatch on inode 10041834914 would have cleared inode 10041834914 - agno = 5 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 1 - agno = 3 - agno = 5 - agno = 4 entry ".." at block 0 offset 80 in directory inode 11145911787 references free inode 10041834914 bad CRC for inode 10041834914, would rewrite inode identifier 2349400319156879359 mismatch on inode 10041834914 would have cleared inode 10041834914 entry "7AtWoB8IfI167824961081966043" in shortform directory 11159816000 references free inode 10041834914 would have junked entry "7AtWoB8IfI167824961081966043" in directory inode 11159816000 would have corrected i8 count in directory 11159816000 from 2 to 1 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... entry ".." in directory inode 11145911787 points to free inode 10041834914, would junk entry bad hash table for directory inode 11145911787 (no data entry): would rebuild would rebuild directory inode 11145911787 entry "7AtWoB8IfI167824961081966043" in shortform directory inode 11159816000 points to free inode 10041834914 would junk entry would fix i8count in inode 11159816000 - traversal finished ... - moving disconnected inodes to lost+found ... disconnected dir inode 11145911787, would move to lost+found Phase 7 - verify link counts... would have reset inode 11159816000 nlinks from 3 to 2 No modify flag set, skipping filesystem flush and exiting. Without flag Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 bad CRC for inode 10041834914 inode identifier 2349400319156879359 mismatch on inode 10041834914 bad CRC for inode 10041834914, will rewrite inode identifier 2349400319156879359 mismatch on inode 10041834914 cleared inode 10041834914 - agno = 5 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 1 - agno = 0 - agno = 3 - agno = 4 - agno = 2 - agno = 5 entry ".." at block 0 offset 80 in directory inode 11145911787 references free inode 10041834914 entry "7AtWoB8IfI167824961081966043" in shortform directory 11159816000 references free inode 10041834914 junking entry "7AtWoB8IfI167824961081966043" in directory inode 11159816000 corrected i8 count in directory 11159816000, was 2, now 1 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... entry ".." in directory inode 11145911787 points to free inode 10041834914 bad hash table for directory inode 11145911787 (no data entry): rebuilding rebuilding directory inode 11145911787 - traversal finished ... - moving disconnected inodes to lost+found ... disconnected dir inode 11145911787, moving to lost+found Phase 7 - verify and correct link counts... resetting inode 1370134807 nlinks from 2 to 3 resetting inode 11159816000 nlinks from 3 to 2 done After repair Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 4 - agno = 5 - agno = 2 - agno = 3 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. 1 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.