My friends server was red balling on disk2. I checked all the connections and then rebuilt the drive. After the rebuild was done it reported that the drive was now unformatted. I decided it was time for a new drive. He is waiting for his new drive to arrive but the server is missing files so it would seem that unraid is not simulating that drive from parity.

 

Why would that happen?? He is busy trying to rebuild the drive again now.

My friends server was red balling on disk2. I checked all the connections and then rebuilt the drive. After the rebuild was done it reported that the drive was now unformatted. I decided it was time for a new drive. He is waiting for his new drive to arrive but the server is missing files so it would seem that unraid is not simulating that drive from parity.

 

Why would that happen?? He is busy trying to rebuild the drive again now.

unformatted, is unfortunately a misleading error output.  "un-mounted" is far more accurate.

 

Whenever unRAID is unable to mount a drive, for whatever reason, it reports it as unformatted.  That misleading error message is probably the cause of more data loss in unRAID than almost anything else, as users like yourself attempt to repair the "unformatted disk"

 

Typically, it is a file-system that has some corruption that prevents it from being mounted.  Occasionally, it will show as unformatted if the server was shut down improperly and the file-system journal needs to be replayed before the disk can be mounted.  (I've seen this take 30 to 45 minutes on a 2TB drive, it would take longer on a larger drive is there was a lot of prior activity before the improper shutdown)  The disk would show unformatted for this interval... and then show as mounted once the replay was completed and the disk mounted. (and the unRAID management screen refreshed to read the new mounted status)

 

Improper attempts at running a file-system check and subsequent repair is probably the second most common cause of data loss in an unRAID array.  (the file-system repair being done to the wrong partition and in fact causing additional damage rather than repair)  Unless you know exactly what you are doing, and are willing to introduce party errors that will require subsequent correction, you should NEVER run reiserfsck on the /dev/sdX1 devices.  (It absolutely should NEVER be run on the /dev/sdX devices... ever...)

You should ALWAYS use the /dev/mdX devices.

 

Even with a fully defective disk (completely un-plugged even) the disk (the simulated disk as re-constructed by the unRAID "md" driver) will normally be able to be mounted and all the files accessible.  For that reason, I doubt your physical disk is the reason your file-system cannot be mounted.

 

Seek help from lime-technology.    They should be able to guide you to getting the file-system repaired and mounted.