mikesp18 Posted July 15, 2021 Share Posted July 15, 2021 I removed a share and then tried to add a new one. My system log started throwing many errors such as Quote Jul 15 15:58:44 Orcrist emhttpd: error: get_fs_sizes, 5903: Input/output error (5): statfs: /mnt/user/Mov I stopped the array and restarted it. Now under the Array Operations on the Main tab, I see Quote Unmountable disk present: Disk 4 • WDC_WD80EFAX-68LHPN0_7SJ7JTMW (sdc) It is giving me the option to format that drive as it is unmountable. This drive was working fine a few seconds prior. Any ideas? I have seen some UDMA_CRC errors on this drive before, but it is a relatively new drive (I seem to frequently get UDMA_CRC errors despite checking and replacing SATA cables). Before I do something stupid like resetting the server, could you guys look at the log and smart report and let me know what you think? I appreciate it. orcrist-diagnostics-20210715-1613.zip orcrist-smart-20210715-1613.zip Quote Link to comment
Squid Posted July 15, 2021 Share Posted July 15, 2021 Run the file system check against disk 4 https://wiki.unraid.net/Check_Disk_Filesystems Quote Link to comment
mikesp18 Posted July 15, 2021 Author Share Posted July 15, 2021 Phase 1 - find and verify superblock... - block cache size set to 3012408 entries Phase 2 - using internal log - zero log... zero_log: head block 578753 tail block 574745 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... invalid start block 2690876492 in record 46 of bno btree block 4/44382387 agi unlinked bucket 4 is 386238468 in ag 4 (inode=8976173060) sb_icount 299168, counted 290912 sb_ifree 8198, counted 14220 sb_fdblocks 598797622, counted 631121483 - 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... free space (4,48984675-48984973) only seen by one free space btree - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 1 - agno = 5 - agno = 7 - agno = 4 - agno = 6 - agno = 3 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 8976173060, would move to lost+found Phase 7 - verify link counts... would have reset inode 8976173060 nlinks from 0 to 1 No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Thu Jul 15 16:44:00 2021 Phase Start End Duration Phase 1: 07/15 16:43:29 07/15 16:43:29 Phase 2: 07/15 16:43:29 07/15 16:43:30 1 second Phase 3: 07/15 16:43:30 07/15 16:43:46 16 seconds Phase 4: 07/15 16:43:46 07/15 16:43:46 Phase 5: Skipped Phase 6: 07/15 16:43:46 07/15 16:44:00 14 seconds Phase 7: 07/15 16:44:00 07/15 16:44:00 Total run time: 31 seconds Quote Link to comment
JorgeB Posted July 16, 2021 Share Posted July 16, 2021 Without -n or nothing will be done, if it asks for -L use it. Quote Link to comment
mikesp18 Posted July 16, 2021 Author Share Posted July 16, 2021 Phase 1 - find and verify superblock... - block cache size set to 3012408 entries Phase 2 - using internal log - zero log... zero_log: head block 578753 tail block 574745 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. This is the output with -v. Should I use the -L option? Quote Link to comment
mikesp18 Posted July 16, 2021 Author Share Posted July 16, 2021 (edited) Phase 1 - find and verify superblock... - block cache size set to 3012408 entries Phase 2 - using internal log - zero log... zero_log: head block 578753 tail block 574745 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... invalid start block 2690876492 in record 46 of bno btree block 4/44382387 agi unlinked bucket 4 is 386238468 in ag 4 (inode=8976173060) sb_icount 299168, counted 290912 sb_ifree 8198, counted 14220 sb_fdblocks 598797622, counted 631121483 - 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 - 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 = 1 - agno = 7 - agno = 5 - agno = 3 - agno = 6 - agno = 4 - agno = 2 Phase 5 - rebuild AG headers and trees... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - 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 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 8976173060, moving to lost+found Phase 7 - verify and correct link counts... Maximum metadata LSN (3:576454) is ahead of log (1:2). Format log to cycle 6. XFS_REPAIR Summary Fri Jul 16 13:06:15 2021 Phase Start End Duration Phase 1: 07/16 13:03:37 07/16 13:03:37 Phase 2: 07/16 13:03:37 07/16 13:04:14 37 seconds Phase 3: 07/16 13:04:14 07/16 13:04:30 16 seconds Phase 4: 07/16 13:04:30 07/16 13:04:30 Phase 5: 07/16 13:04:30 07/16 13:04:32 2 seconds Phase 6: 07/16 13:04:32 07/16 13:04:47 15 seconds Phase 7: 07/16 13:04:47 07/16 13:04:47 Total run time: 1 minute, 10 seconds done This was the output with -Lv. It seems to be working and the drive remounted. Any way to see what's in this lost and found file? It's tiny. Actually says 0 bytes Edited July 16, 2021 by mikesp18 Quote Link to comment
JorgeB Posted July 17, 2021 Share Posted July 17, 2021 10 hours ago, mikesp18 said: It's tiny. Actually says 0 bytes That's good, everything should be fine. Quote Link to comment
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.