June 11, 20206 yr Hello everyone, So my server had some issues the other day. My son accidentally touched the drive bay on the front and turned off some of the disks while the server was running. He had also powered the server off. I already had one failed disk in the array at this point. I had restarted the server and some disks were missing when the array turned on. I reseated all the drives, and things seemed to be going okay. I decided to swap in a new drive for the failed disk and rebuilt the disk. After this completed I noticed that disk 4 started generating UDMA CRC error counts, the number has grown to 1652 now. I left it alone while I waited for replacement disks and since then Disk 6 says that it is unmountable. I have two replacement drives that I am looking to swap in, but I am just trying to determine the best process for doing so to preserve as much data as possible. Thanks tower-diagnostics-20200611-0900.zip
June 11, 20206 yr Community Expert Check filesystem on disk6: https://wiki.unraid.net/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui 1 hour ago, Caboose20 said: disk 4 started generating UDMA CRC error counts Disk is usually a bad SATA cable, replace it.
June 11, 20206 yr Author 35 minutes ago, johnnie.black said: Check filesystem on disk6: https://wiki.unraid.net/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui I ran the test and this was the result: Phase 1 - find and verify superblock... - block cache size set to 544656 entries Phase 2 - using internal log - zero log... zero_log: head block 127307 tail block 127290 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... agi unlinked bucket 63 is 8831 in ag 0 (inode=8831) sb_ifree 2069, counted 2070 sb_fdblocks 205844696, counted 206825776 - 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 data fork in ino 117471321 claims free block 15577142 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - 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 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 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 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 8831, would move to lost+found Phase 7 - verify link counts... would have reset inode 8831 nlinks from 0 to 1 Maximum metadata LSN (20:127391) is ahead of log (20:127307). Would format log to cycle 23. No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Thu Jun 11 10:42:02 2020 Phase Start End Duration Phase 1: 06/11 10:41:54 06/11 10:41:54 Phase 2: 06/11 10:41:54 06/11 10:41:55 1 second Phase 3: 06/11 10:41:55 06/11 10:41:59 4 seconds Phase 4: 06/11 10:41:59 06/11 10:41:59 Phase 5: Skipped Phase 6: 06/11 10:41:59 06/11 10:42:02 3 seconds Phase 7: 06/11 10:42:02 06/11 10:42:02 Total run time: 8 seconds It seems to indicate that I need to mount the disk to resolve the issues
June 11, 20206 yr Community Expert Run it again without -n or nothing will be done, if it asks for it use -L
June 11, 20206 yr Author Thanks for the fast reply this solve it. I also reseated the drive and I don't seem to be getting CRC errors any more.
Archived
This topic is now archived and is closed to further replies.