Disk #2 is not accessible. When I access it over the network, it shows unavailable. However, it shows "green" in Unraid. I believe that I know what has happened. I think I have copied a file that fills the disk to 100%. Basically filled it to a degree that I can no longer access it.

Any idea how to fix this? I currently don't have parity, so really hope that I don't have to lose the disk?

 

Diagnostic attached

tower-diagnostics-20170421-1953.zip

You need to run xfs_repair on disk2 (md2):

 

https://lime-technology.com/wiki/index.php/Check_Disk_Filesystems#Drives_formatted_with_XFS

Well, parity wouldn't have helped with filesystem corruption anyway, but why do you have so many drives, mostly full, and no parity?

 

And, since you aren't using user shares there isn't any way for unRAID to switch to another disk when one of them gets too full, so you will have to be very careful or you will do this again.

 

 

2 hours ago, johnnie.black said:

You need to run xfs_repair on disk2 (md2):

 

https://lime-technology.com/wiki/index.php/Check_Disk_Filesystems#Drives_formatted_with_XFS

 

Thanks for your help. Unfortunately, this did not solve it yet. Please see error message below:

 

*** root@Tower:~# xfs_repair -v /dev/md2
*** Phase 1 - find and verify superblock...
***         - block cache size set to 1421560 entries
*** Phase 2 - using internal log
***         - zero log...
*** zero_log: head block 362756 tail block 362750
*** 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.

Use -L, usually there's no data loss.

Perfect, this fixed it. Thanks!