I did not see anything glaring or obvious in the syslog.

I noticed the drives are detected in IDE mode and not AHCI mode. I do not see this as a major issue.

 

Sep 11 09:45:43 unRAID kernel: md: sync done. time=12226sec rate=59919K/sec

Sep 10 23:29:00 unRAID kernel: md: sync done. time=12053sec rate=60779K/sec

 

Your parity sync times are quite respectable.

 

I still advise using smartctl and doing a

date >> /boot/smartlog.txt

smartctl -a /dev/sda >> /boot/smartlog.txt

smartctl -a /dev/sdb >> /boot/smartlog.txt

smartctl -a /dev/sdc >> /boot/smartlog.txt

 

to provide a review of anything found on the drive itself.

If there are significant reallocated or pending sectors there may be an issue with drive.

In addition, when you see sync errors which colum is it on (parity, disk1, disk2, etc, etc).

 

See remarks in this post regaring support libs.

http://lime-technology.com/forum/index.php?topic=3642.msg38403#msg38403

 

 

Thanks.  You're asking to do this on /dev/sda.  Should I go through each drive?

 

Robbie

 

Thanks.  You're asking to do this on /dev/sda.  Should I go through each drive?

 

Robbie

 

 

Yes, each drive

 

/dev/sda

/dev/sdb

/dev/sdc

 

But also review this post and the need to install the support libs in the version of unraid you are using.

(follow this link to the post and the other related posts).

http://lime-technology.com/forum/index.php?topic=3642.msg38403#msg38403

 

Awesome; thanks.  This will take setting aside some time this weekend... I'll post my results/findings asap.

 

Thanks for all your help (to all)!

 

Robbie

BTW... I'm 30% through a parity check with 0 errors... perhaps because I have not written anything to the drive since the last check; but thought it was worth mentioning.

 

My next test will be:

- Add 10 GB to the array

- Check parity

- if parity errors >0 remove all drives from motherboard headers and move to pci

- re-run parity

- write 10 GB data to array

- run parity

 

Cool, right?

My next test will be:

- Add 10 GB to the array

- Check parity

- if parity errors >0 remove all drives from motherboard headers and move to pci

- re-run parity

- write 10 GB data to array

- run parity

Cool, right?

 

This is what I would do, however, my first point of reference would be to check the drive's health via SMART.

Then I would know without doubt if there is an issue with the drive.

 

Next time you boot go into the BIOS. See if there is an option to enable SMART checking.

This is only done during bios initialization of the motherboard drives, yet if there are significant health issues, a BIOS notice will be displayed.

 

 

Also FWIW, later on in the game, I would look in my old parts draw for a less muscular CPU and save on electricity.

 

Sep 10 20:07:15 unRAID kernel: CPU0: Intel® Pentium® 4 CPU 3.00GHz stepping 04

 

If that's a 3GHZ northwood, then fine, but if it's a presshot, I would probably be looking at a replacement or underclock/undervolting it or even trading it off

(Later on).

 

unRAID is not that CPU intensive.  Fast BUS, Memory and DISK I/O is where you gain.

If you plan to run VMWare later on then fine, but if it's going to idle allot, it could waste allot of power.

 

 

Ah yes... I suppose you're gonna make me install a monitor on that box    hehe... okay okay, I'll do it for the sake of my data - lol.

 

Thanks for the suggestion.

 

Robbie

You do not need a monitor to install smartctl. that could be installed from the network over telnet.

Also FWIW, later on in the game, I would look in my old parts draw for a less muscular CPU and save on electricity.

 

Sep 10 20:07:15 unRAID kernel: CPU0: Intel® Pentium® 4 CPU 3.00GHz stepping 04

 

It's a prescott.  While I understand what you're saying and all, I still kinda laughed because this is just an old clunker system I had kicking around.  So if unRAID is that 'light', wow.  Seriously.

 

But yeah... I suppose I could underclock it ... or something... what would you suggest?  I could always put a lighter cpu on the board..  I think I have a 1.7 GHz processor kicking around.

 

Is it really that much power to care about?  In all honesty?  Worth the trouble?

 

Thanks!!

You do not need a monitor to install smartctl. that could be installed from the network over telnet.

 

Perfect!  I'll install that and take a look; thanks!

You do not need a monitor to install smartctl. that could be installed from the network over telnet.

He does need a monitor and keyboard to check the BIOS options though...

Thanks Joe; of course, backing up a bit... remember, I thought this thing through    I set up SMART in the bios at the same time I set the bios to boot from USB 

 

The only curious factor would be, will the pci card report SMART... I would expect so, but will soon find out 

 

Thanks!

Logging my results...

 

Following this morning's sync, I have not placed ANY data on the array.  Ran a sync and got:

 

Last checked on 9/11/2009 7:47:13 PM, finding 0  errors.

 

So, now I am going to throw 12.5 GB on the array, and run another parity check after the write operation.

 

Robbie

You do not need a monitor to install smartctl. that could be installed from the network over telnet.

He does need a monitor and keyboard to check the BIOS options though...

 

Duh.. right.  

 

Also FWIW, later on in the game, I would look in my old parts draw for a less muscular CPU and save on electricity.

 

Sep 10 20:07:15 unRAID kernel: CPU0: Intel® Pentium® 4 CPU 3.00GHz stepping 04

 

It's a prescott.  While I understand what you're saying and all, I still kinda laughed because this is just an old clunker system I had kicking around.  So if unRAID is that 'light', wow.  Seriously.

 

But yeah... I suppose I could underclock it ... or something... what would you suggest?  I could always put a lighter cpu on the board..  I think I have a 1.7 GHz processor kicking around.

 

Is it really that much power to care about?  In all honesty?  Worth the trouble?

 

 

Yeah, it's light. I've run it on a 1ghz celeron-M. I've run my 2.66ghz core 2 duo at 1.6ghz.

 

Is it worth it? Depends on how the system is going to be used.

If it is up 24x7 it will require electricity and create heat. (up to 89/103watts of heat)

 

Not sure of the 1.7's heat output.   Some Prescott CPU's have enhanced halt states and thus trim down on their own.

Not sure if unRAID's kernel has this enabled.

 

I just remember in older days how my 3.2ghz presshot was so hot I would sweat when working inside it.

 

The heat just pour'ed out of that machine. I later locked the multiplier to 2.8 to keep it trimmed down.

On some machines I decided to go with the P4 2.4C which was clocked at 800MHZ and had hyperthreading.

That was a decent P4 for average use. the SL6WF's go cheap on eBay.

 

It all depends on how much you want to control your carbon footprint. LOL!

 

FWIW, when I went from a pair of reguilar XEONS to LV XEONS, the drop in heat and electricty was very noticable.

 

Here's an interesting read

http://en.wikipedia.org/wiki/List_of_Intel_Pentium_4_microprocessors

 

Don't do anything until your stable.

It was just interesting to talk about it.

Yeah I'm all about being 'environmentally conscious', but haven't really given that much thought with this rig; I kinda felt that unRAID's ability to spin down unused drives was a good power saver (over traditional RAID)... and I just use high-end cooling systems (not OEM), so the CPU does not run hot.  I have no idea how much hydro it uses though.. but again, the fact the drives are spinning down at least does something for the power consumption 

 

Not to mention, I'm 'recycling' almost the entire rig... the main selling point for unRAID for me was that very item: reusing old drives... reusing old motherboard... chassis... etc.  It's all old hardware that could have ended up in the landfill.

 

That said, if underclocking the processor would even further decrease the environmental impact, I'm willing to give it a try.

 

But like you said; I'll wait first until I have it stable before I start messing with CPU voltages and such    haha

 

Thanks,

Robbie

Status Update:

 

- Copied 12.5 GB of video files to the array

- Ran Parity Check - Last checked on 9/12/2009 3:13:21 AM, finding 516  errors.

 

Going to now move all the drives off the motherboard.  I'll also be adding a 4th drive while I have the system up on the bench, as I want to grow the array too.  Hopefully we can see some good parity once I get the hard drives off the motherboard.

 

I'm also going to add a cache drive now.

I would recommend holding off additional drives/hardware until there is a stable system.

I would recommend holding off additional drives/hardware until there is a stable system.

 

Yeah... I know... you're right.  I just need the space... 

 

Okay, I'll move the drives first, run parity, copy data and run parity again, and then if it's good, I'll add the next drives.

 

I've attached my syslog, which I updated after the most recent parity (this morning).

 

Please let me know if you spot anything.

 

Thanks!!

Robbie

I've attached my syslog, which I updated after the most recent parity (this morning).

 

I don't see a syslog attached, however, I do not expect to see anything right now.

Move the drive, do your test, then attach the syslog.

 

I can understand you need space, don't trust any data on this machine until you get a clean parity check and you review the smartlogs.

The data is fine though, as long as a drive doesn't fail -- right?

The data is fine though, as long as a drive doesn't fail -- right?

 

You are gettng sync errors, somewhere along the line, a verification of the bits is revealing miscompares.

I would consider your hardware unreliable at the moment.

 

There were issues many moons before with the nforce chipsets.

Data copied over the lan and compared with the original revealed differences.

This was not an issue of unRAID, but there were bit errors somewhere along the line in the motherboard's chipset which was fliipping bits.

I believe this has been resolved in the later kernels (It was a linux/nforce chipset issue).

 

I realize that you are not using this chipset, but somewhere along the line the compares are not matching.

 

During your tests I would suggest not deleting the original source.

This is the Achilles heal of unRAID IMO. 

Actually, this is the Achilles heal of ANY computer that does not immediately re-read what was written, to verify it got written correctly.

 

Unfortunately, this describes almost ALL computers we use.   The "bit-error-rate" of modern drives is good... but not perfect.  They layer CRC checks on the sectors, but that does not prevent an error, it just detects it.   Look at any SMART report... the "raw" read error rate is not zero.  There's a LOT of hardware error correction going on, constantly...  having the correct bit values on the drive's end of the cable does nothing to help if the bits are corrupted by noise when they get to the other end.

 

The big question is what happens when a byte is not read accurately, regardless of the cause

(disk vs. cabling vs. power-supply vs. MB chipset vs. disk-controller).   

 

On MS-Windows we get Blue-screen-of-death... or Cannot open document, or something in between.  On unRAID, we get a parity check error.

 

I know one thing for certain, we can at least check parity and verify we can read disk contents and do some basic tests...   An MD5 verification sounds like a great addition...  (It will take a while to run, but who cares...)  Probably something out there already does it... anybody have one they like?

 

Joe L.

 

I think we're talking about two different things.  Maybe an example would help ...

 

Say you are writing a large video file to disk1 of the array.  A few minutes later you try writing some mp3s to disk3.  But disk3 fails and crashes unRAID (the sudden loss of power to a drive has been known to crash unRAID so this is not far fetched).  You reboot and realize that disk3 is disabled and is being simulated.  You replace disk3 and rebuild it.  Everything seems perfect.  

 

But due to the dirty shutdown and the fact that unsynced updates were in process on disk1, files on disk3 that happen to be located in the corresponding sectors to recent write activity on disk1 are going to be corrupted.  And there is no way to know which files, if any, are affected.

During your tests I would suggest not deleting the original source.

 

Ha - there are no other sources.    I don't have any storage space anywhere else on my network (we're tapped completely out, which is what prompted us to build an unRAID box.)

 

I guess I'll simply have to hope the parity errors were on the parity drive, not the data... 

Do the smart log checks, make sure you are working with drives you can trust.