January 12, 20179 yr I know this topic has been covered in the General Support, however, I am still not a 100% sure how to proceed. I rebooted my unRAID server v6.2.4 and Disk 3 which is formatted as xfs states 'unmountable'. In some threads, it says to run xfs_repair with the -L option tool and in others, it says to run a new config. I don't want to lose any data and I haven't formatted the disk. I have tried the Parity-Sync/Data Rebuild but that did not help and the Disk passes the SMART test without any errors. Any help and clarifications on how to solve this would be greatly appreciated! Thank you in advance.
January 12, 20179 yr Community Expert That screenshot looks like it is rebuilding the disk. And rebuilding an unmountable disk will just result in an unmountable disk. And a parity check wouldn't help either, nor would a New Config. I don't really see how you could have gotten the idea that you needed to do any of those things. You really should have asked before doing anything. Not clear what you already did before asking. Go to Tools - Diagnostics and post the complete diagnostics zip.
January 12, 20179 yr Author Hi Trurl, Thank you for the quick reply! All I have done so far is I removed the disk from the array without formatting, started the array back up without the disk, stopped it again, rebooted and added the disk back thinking it would fix it. Other than that I have only rebooted or shut down the unRAID. I have not run a new config or the xfs_repair tool because I am unsure. Here are the threads I read about new config and xfs_repair tool: http://lime-technology.com/forum/index.php?topic=55487.0 http://lime-technology.com/forum/index.php?topic=54060.15 And I am attaching the diagnostics zip. Thanks! diagnostics-20170111-1050.zip
January 12, 20179 yr Community Expert Those threads were somewhat more complicated than your scenario. There are a lot more threads out there that are a lot closer to yours so maybe you should have kept looking. This is also covered in the wiki. Let me know if you need help searching, or see How to Search in my sig. The syslog agrees with the screenshot. It is currently rebuilding the disk. The reason I say this is not only because of the yellow triangle, but also because of the large number of reads on the other disks and the large number of writes on that disk. unRAID rebuilds a disk by calculating its contents from parity plus all the other disks. There is a bit at the end of your syslog that make me wonder about the connection to disk1 and cache, but the screenshot isn't showing anything in the errors column for disk1 so I guess it is OK. How is the rebuild progressing? Post a screenshot of Main - Array Operations.
January 12, 20179 yr Author The rebuild is almost done. I have attached the requested screenshot. It would be great if you could help me find a solution or a thread closer to my issue. I would greatly appreciate it I tried searching, but I thought those 2 threads I found were somewhat close to my issue because others had the "unmounted" disk showing. That's what I was basing my search on. I had a scheduled parity check on January 1st and it came back with 0 errors. I have one running once a month. I don't know if this information helps.
January 12, 20179 yr Community Expert According to the screenshot the rebuild was almost done. It will not have fixed your problem, but post another screenshot of Main-Array Devices when it is finished just to make sure everything is as expected before we proceed. Here is the wiki for you to read: Checking and fixing drives in the webGui
January 12, 20179 yr Community Expert Looks OK, all drives green. You just need to repair the filesystem as in the wiki I gave you. Stop then Start in Maintenance mode, run the test and post the output.
January 12, 20179 yr Author Thank you! Here are the results: Phase 1 - find and verify superblock... - block cache size set to 1517296 entries Phase 2 - using internal log - zero log... zero_log: head block 17700 tail block 17696 - 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 = 1 - agno = 3 - agno = 2 - agno = 0 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... Maximum metadata LSN (1:17927) is ahead of log (1:17700). Would format log to cycle 4. No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Wed Jan 11 13:46:19 2017 Phase Start End Duration Phase 1: 01/11 13:46:18 01/11 13:46:18 Phase 2: 01/11 13:46:18 01/11 13:46:18 Phase 3: 01/11 13:46:18 01/11 13:46:19 1 second Phase 4: 01/11 13:46:19 01/11 13:46:19 Phase 5: Skipped Phase 6: 01/11 13:46:19 01/11 13:46:19 Phase 7: 01/11 13:46:19 01/11 13:46:19 Total run time: 1 second
January 13, 20179 yr Author This is what I got: Phase 1 - find and verify superblock... - block cache size set to 1517296 entries Phase 2 - using internal log - zero log... zero_log: head block 17700 tail block 17696 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. Run the -L option?
January 13, 20179 yr Author I ran - L, but when it finished I accidentally clicked "Check" again on -n so I don't have the results... I started the array normally and the disk is now mounted properly, but I can't seem to find where a lost+found folder was created.
January 13, 20179 yr Author No, I don't see a user share. But I see an appdata user share, which usually appears after an unRAID update and it is always empty. I set the disk export to "Yes" but there is no lost+found folder there either.
January 13, 20179 yr Community Expert No, I don't see a user share. But I see an appdata user share, which usually appears after an unRAID update and it is always empty. I set the disk export to "Yes" but there is no lost+found folder there either. not having a lost+found folder is normally a good thing as it meant the repair process found nothing it wanted to put there.
January 13, 20179 yr Author That's great! Should I leave the appdata user share? It is on the cache drive. It auto creates itself and it is always empty.
Archived
This topic is now archived and is closed to further replies.