Drive shows as 'Unmountable: not mounted'

[craig_read]

Ok.. so I am having a problem.

 

I recently replaced a drive with a new one, and the parity re-build process completed but the drive was showing as unmountable.

 

I (unsure if this was the right thing to do or not) formatted the drive in MAIN, and then it showed as empty but active in the array.

 

I paniced... shut down the array... took the drive offline again.. formatted it... and put it back into the array and it's now rebuilding again.

 

The drive is showing as 41.9GB used and nearly 6TB free, this is incorrect.  The original drive had a lot more data on it than this. 

 

I'm looking at my shares and I can see that they're emulated, so I am assuming parity is maintaining those.

 

I'm not sure what to do, I am concerned I'm about to loose a whole bunch of data from the array once re-build completes.

 

Can someone advise me on the best approach to take here?

[JorgeB]

15 minutes ago, craig_read said:

I (unsure if this was the right thing to do or not) formatted the drive in MAIN

It's not, there's even a big pop warning about it:

 

 

If you still have the old disk intact and assuming it's not dead you should be able to recover data from there, see if it mount with the UD plugin, if it doesn't post the diagnostics.

[craig_read]

Haha...... yeah I figured... I can still see all my "emulated" data... so there is a way I can "copy" it back?  If not.... that's life

[craig_read]

Here is the diagnostics.

tower-diagnostics-20220425-1422.zip

[JorgeB]

2 minutes ago, craig_read said:

I can still see all my "emulated" data... so there is a way I can "copy" it back? 

What do you mean? Disk6 is empty so any data there is lost, you can see the rest of the array data.

 

5 minutes ago, JorgeB said:

If you still have the old disk intact and assuming it's not dead you should be able to recover data from there, see if it mount with the UD plugin, if it doesn't post the diagnostics.

 

[craig_read]

Ok so I've definitely lost anything that was on disk 6?  Oh well.. you live and learn I guess.. I've gone through and anything that was important I still have.. the rest is pretty incidental.  I guess I learned a good lesson quite lightly!

 

Also important stuff is backed up in multiple places so again.. incidental really...

 

Out of interest.. what should I have done?

Edited April 25, 2022 by craig_read

[JorgeB]

17 hours ago, craig_read said:

Out of interest.. what should I have done?

 

Check filesystem

[craig_read]

Ok.. it has happened again...

 

Attached is the results of the check... not sure what I am looking at if I am honest..

Disk Check.txt

[craig_read]

I'm trying to run;

 

xfs_repair -v /dev/md6

 

But I am getting the following failure;

xfs_repair: cannot open /dev/md6: Device or resource busy

 

 

[Squid]

Did you start the array in Maintenance Mode?

[trurl]

You must start the array in Maintenance mode. Also, I suggest NOT doing the check / repair from the command line. You can do it from the webUI by clicking on the disk to get to its page. If you do it in the webUI, it will use the correct command. Your post did show the correct command, but it is possible to get that wrong especially if following some random post on the internet or even this forum.

[trurl]

And you should post new diagnostics in your NEXT post if you haven't rebooted so we can try to see what caused this.

[craig_read]

Yes I did, I'm just in the process of rebooting (which weirdly fixed the same issue with the cache drive) but disk 6 is still in the same condition.

 

 

[craig_read]

Diagnostics attached.

tower-diagnostics-20220427-1544.zip

[craig_read]

10 minutes ago, trurl said:

And you should post new diagnostics in your NEXT post if you haven't rebooted so we can try to see what caused this.

 

Sorry I saw this too late.. apologies.

[craig_read]

Phase 1

- find and verify superblock...

- block cache size set to 720104 entries

 

Phase 2

-using internal log

-zero log...

Log inconsistent (didn't find previous header)

empty log check failed zero_log: cannot find log head/tail (xlog_find_tail=5)

ERROR: The log head and/or tail cannot be discovered. Attempt to mount the filesystem to replay the log or use the -L option to destroy the log and attempt a repair.

 

 

is it safe to run again from the GUI with "-L" in the options box next to CHECK?

[JorgeB]

8 minutes ago, craig_read said:

is it safe to run again from the GUI with "-L"

Usually yes, though if you're getting constant filesystem corruption without an apparent reason there might be a hardware issue, like bad RAM.

[craig_read]

Ok I have ran this now, after I don't see anything coming from the log that looks bad.  I'll do a reboot now and go back into maintenance mode to see if it mounts properly.

 

Is there a memory tester built in to UNRaid?

[itimpi]

1 minute ago, craig_read said:

Ok I have ran this now, after I don't see anything coming from the log that looks bad.  I'll do a reboot now and go back into maintenance mode to see if it mounts properly.

In Maintenance mode the drives are not mounted - this only happens in Normal mode.

 

2 minutes ago, craig_read said:

Is there a memory tester built in to UNRaid?

There is a version of memtest86 you can select from the Unraid boot menu if you boot in legacy mode.

 

if you use UEFI boot mode or have ECC RAM then you should download the latest version from memtest86.com.

[craig_read]

Ok... it's back...  I can trace all this to a few operations I think... so I'll just complete the tidy up operations and then go from there now...