First, sorry for saying that there were two red dots, until I looked really closely they both looked the exact same colour. Second, every drive according to telnet was unmounted even though the webgui said that disk 3 was still up. I said this as well, that every drive was unmounted. But don't worry about it.

 

before I did the trusted recover option, I tried running the reiserfsck on MD1. It came back with no such file or directory.

 

So then I tried Joe's third option and followed the instructions. All drives went blue, the command did exactly as written and so I pressed start, and now it's running through a parity check.

 

this will take a while as there is nearly 5TB's of storage. Hopefully it will run through ok. 

 

Will I post the syslog when it is finished? or should I do a reboot then post that syslog?

 

cheers for the help so far.

First, sorry for saying that there were two red dots, until I looked really closely they both looked the exact same colour. Second, every drive according to telnet was unmounted even though the webgui said that disk 3 was still up. I said this as well, that every drive was unmounted. But don't worry about it.

 

before I did the trusted recover option, I tried running the reiserfsck on MD1. It came back with no such file or directory.

 

So then I tried Joe's third option and followed the instructions. All drives went blue, the command did exactly as written and so I pressed start, and now it's running through a parity check.

 

this will take a while as there is nearly 5TB's of storage. Hopefully it will run through ok. 

 

Will I post the syslog when it is finished? or should I do a reboot then post that syslog?

 

cheers for the help so far.

You can post the syslog now... and then again after the parity check has finished, but before you reboot.  Any reboot would start the log new and we would lose all the data it collected as you went about the restore.

 

Actually, I wanted a new syslog before you started any procedure, but now that it is started, do not stop it... you should see all the drives as green and a parity check in progress?  Is this true?

 

Do you see any parity errors on the management web-page?  (should be few to none, depending on if the power failure occurred while writing to the disks)

 

Do not stop the parity check.  Let it run to completion and then post a new syslog.  Hopefully, there will not be any errors on any of the other disks.

 

Joe L.

Apr  2 22:50:34 Projectx emhttp: shcmd (12): mkdir -m 700 /mnt/disk1

Apr  2 22:50:34 Projectx emhttp: shcmd (13): mount -t reiserfs -o noatime,nodiratime /dev/md1 /mnt/disk1  >/dev/null 2>&1

Apr  2 22:50:34 Projectx kernel: ReiserFS: md1: warning: sh-2006: read_super_block: bread failed (dev md1, block 2, size 4096)

Apr  2 22:50:34 Projectx kernel: ReiserFS: md1: warning: sh-2006: read_super_block: bread failed (dev md1, block 16, size 4096)

Apr  2 22:50:34 Projectx kernel: ReiserFS: md1: warning: sh-2021: reiserfs_fill_super: can not find reiserfs on md1

Apr  2 22:50:34 Projectx emhttp: shcmd: shcmd (13): exit status: 32

Apr  2 22:50:34 Projectx emhttp: shcmd (14): rmdir /mnt/disk1

Apr  2 22:50:34 Projectx emhttp: disk1 mount error: 32

 

My comments were based on both syslogs, including the above which is essentially identical to the first syslog, even though it is *after* the cable changes and a reboot.  Probably because the Parity drive was not green, it did not even *try* to mount a reconstructed Disk 1.  All other drives were mounted fine.  Now after using the 'Trust' procedure, to which I totally agree, we should be able to recover the Parity drive and be in a position to rebuild Disk 1 if necessary.  And we can confirm from the next syslog what the real status of that drive is.

 

Just saw your new post, that is great news!  If it is running a parity check now, then everything should be fine!  Probably will be a few parity corrections.  Get the syslog BEFORE you consider rebooting.

Hey Joe and Rob,

 

All drives are green, I followed the instructions on the link you posted Joe. If any of the drives had been any other colour I would have stopped.

 

But, it's great news, it's 10% done and 921 errors so far. But all those errors occured in the first 1%.

 

I will post the syslog as soon as it finishes. It will take about 10 hours.

 

thanks for your patience guys 

Glad it is up and running.   Let's see how the parity check does.

 

Because it found errors, once it finishes you should run a second parity check.  It should find no errors. (The second test is just to ensure nothing else in your hardware is causing errors)

 

As an aside... A PM from Tom to me indicates he has written an improved "Stop" button command that will handle open files, etc on file-systems before they are un-mounted.    It should be in the next beta. Hopefully, at that time, these issues of "Unformatted" drives being incorrectly reported when the array is stopped will be behind us.

 

Joe L.

 

As an aside... A PM from Tom to me indicates he has written an improved "Stop" button command that will handle open files, etc on file-systems before they are un-mounted.

 

I hope it will inform that open files exist and shat they are... more than once I've gone to shutdown unRAID, not realizing I had something running with open files that I did not want to kill.  That's why I wrote a scripted shutdown that will stop and inform if open files or loopbacks are found.

As an aside... A PM from Tom to me indicates he has written an improved "Stop" button command that will handle open files, etc on file-systems before they are un-mounted.

 

I hope it will inform that open files exist and s what they are... more than once I've gone to shutdown unRAID, not realizing I had something running with open files that I did not want to kill.  That's why I wrote a scripted shutdown that will stop and inform if open files or loopbacks are found.

Excellent point.

 

Joe L.

ok, the parity check has finished and everything looks fine.

 

It found 921 errors. Please see below for the syslog.

 

Should I now reboot the server and get another syslog? and do another parity check?

 

ok, the parity check has finished and everything looks fine.

 

It found 921 errors. Please see below for the syslog.

We expected to see some... glad they were all in the housekeeping areas in the first block or so.

Should I now reboot the server and get another syslog? and do another parity check?

Yes, yes, and Yes.

 

Over the past year or so as you've owned the server, how often did you perform a manual parity check?

 

Do you have any non-standard scripts or programs loaded or running?

 

Are you running any additional processes via "cron"?

 

Hope you don't mind the questions...  (Just curious what might have kept your disk "busy"?

 

You might consider a UPS to get you through minor power blips...

 

Joe L.

This is one for the books, really strange!  Your last syslog shows exactly the same errors trying to read and mount Disk 1.  In fact, it does not even try to mount a virtual reconstructed Disk 1 !!!  But once you reset the configuration with the Restore button, and threw out the old super.dat file, and created a fresh one, Disk 1 was recognized correctly, the Reiser file system was read without issue, and the drive was mounted.  Shows I have much to learn I guess.

Don't mind the questions at all.

 

I have a lot to learn, and yes I am considering getting a ups.

 

I have done a manual parity check a few times. Have the server about 8 months and have done it about 5 times. Twice because I was upgrading disks.

 

The only thing I have running different is the twonky media server. I didn't add anything else.

 

LOL, and I don't know what cron is, so I doubt I am running any additional processes 

 

I will reboot the server when I get home and post the syslog I get after the reboot.

This is one for the books, really strange!  Your last syslog shows exactly the same errors trying to read and mount Disk 1.  In fact, it does not even try to mount a virtual reconstructed Disk 1 !!!  But once you reset the configuration with the Restore button, and threw out the old super.dat file, and created a fresh one, Disk 1 was recognized correctly, the Reiser file system was read without issue, and the drive was mounted.  Shows I have much to learn I guess.

He had not rebooted since the first syslog. Look at the dates, unless I'm mistaken, the syslog lines where the mount failed were exactly the same because they "were the exact same lines from several days ago"

 

Everything looks fine from where he used the "trust parity" process.

 

Joe L.

Hi,

 

Well here is the syslog from the restart I have just done.

 

Joe, I did restart the server between the two previous syslogs I posted. I had to restart, because I replaced a SATA cable. 

 

Anyway, here is the syslog. And I am now running another parity check. Will have the result of that one tomorrow.

 

Thanks guys 

ok, everything is back working and no loss of data 

 

Thanks everybody for the help especially Joe and Rob. The parity check can back with no errors.

 

Now just go out and buy a UPS