All drives show as UNFORMATTED except for one

[cbf305]

Hi Everyone,

 

I setup a 3 disk unRAID server about 3 weeks ago.  It ran great.  I had three free SATA ports on my MOBO.  My end goal is to have a 21 drive (including cache) system.  So I ordered two SuperMicro AOC-SAT2-MV8 controllers and unRAID Pro.  I got unRAID pro about a week ago and added the next three disks.  No issues.  I started copying my media from my old server to my new unRAID server.  Again, no issues.  The controller cards cam in yesterday, and I put one in.  I added two more drives, again no issues.  I then copied about 250 GB of data to the 1.75TB array.  This morning before I left for work I started a 330 GB move.  I have TeamViewer setup on my machine so I can remote in and monitor the transfer.  About 14 GB into the transfer the array just dropped off the network.  I could not load the web pages or ping it.  I went home for lunch and the console was also unresponsive, so I had to hard reset the machine.  When it came back up, 6 of the 7 data drives were showing as UNFORMATTED and the last one, which was actually part of another user share was showing as OK.  Of course I panicked and hit the forums.  I found how to copy the syslog off to the flash key, and took a look, but I dunno what to look for.  Anyway it's attached.

 

I also had unmenu installed, so I went to that web page to get some more info.  It showed that all 8 drives were correctly detected, but only the parity and disk7 were mounted.  The server was running a parity check.  No suggestion from the forums allowed me to stop the array or power off the machine.  I couldn't even kill anything or shutdown from the console, it would accept the commend and then issue a single beep.  I didn't want to just hit the power switch for fear that I would loose my data, so I kept trying to stop the parity check in the unmenu Array Management page.  It kept producing an error, but as I would refresh the page I would start to see the other disks getting mounted.  After about 5 or so minutes all the drive mounted and the partiy check completed.  After which the array showed as started and I was able to control the system again.

 

My current setup:

mobo:  TYAN Tomcat S5112 - P4 w/ HT, 4GB RAM

PS: 550W Antec

SATA: 6 onboard and one of two AOC-SAT2-MV8 controllers

Drives:  8 x WD2500JD

unRAID 4.5 Pro

 

The 8 disks are setup in two user shares with simple security:

disks 1-6 - Movies

disk 7    - Users

 

The array is currently online, but idle.  I dunno if this was just a fluke, but any help/suggestions would be appreciated.

 

Thanks!

[Joe L.]

Because your array was hard-reset by you when it went un-responsive, it was not a clean shutdown.

 

when you powered back up, the transactions that had not yet been committed to the disks were re-played by the file-system journal.  While it did this, it delayed the "mount" of each disk until it was done.  Since you had a massive amount of files being copied when you hard-reset, the replay from the journal in the file-system took some time.   You just needed to be patient at that point. 

 

If you had gotten a copy of the syslog before the hard-reset it might have had some clues for analysis as to why the array went un-responsive.

 

The "unformatted" description is misleading.   unRAID should probably show "mounting" instead at that point.

 

Looking in your syslog,  disk7 only had a few "transactions" in the journal.  It came online quickly.

Jan  6 10:28:05 Storage kernel: REISERFS (device md7): checking transaction log (md7)

Jan  6 10:28:05 Storage kernel: REISERFS (device md7): replayed 2 transactions in 0 seconds

 

The others had many transactions and took about 10 minutes or so to come online.

Jan  6 10:28:05 Storage kernel: REISERFS (device md6): checking transaction log (md6)

Jan  6 10:28:05 Storage kernel: REISERFS (device md5): checking transaction log (md5)

Jan  6 10:28:05 Storage kernel: REISERFS (device md1): checking transaction log (md1)

Jan  6 10:28:05 Storage kernel: REISERFS (device md4): checking transaction log (md4)

Jan  6 10:28:05 Storage kernel: REISERFS (device md2): checking transaction log (md2)

Jan  6 10:28:05 Storage kernel: REISERFS (device md3): checking transaction log (md3)

Jan  6 10:37:13 Storage kernel: REISERFS (device md6): replayed 509 transactions in 548 seconds

Jan  6 10:37:40 Storage kernel: REISERFS (device md5): replayed 533 transactions in 575 seconds

Jan  6 10:37:54 Storage kernel: REISERFS (device md4): replayed 566 transactions in 589 seconds

Jan  6 10:38:07 Storage kernel: REISERFS (device md1): replayed 562 transactions in 602 seconds

Jan  6 10:38:28 Storage kernel: REISERFS (device md2): replayed 571 transactions in 623 seconds

Jan  6 10:38:37 Storage kernel: REISERFS (device md3): replayed 536 transactions in 632 seconds

Also... are you aware you are only connecting to the LAN at 100Mb/s. ??

Jan  6 10:28:09 Storage kernel: e1000: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX

 

It appears as if you might have canceled the parity check.  If you did, you probably should initiate a new manual check.  It is appropriate for it to occur after a hard reset, and it usually will find some small number of errors to correct in parity for the housekeeping portions of the data disks.

 

Joe L.