waldosr

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.

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

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

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

Thanks for the quick reply. I will give that a shot and see what happens.

I have been trying to chase down for the past few weeks what is going on with docker. I have tried removing the docker image, increasing the image size, and only starting essential containers that I needed. After anywhere from a day to several days, I will get the following error on the docker page and when I had a VM running, it would stop that too. After this last reboot, the dockers started right up but the server has stated another parity check. Not sure if that is I have also formatted my cache drives this last time with no luck. Any assistance would be greatly appreciated. kenserver-syslog-20230316-1116.zip kenserver-diagnostics-20230316-0611.zip

That worked. I must have left that encrypted when I was trying to encrypt my disks. Thanks a lot for the help.

Attached are diagnostics kenserver-diagnostics-20190819-1248.zip

I am trying to add some drives to my array and if I manually stop my array I can't restart it whether I add the drives or not. The only way I can get my array to start is if I reboot the system. I have attached a screenshot of what I am seeing. Thanks for the assistance.