February 16, 20179 yr HI I am having issue for the last 3 days with one of my hard drive which reports "Unmountable disk present" (please see attached snapshost and dignostic file). I used to use for the last month the verion 6.2.4 but yesterday I reverted the unraid ios to the version 6.1.9 and this didn't make any difference. I have got currently two 6TB WD Red hard drives and one ssd 500GB. One of the 6TB WD Red hard drive is reporting the issue and the status is "Unmountable". I have tried to check the parity and run the smart full test which took about 11 hours on Disk1 which reports "unmountable" status but I couldn't find any errors. I also cannot see my shared any more. I have attached all diagnostic files but I don't know how to resolve this. Could someone please advise what would be the next step which I should go for ? Thank you very much in advance. T. blue-diagnostics-20170216-0028.zip
February 16, 20179 yr Completely unrelated to your problem but worth mentioning anyway, assigning an SSD to an array slot is not advised. While it isn't forbidden and the system does allow it, it isn't supported and can cause problems in the future. Furthermore, its speed advantage is largely wasted as you have a mechanical parity disk. A better use of an SSD is as a cache disk, where it can be used to store your docker image and any VMs. There's a discussion thread here.
February 16, 20179 yr Author HI, Thank you for your prompt respond. Sorry but I've forgotten to mention that I use ssd only for running VM and it's not part of this array. I have just run xfs_repair command and got the following output: root@Blue:~# xfs_repair -v /dev/md1 Phase 1 - find and verify superblock... - block cache size set to 2991032 entries Phase 2 - using internal log - zero log... zero_log: head block 337074 tail block 337067 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. root@Blue:~# Could you please confirm if I should run this command with the option "-L" ? Thank you T.
February 16, 20179 yr Author HI I have just tried to stop array, unassigned the Disk1, start array, stop array, assigned the Disk1, start array again and now I can see the that Data has started rebuilding from the gui. Will let you know how it goes. T.
February 16, 20179 yr Yes, you need to use the -L option. Best to wait until the unnecessary rebuild completes. The SSD is assigned as Disk5, which is part of the array.
February 16, 20179 yr Author I will wait until the process of the rebuilding array is done and I will run xfs_repair with option -L Thank you for your comments and prompt respond. Will let you know how it goes. Probably tomorrow. T.
February 16, 20179 yr When the rebuild completes the disk will still show as unmountable. The warning about data loss when using the -L option is perhaps a little misleading. It simply discards the journal so any uncommitted transactions are lost, which in practice tend to be minimal. You'll need to have the array started in Maintenance mode, of course.
February 17, 20179 yr Community Expert Just thought I would note that you waited only 6 minutes for a reply before starting the unnecessary rebuild. Sometimes a little patience can actually save time.
February 17, 20179 yr Author HI Guys, I have run this morning the following command which fixed my issue: xfs_repair -v -L /dev/md1 Could someone please advise why this happened in the first place and what could cause this issue ? Thank you T.
February 17, 20179 yr Community Expert Could someone please advise why this happened in the first place and what could cause this issue ? Have you ever powered off by some means other than using the webUI?
February 17, 20179 yr Author HI. I don't remember using command line to shutdown/reboot unraid. I think about 1 month ago I upgraded the IOS on unraid and upgraded from ver 6.1.9 to the version 6.2.4 and performed reboot afterwards. Thank you very much for your support guys. It was very helpful.
February 17, 20179 yr Incorrect shutdown, perhaps by the loss of power or if the system crashes and has to be forced to power down, is the most common cause of file system corruption.
February 17, 20179 yr Author thank you for explanation and for your assistance on that. Much appreciated.
Archived
This topic is now archived and is closed to further replies.