I was accessing my array quite happily in the night whilst creating a new larger parity disk, but when I checked the log, I saw there were a number of errors. I rebooted hoping that might clear the problem but it did not.

I have no idea what has gone wrong since all my disks are relatively new.

I have attached the diagnostics hoping that somebody can help me restore my system.

tower-diagnostics-20240417-0933.zip

Diags are after rebooting so we can't see what happened, but check filesystem on disk3 first, run it without -n, you will also need to re-sync parity.

Thanks for the assistance.

Running with the -n option as set (as default), the following is produced.

 

<Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being ignored because the -n option was used. Expect spurious inconsistencies which may be resolved by first mounting the filesystem to replay the 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 - agno = 6 - agno = 7 - 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 = 4 - agno = 5 - agno = 6 - agno = 7 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... Maximum metadata LSN (1:2016718) is ahead of log (1:2014534). Would format log to cycle 4. No modify flag set, skipping filesystem flush and exiting>

 

Running without -n produces:-

 

<Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this.>

 

I don't know how to proceed from here.

Use -L

That was very scary  - but it looks like it has worked!!!

Thank you so much.