I had a drive that was failing 1.5tb I shutdown unraid 6.5 and installed a new drive last night. It looked like it was rebuilding over night. When I got home today it showed the drive as unmountable: No file system. I tried rebooting but no go, same message. Is there away to force the rebuild again on the new drive. I have the old drive but when I inserted it back into the array the message said you can not replace with a smaller drive. I have not done a lot with unraid so I need to know what to try next. The old drive still seems to be readable if formatting the drive is the best option I would prefer to rebuild thou. 

 

Thank You Mark

 

Please post your diagnostics: Tools -> Diagnostics

Here is the diagnostic file and a screen print of main. There was a power outage after my post which caused a parity check / rebuild but nothing seemed to change.

sagetv-diagnostics-20180405-0602.zip

 

Edited April 5, 20188 yr by mechling-burgh

15 minutes ago, mechling-burgh said:

There was a power outage after my post which caused a parity check / rebuild but nothing seemed to change.

That's unfortunate since I'd like to see the logs covering the rebuild, also not good for the server, consider getting an UPS.

 

As for the unmountable disk, if there were no errors during the rebuild xfs_repair should fix it:

https://lime-technology.com/wiki/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui

 

I was thinking that also. It was just a media server so I wasn't worried about but I'm starting to we have the power cut out three time in the last month for five to ten minutes. I'm thinking maybe the rebuild button was not checked before the array started. I have a mouse and display on the server and the mouse button seems to double click or not click at all. I noticed it last night when I was working on this. I will give this link a try. will running these steps take the server off line. just trying to figure out when to do this. Also if this does not work will formatting the drive and copying the files back be alright or will this mess up the file system?

 

Thank You for your Help, Mark

will running these steps take the server off line. just trying to figure out when to do this.

Yes, just follow the instructions on the link.

 

Also if this does not work will formatting the drive and copying the files back be alright or will this mess up the file system?

If you mean copying back from another source it's OK, no problem, it's not possible to rebuild from parity after formatting, might seem obvious but a surprising large number of users don't know.

 

 

Yes I read that in some other posts. But I also read about file systems being screwed up from doing I thought. I just wanted to know it was a fall back option, that is why I did before the the drive failed.

2 hours ago, mechling-burgh said:

Yes I read that in some other posts. But I also read about file systems being screwed up from doing I thought. I just wanted to know it was a fall back option, that is why I did before the the drive failed.

It is quite normal for a drive to show as unmountable after a disk has been disabled due to a write to it failing.    In such cases running a file system repair on the disk nearly always fixes things without data loss.    

 

Just as aside it is possible to do a file system repair on the emulated drive before doing the rebuild.     The advantage of doing this is that you can check that the emulated drive has the content you expect (and thus what you will get after a rebuild) while you still have the ‘failed’ disk unchanged (and thus available if more drastic error recovery actions are required).

Ran the xfs_repair scan as suggested (options -nv), no options came up in the options box has the directions said it would for a repair. When I restarted the array it did a parity check  again but was still unmountable before and after the scan. I reran the xfs_repair a second time but same results and the array started another parity check when I brought the array back up. I have attached diagnostic file and the two xfs_repair logs.  Any other ideas on what to try. It must of tried to rebuild build when I first installed it since it is showing the drive as XFS format and I did not format it. The reads are going up but the writes are staying at 5 no change from the scans and the parity check in case that means anything.

Scan Log.txt

sagetv-diagnostics-20180406-1659.zip

xfs_repair-first.txt

You need to remove -n or xfs_repair won't fix anything.

Okay run a straight check no options this is what come back in the message area now.

 

Phase 1 - find and verify superblock...
        - block cache size set to 753680 entries
Phase 2 - using internal log
        - zero log...
zero_log: head block 122215 tail block 122207
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.

 

Should I run it or will it screw up the files system like it says. I can't mount it because it says unmountable.

 

You need to use -L

Okay ran with -L option got this message

 

Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
agf_freeblks 1750359, counted 1527671 in ag 1
        - 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 = 2
        - agno = 3
        - agno = 1
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
rebuilding directory inode 1073741920
xfs_repair: phase6.c:1308: longform_dir2_rebuild: Assertion `done' failed.

 

Restarted the array and and still say's unmountable and started running another parity check (Takes 9.5  hours to run). Any other options to try, Thank you for your timeand help by the way.  I think the old drive is still readable is there a way to mount it and  be able to copy the old file onto the new drive if I have to format it.

 

No point in running a parity check for now, try xfs_repair one more time after updating to last release.

Okay updated OS and and reran the xfs_repair, still a no go any other suggestions or are we at the end of options on the rebuild. One nice thing thou is after deleting the logs the parity check stopped running after reboots and array restarts.  I'm sure it's something I did but it still stings it didn't rebuild. One of the reasons I switched was for the disk failure. Again thank you for your help windows I know pretty well Linux and unraid just a little bit.

 

Mark

If xfs_repair can't fix the disk you'll need to to restore data from backups (if available), though a newer xfs_progs may be able to fix it in the future, you can also ask for help in the xfs mailing list, xfs_repair shouldn't fail to fix the filesystem, with more or less data loss.

Okay so format the drive again I guess, I'm at my max drive count can I mount the old drive using unassigned devices and copy the files off or will I need to get a program to reat XFS on windows and copy it over the network, which is the best approach do you think. One last question is there away to force a rebuild for one last try?

 

Mark

 

4 minutes ago, mechling-burgh said:

One last question is there away to force a rebuild for one last try?

Yes, but you'll likely get the same result, possibly parity wasn't 100% valid, if you want to try, stop the array, unassign that disk, start the array and you check the emulated disk, whatever is emulated is what's going to be rebuilt.

 

7 minutes ago, mechling-burgh said:

I'm at my max drive count can I mount the old drive using unassigned devices and copy the files off or will I need to get a program to reat XFS on windows and copy it over the network, which is the best approach do you think.

If you can hotplug the disk after array start you can use the UD plugin.

okay formatted the shows up as device contents emulated. stopped the array ran the xfs_repair re started array and it still comes up emulated. The parity check is running right now will this fix the emulation mode problem?

Haven't really been following this thread, but I don't understand why you keep getting a parity check. Also, a parity check will not change anything unless it is a correcting parity check, and even then it won't change anything except the parity disk. A parity check can't really do anything except possibly correct parity errors. It won't have any effect on your data.

 

Are you cutting the power without shutting down from the webUI? Getting a parity check every time you boot up is not at all normal.

 

 

Your most recent posts sound as if you decided to format the disk and try to recover the data from another drive. But formatting a disabled disk is only going to format the emulated disk, which seems to be where you are now.

 

I'm not going to try to tell you how to proceed at this point in case I am misunderstanding some things in this thread. But the whole thread is kind of confusing anyway because of all the parity checks. I don't know if you are starting these parity checks (why?), they are starting automatically (not normal), or you are just saying "parity check" when really something else is happening.

 

The parity sync / rebuild not checks I guess my bad, are running by them self's any time I did a stop array or powered down properly. It's doing it right now but for the first time it is writing to the new disk, but the disk info is saying "Device info emulated'. I found this in trouble shooting. If it does write stuff to the emulated drive I will try the re-enable hard drive. I have nothing to lose at this point.

Re-enable the drive

Okay, you are sure the drive is good, but the cable was loose, or the port was bad, or the controller crashed, or you think the failure was a fluke ( note: it is NEVER a fluke )- how can I get unRAID to reuse this same disk that it has disabled?

If you are sure that the drive is fine, and the SMART report confirms it, then you will want to re-enable the drive, and return it to service. There are 2 ways to do it. Remember however that while the first way is quick, there may have been writes to the drive, including the write that failed and caused the red ball. Those writes went to the emulated drive, not the physical drive, so by far the best and safest option is the second way, to rebuild the drive onto itself, writing the up-to-date emulated drive to the physical drive.

You can re-enable the hard drive and reconstruct it as follows:

• Stop the array.
• Go to the Main page (Devices in version 4.7) and unassign the disk.
• Go to the Main page (Array Operations section) and start the array.
• Stop the array again.
• Go to the Main page (Devices in version 4.7) and re-assign the disk.
• Go to the Main page (Array Operations section) - the system should indicate there is a "new" drive to replace the disabled one. Check the confirmation box and click the Start button to start a reconstruct/rebuild of the disk.

okay it must of tried to do a rebuild it wrote to the disk this time but when it was done it came out of emulate mode but the disk was empty which is what we figured would happen. thank you for all your help I will now try to spin up the old drive and copy it over.

10 hours ago, mechling-burgh said:

The parity sync / rebuild not checks I guess my bad, are running by them self's any time I did a stop array or powered down properly.

If this continues to happen then the server is not doing a clean shutdown, you need to figure out what's preventing that, diagnostics might help and they should be saved in the logs folder of your flash drive when this happens.

I will do a clean reboot when I get home to check. All seems fine now as soon as it finished the parity sync the drive came back. I plugged in the old to a usb reader but as soon as I mount it it become unmounted. I think its a bad log file also, I'm wondering if it is  in of the bad sectors on the drive and what screwed up the rebuild. Is there anyway to recover the files on another machine with another program or a linux install.

5 minutes ago, mechling-burgh said:

Is there anyway to recover the files on another machine with another program or a linux install.

You should be able to boot up a linux distro from a flash drive and read the disk if it is readable.