Literally sitting her pushing Refresh for 3 hours    Has anyone implemented ajax into the interface yet?

 

So, here's my result:  Last checked on 9/12/2009 11:10:29 AM, finding 16  errors.

 

Now, I've created a 1.1 GB ZIP file; I'm going to transfer it to the array as a copy, then MD5 both the local and unRAID copy.  I will then run another parity check and see what it turns up, keeping in mind none of my drives are using the motherboard's headers now.  I have two Silicon PCI cards, each with 2 ports.  So now that parity has been recalculated, anything I do will be done off the pci bus.

 

This'll take a while... be back later!!

 

Robbie

OH NO.

 

What just happened?

 

After the parity check, I pressed Stop so I could shut down the server to close it up.

 

Now:

disk1  ata-ST3160812AS_5LS287JY  *  156,290,872  Unformatted  500,244  20  0

 

Excuse me??!

 

Thoughts?

I also cannot seem to stop the array now, so I cannot do a safe shutdown.  Any time I push Stop, it does nothing (besides graying out for a moment as if it were shutting down, but it doesn't).

It finally stopped after pushing Stop a bunch of times, and then came back online and the drive is no longer showing as unformatted.  What on earth just happened?

 

Thanks,

Robbie

Alright Joe, I'm about to cry.

 

Local:

-rw-r--r-- 1 robbie robbie 1130216899 2009-09-12 10:56 testfile.zip

9c3b3eb65e00c18cffb058a91c0903e7  testfile.zip

 

unRAID:

-rwx------ 1 root root 1130216899 Sep 12 09:56 testfile.zip*

3f3c70c7c114144755b232110e102da3  testfile.zip

 

I'm not going to bother running a parity check.  What do I do?

 

Thanks in advance.

Actually, scratch that: I will run a parity check to see if it corrects the file (to give me peace of mind regarding all the files that are currently on my array).

 

I'll watch for replies and won't write anything to the array in the meantime.

 

Thank you!!

The Unformatted bug is a well known problem and one that occurs when there is something accessing the drive.  this can be a lot of things, telnet session into a directory, etc.  With the additions and stuff that have been made to unRAID by this community it is not so uncommon to see new users scared by seeing the Unformatted label.  As long as the format button is not pushed you are fine.

 

be sure to check out the FAQ section of the unRAID wiki along with the How-To's and Topical Index sections.

It finally stopped after pushing Stop a bunch of times, and then came back online and the drive is no longer showing as unformatted.  What on earth just happened?

 

Thanks,

Robbie

I'll point you to the wiki on this one...  You probably had "cd'd to one of the disks keeping it busy... http://lime-technology.com/wiki/index.php/FAQ#Why_is_a_disk_showing_as_Unformatted.3F

 

Just stop the process accessing the disk, and press "Stop" once more.  (and don't press the Format button)

 

Joe L.

Actually, scratch that: I will run a parity check to see if it corrects the file (to give me peace of mind regarding all the files that are currently on my array).

 

I'll watch for replies and won't write anything to the array in the meantime.

 

Thank you!!

Parity will never "correct" the file, unless the disk is missing or un-assigned (simulating it is missing)  A parity "check" now will change "parity" based on what it reads from a disk. 

 

I'd try removing one of your memory strips and running with just one, or the other, and re-try the md5 with each.

 

We really do not know if the issue is with the write of a file to your data disk, or the write of the file to the parity disk, or the "read" from the parity disk, or the "read" from the data disk.  Of course, it could just be the network card... and it was mangled in transmission  (unlikely, since tcp/ip protocol has its own checksums)

 

I hate to say it, but now you know why we said early nforce chipsets have proven to be a real pain...

 

Let's try a few md5 checksums of the same large file in sequence... If it is a problem reading the file from the data disk, they could differ from each other.

 

Literally sitting her pushing Refresh for 3 hours    Has anyone implemented ajax into the interface yet?

Right about now you should try the alternate unMENU web-interface.   It auto-refreshes its main screen for you...

 

It is an alternate interface to unRAID... It does almost everything for reporting.  It does not do normal configuration and starting of the array, but it does do a better job of stopping the array, including killing process that might be keeping disks busy.

 

As I said, I'm going through a update of the package files... to update the links to the download files...so wait a day or so before you download it. (I've got to get ready to go out this evening, so I'll probably not get the new version out till tomorrow or Monday.)

 

There is a small shell script version of a basic display of the array status that will let you know of the parity check progress..  Why not download it and run it.  It too refreshes itself, but in a telnet session.

 

I attached it to this post for you.  Un-zip, move to your unRAID array, and execute as a shell script in a telnet session.

 

It is the great-grandfather to the unMENU web-interface I wrote...  It looks like this when a parity check is in progress:

 

I told you my array reports BIG numbers when I first push the "Check" button...  Don't worry... it lies.

 

Joe L.

I hate to say it, but now you know why we said early nforce chipsets have proven to be a real pain...

I don't think this particular board is using the nforce chipset, however there could be a similar problem with chipset communication.

 

Chipset	
  - Northbridge: Intel® 865GV
  - Southbridge: Intel® ICH5

 

The Unformatted bug is a well known problem and one that occurs when there is something accessing the drive.  this can be a lot of things, telnet session into a directory, etc.

 

Ahh; that explains it - thanks.  I was telnet'd in to that drive to run the md5sum.

 

Robbie

 

PS - Yes, my heart nearly stopped; it was very scary to see a data drive in my array as unformatted... but then I realized, I had just made good parity, so even if that happened (for real), I would have been okay.

Okay; just got in.  Of course, you're right.  The md5 still fails after a parity check.  So it probably means I'm losing data, right?  Or is the data perhaps okay?

 

Updated stat:

---

Last checked on 9/12/2009 3:21:51 PM, finding 23  errors.

3f3c70c7c114144755b232110e102da3  testfile.zip

---

 

I'll try the suggestion to remove a stick of RAM and try again... I'll post everything I try and my results.  Thank you to everyone for your kind assistance.  It really speaks volumes of the community here.  While I'm new to unRAID, I'm by no means a n00b; but you've shown me that even someone with very little technical knowledge would be able to find an extremely helpful group of people for support.  I don't think that should go un-praised.  So, thanks!

 

Robbie

Okay; just got in.  Of course, you're right.  The md5 still fails after a parity check.  So it probably means I'm losing data, right?  Or is the data perhaps okay?

 

Updated stat:

---

Last checked on 9/12/2009 3:21:51 PM, finding 23  errors.

3f3c70c7c114144755b232110e102da3  testfile.zip

---

 

I'll try the suggestion to remove a stick of RAM and try again... I'll post everything I try and my results.  Thank you to everyone for your kind assistance.  It really speaks volumes of the community here.  While I'm new to unRAID, I'm by no means a n00b; but you've shown me that even someone with very little technical knowledge would be able to find an extremely helpful group of people for support.  I don't think that should go un-praised.  So, thanks!

 

Robbie

We don't really know...

One way to know for sure would be to take the drive with the file from the unRAID server and put it in your other linux box, mount it there, and run the same md5 checksum.  If it was written correctly, it would have the same checksum.  If written incorrectly, then it is a different problem entirely. 

 

(nice to be able to move the drive from one server to the other...isn't it)  Just temporarily mount it as read-only in the other linux box, otherwise the reiserfs superblock might get modified with the mount time, and result in a "parity" error when you run the next check when you put it back in the unRAID box... It would not be one that corrupts data, but you should not be surprised if it occurs.  It would show almost immediately when you press the check button being in the first block or so of data in the file-system.

 

Now, knowing the data is written properly, but read back improperly does not lead to a solution, but you at least know where to check. 

 

Joe L.

Yeah Joe.  I think what that would do for me, more than anything, would be assure me that my data (380 GB) is okay.  Fortunately I was ... ahem ... "Smart" and didn't put our family photo collection or anything like that on there yet... but in the interest in freeing up some space, there is quite a bit of video production files (from the show) that are sitting on unRAID with no duplicate elsewhere on the network.

 

I'm booting up now with a solitairy stick of RAM, and will try my MD5 test again.  If that fails, I'll try the other stick single channel as well, and then will do the "mount this on another box" test.  YES, that is BRILLIANT -- a HUGE selling point for unRAID if you ask me.  Plus, I have a Thermaltake BlacX on my desktop computer (which runs Ubuntu exclusively), and the unRAID box is a hot-swap cage, so to do the drive move is beyond simple.  Yes; I'll stop the array, and I'll actually shut down too.  Just expressing that the drives themselves will be a breeze to remove and move to another system for testing.

 

Thanks for all the great direction!

Bad news: the md5 is wrong when mounted on my other PC.  So... the MD5 is going bad during the write operation, it would seem.

 

I've tried the different sticks of RAM in single channel mode, and no go.

 

Next up?...

 

Robbie

How big is your flash?

 

Maybe you could put shutdown the unraid syste,, put the flash on your other machine and copy some large video files on your flash,

Then boot unRAID, do some copy compare operations This would eliminate the network interface.

 

Speaking frankly, I would be ascared to trust my data on that board.

What was the reason to retire it in the first place?

 

Any other junk in the trunk?

 

FWIW, your drives are good.

Another test could be to eliminate the PCI SATA cards.

 

Just have 1 Parity drive and 1 data drive on the motherboard alone.

This will work and you would still be protected (for the one drive).

 

You could do cmp's or md5's over the network to insure data is intact.

I.E. I believe the Parity disk is a mirror if there is only one drive.

 

Shouldn't be having this much trouble.

Bad news: the md5 is wrong when mounted on my other PC.  So... the MD5 is going bad during the write operation, it would seem.

 

I've tried the different sticks of RAM in single channel mode, and no go.

 

Next up?...

 

Robbie

Well... you've used two different disk controllers... probably not both of them

You've used two sets of memory strips (or at least different combinations) I trust you did set the voltage, timing, and clock speed appropriate for your specific memory.

 

We are pretty certain the data is being written incorrectly... and when read later and compared via the parity check to what it thought should be on the disk, it was different.    This, to me indicated the "parity errors" were merely the parity disk trying to get into sync with the improperly written data to the data drive, being read back from it during the check. So, by "assuming" the data disk was the correct data, the parity check process actually ended up with parity in sync with the "bad" data.

 

If you've found that subsequent parity checks, with no data writes between are always clean, then we can assume we can read and write the parity disk correctly...  and also read the data disk consistently.  If subsequent checks sometimes find failures, with no data written in between, then we have a "read" problem too.

 

That only leaves writing to the data disk as the "failure" and writing to the data disk is done in parallel with the writing of parity, so it basically involves the disk controller and the disk itself (and the cabling to the disk)

 

I guess the next thing to isolate is if it is a single data disk, or more than one, or the disk controller...  (might be moving your disks back to the on-board controller to test this)

 

Joe L.

Hey WeeboTech.

 

Yep; next step I just completed was to pull the first PCI card and put the parity and one data drive back on the mobo.  So now I'm on Mobo & the new pci card, just to rule out the old pci card.

 

The board was not 'retired' for any reason; it was a trade-in.  A client bought a bigger & better system and wanted trade-in value.  The board is fine, the ram checks out, the CPU seems perfectly fine (I haven't run a burn-in, but there haven't been any issues that point to the CPU).  Caps are good, everything looks fine.

 

I'm going to bypass the network card by plugging in an external usb hard drive... will let you know how that goes in a moment.

 

Thanks,

Robbie

Thanks Joe.  Parity checks have seemed clean after having run one (eg. get errors first time through, then if no data written, no errors the next time I run check).  I've only done that twice (due to the time it takes) but it's been clean both times.  Once, there were 2 errors, but that was after I put that 500 MB file on the array during the check.

 

I'll check the network as a last-ditch resort and then start pulling drives... I'll throw in some old IDE drives to build a fake unraid array to see if I can get it up and running without errors...

 

I'll consult you guys before I do this, as I have to be careful not to lose the data on the existing unRAID array (even though I fear some of it may have glitches... hopefully nothing severe).

Just have 1 Parity drive and 1 data drive on the motherboard alone.

This will work and you would still be protected (for the one drive).

 

You will need to press the "Restore" button to save a new configuration if you remove the other drives.  It will re-compute parity on the remaining data drive, so use a smaller one... (parity checks will take less time.. until you can isolate the troublesome hardware, then you can add back in the other drives... Since they are already reiserfs, they will not be cleared and added with the data intact... and parity calculated as you add each in turn.

You could do cmp's or md5's over the network to insure data is intact.

I.E. I believe the Parity disk is a mirror if there is only one drive.

 

Shouldn't be having this much trouble.

If you un-assign the other data drives (you can leave them physically installed) leaving 1 data drive and a parity drive, then the parity drive, because of even parity would be a mirror of the data drive for the portion starting at sector 63 through the size of the data drive.

 

You can experiment with the flash drive movement of files as WeeboTech said.  And he is right... It should not be this hard... It is that you are working with cast-off hardware...  (was it retired because of problems? or just because it was out-dated?) 

 

Joe L.

We understand the need to protect your data. 

 

Just post as you need...  I'll be out for the evening, but be back late tonight.  Others can advise. 

 

(have to start getting ready soon to go out dancing with my wife. 

I'm not entirely a geek...

Tonight is my last night as President of a local Ballroom Dance club...

so I have to be there to turn over the role to the incoming President.)

 

Joe L.

(coding AND knowing right foot from left... sometimes )

 

Cool man--have fun!

 

Thanks again for all your help.  I appreciate it.

 

Just to clarify, is what you're saying that...

 

I have:

Parity - 750 GB

Data 1 - 160 GB

Data 2 - 400 GB

----

Is this what you are explaining based on this setup?

I can go into devices and change Data 2 to unassigned, then restart the array and press "Restore", and all data will be fine (except not protected on the 400 GB drive for now).

 

I can then test the array with just the parity and data 1 all I want.

 

When stable, I can re-select the 400 GB drive as Data 2 and it will be added to the array, DATA INTACT.

 

Is this right?

 

Cool man--have fun!

 

Thanks again for all your help.  I appreciate it.

 

Just to clarify, is what you're saying that...

 

I have:

Parity - 750 GB

Data 1 - 160 GB

Data 2 - 400 GB

----

Is this what you are explaining based on this setup?

I can go into devices and change Data 2 to unassigned, then restart the array and press "Restore", and all data will be fine (except not protected on the 400 GB drive for now).

 

I can then test the array with just the parity and data 1 all I want.

 

When stable, I can re-select the 400 GB drive as Data 2 and it will be added to the array, DATA INTACT.

 

Is this right?

 

Correct. 

 

You can at any time get to the data on disk 2 by mounting its first partition on a mount-point of your own. (or by moving it to your other PC)  It will just not be protected.

 

When disk2 added back into the array (assigned to a slot) it will need to calculate parity once more with it, but by then you will be a seasoned veteran...

(Just Don't pre-clear it!!!!! I guess you would have figured that out... but for the REAL noobs... if you zero out all the bytes on a disk... there is no "un-do")

 

 

Joe L.

Thanks Joe!  You go dance with your darling wife, and I'll dance with this server. 

 

I'll be at this for a while, and then gonna spend time with my wife too 

 

Robbie