So when I stopped my array for a reboot to replace a cache ssd it wouldn't stop and I had to powercycle the host after a long wait.

Once it was back up I got a warning about a array disk that had error'd out.

 

I started the array with the disk unassigned and then I saw this in syslog:

Quote

Jun 27 19:40:59 Tower emhttpd: shcmd (178): mkdir -p /mnt/disk2
Jun 27 19:40:59 Tower emhttpd: shcmd (179): mount -t xfs -o noatime,nodiratime /dev/md2 /mnt/disk2
Jun 27 19:40:59 Tower kernel: XFS (md2): Mounting V5 Filesystem
Jun 27 19:40:59 Tower kernel: XFS (md2): Corruption warning: Metadata has LSN (2:2019828) ahead of current LSN (2:2019822). Please unmount and run xfs_repair (>= v4.3) to resolve.
Jun 27 19:40:59 Tower kernel: XFS (md2): log mount/recovery failed: error -22
Jun 27 19:40:59 Tower kernel: XFS (md2): log mount failed
Jun 27 19:40:59 Tower root: mount: /mnt/disk2: wrong fs type, bad option, bad superblock on /dev/md2, missing codepage or helper program, or other error.
Jun 27 19:40:59 Tower emhttpd: shcmd (179): exit status: 32
Jun 27 19:40:59 Tower emhttpd: /mnt/disk2 mount error: No file system
Jun 27 19:40:59 Tower emhttpd: shcmd (180): umount /mnt/disk2
Jun 27 19:40:59 Tower root: umount: /mnt/disk2: not mounted.
Jun 27 19:40:59 Tower emhttpd: shcmd (180): exit status: 32

Then I noticed some of the emulated shares are missing folders and files.

I'm running unraid 6.7.2.

 

What should be my next step in order to try to salvage any data that is missing? I've attached diagnostics.

tower-diagnostics-20190627-1838.zip

Edited June 28, 20197 yr by sorano

So I stopped array and started in maintenance mode and ran check with -nv

 

Quote

Phase 1 - find and verify superblock... - block cache size set to 3067240 entries Phase 2 - using internal log - zero log... zero_log: head block 2019822 tail block 2019818 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... sb_fdblocks 85383563, counted 87550687 - 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 = 1 - agno = 2 - agno = 3 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Thu Jun 27 23:40:59 2019 Phase Start End Duration Phase 1: 06/27 23:39:09 06/27 23:39:09 Phase 2: 06/27 23:39:09 06/27 23:39:13 4 seconds Phase 3: 06/27 23:39:13 06/27 23:40:39 1 minute, 26 seconds Phase 4: 06/27 23:40:39 06/27 23:40:39 Phase 5: Skipped Phase 6: 06/27 23:40:39 06/27 23:40:59 20 seconds Phase 7: 06/27 23:40:59 06/27 23:40:59 Total run time: 1 minute, 50 seconds

So it doesnt tell me to run xfs_repair, what would my next step be?

Run again without -n

Quote

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.

@johnnie.black

use -L

Thanks for helping @johnnie.black

 

It's running now.

Is there anything I can do when it's done in order to try to salvage any data that was lost?

Look for a lost+found folder on that disk and any data inside, but most likely no data loss.

Ok, it finished now:

 

Quote

Phase 1 - find and verify superblock... - block cache size set to 3067240 entries Phase 2 - using internal log - zero log... zero_log: head block 2019822 tail block 2019818 ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used. - scan filesystem freespace and inode maps... sb_fdblocks 85383563, counted 87550687 - 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 = 1 - agno = 2 - agno = 3 Phase 5 - rebuild AG headers and trees... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Maximum metadata LSN (2:2019828) is ahead of log (1:2). Format log to cycle 5. XFS_REPAIR Summary Fri Jun 28 09:57:32 2019 Phase Start End Duration Phase 1: 06/28 09:23:44 06/28 09:23:44 Phase 2: 06/28 09:23:44 06/28 09:34:22 10 minutes, 38 seconds Phase 3: 06/28 09:34:22 06/28 09:35:49 1 minute, 27 seconds Phase 4: 06/28 09:35:49 06/28 09:35:49 Phase 5: 06/28 09:35:49 06/28 09:35:49 Phase 6: 06/28 09:35:49 06/28 09:36:12 23 seconds Phase 7: 06/28 09:36:12 06/28 09:36:12 Total run time: 12 minutes, 28 seconds done

Then I stopped maintenance and started the array with the disk still unassigned and my missing folders are back!

 

What is my next step now? Stop the array and re-assign the disk again?

Disk is connected using USB and there's no SMART, so can't see if the disk is good or not.