BRiT

I use an OCZ Vertex 1 120GB on my main PC. I picked it up for $300 when they were brand new, back in March 2009. It's incredibly fast and continues to work well. They were really OCZ's first consumer friendly SSD that I could recommend to friends and family. If you're a WinOS user, the Vertex 1 120GB has a Windows Experience Index rating of 7.3, where I believe the top performance SSDs score 7.9 the max score reported. Both of those SSDs are an amazing value. General OCZ's SSDs of note skipping the limited or turbo editions and in general performance increase order: Agility 1, Vertex 1, Agility 2, Vertex 2 In terms of performance within the same series, generally the larger drives perform better because internally they're composed of banks of smaller drives (raid-0 like). This is typically why the 60GB is faster than the 30GB and the 120GB is faster than the 60GBs. The Agility and Vertex series are their best performing series out of all their lineups. The Onyx series is their budget product line, but I question it's value considering how cheap their Performance series is. The Solid series should be avoided at all costs, it was a Gen 1 product with stuttering issues.

Hopefully you'll never have to rebuild a failed drive on that system. If you do, you'll wish you had spent the 350 on a reasonable system.

You need to ditch the PCI Bus, it's over saturated. All devices on the PCI Bus share the same bandwidth. It's limited to 133 MB/sec for all devices combined. Your preclear is most likely dominating that limited bandwidth. If possible move your drives off the PCI Bus and onto the onboard SATA ports, if you have any available.

As for the missing libraries, if they are truely libraries and not kernel modules then they can be resolved by the community. I was just going to point over to gfjardim's addon, but I see he's already done so.

Yes. That will correct the line endings on an running unRAID system. It's what Limetech uses for their 'go' script. Have a look at /etc/rc.d/rc.local

fromdos </boot/custom/bin/s3.sh >/boot/custom/bin/s3_fixed.sh mv /boot/custom/bin/s3_fixed.sh /boot/custom/bin/s3.sh

No. 060 > 000

What other power savings settings do you have enabled in BIOS? Perhaps you have USB Resume enabled, which is almost always going to prevent the box from sleeping?

You must not have been around when we worked through the various cases of stuttering back in the 4.5 beta days. Drives on the same controller just do that. If I/O is occurring on a spunup drive, and an I/O request is issued to a spundown drive on the same host controller, then I/O will freeze on the first drive until the spundown drive gets spunup. This is because the common host controller is busy spinning up a drive and can not process I/O requests for other drives it controls. It's just the way current controllers function. Have a read: http://lime-technology.com/forum/index.php?topic=4782.0 Try to read the entire thread if you can, at least read everything in the first post.

Older EADS do not use 4K sectors (advance format, new format, etc). However, I heard mention that some newer EADS may be using 4K sectors as well.

Answer 1) No that is not the reason. Answer 2) See answer 1. Just to make things perfectly clear, after cache_dirs is invoked, it will be running in the background until the server is turned off. You only need to start cache_dirs once, typically when the array is online, or you need to tell it to wait until the array is online '-w' option. You never need to run cache_dirs again, even after adding files. It only caches file and directory listings. When your media player is scanning for new movies, the new movie file and directory entries should be read from the cached entries. When your media player reads the contents of the files however, the discs must be spun up. The cache_dirs script can do nothing to cache actual file CONTENT. Spinning up idle disks can result in hiccups. This is the intent of spin-up groups, so you have your drives spun up as needed by functionality such as 'all movies'.

The only thing that should be different is the cable types used on your controller card to the Norco backplanes. It won't be too much since you're only using 6 to 8 drives to start with, unless you order all the cables upfront. But still a bit of a bummer to have things come out slightly different than what you had planned.

Once again, in most cases the RAW Values are meaningless. You need to compare the Current Normalized Value to Threshold Value. In your case, none of the Current Values have exceeded the Threshold Value.

The raw value is only meaningful to the mfg. Your worst value is your current value, which is 67. The threshold is 21. You are above that, so no need to worry. Only the mfg knows how quickly this value will decrease or what the value is brand new. Now this following bit, I'm not completely certain about, but it's what I think, so someone correct me if I'm wrong. Even if you exceed the threshold value (drop below 021), odds are it'll still work as the status type is 'pre-fail'. The pre-fail type seems to be an indication that something may go wrong, but not a sign of a genuine failure.

Its also generated in the preclear report. I updated the previous post to display the values you posted from your syslog.

It's in the smart report. First column is current value, next is the worst recorded value, and next is the failure threshold value. The very last column on the right is the raw value that only the mfg knows what it means in most cases. In your situation, in the Offline_Uncorrectable stat, your current value is 100, the worst recorded was 253, and the failure threshold is 000. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0027 167 167 021 Pre-fail Always - 6633 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 10 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 100 253 000 Old_age Always - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 66 10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 8 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 7 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 127 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 100 253 000 Old_age Offline - 0

ps -ef | grep preclear

Are you certain the disk is even /dev/hda ?

The first time the script runs, the drive has to be spun up to get the directory listings. If you mean the drive spuns up after the script is running and the drive has idled out to sping down, how are you browsing the files? If you're using Windows Explorer, make sure it's not trying to read the content of the files to display thumbnails.

One issue is, if you Format the drives outside of unRAID, when you add them to the array you will have to recalculate parity over the entire array. You could possibly downgrade to unRAID 4.5.1 to add the drives and format them. Once added, you could then upgrade back to unRAID 4.5.3.

I'm not sure if a nested/absolute path is needed or if the double-quotes are messing it up in your GO script. The double-quotes may need to be escaped or removed completely.

Alright, here's your full post: I do not see "for me" in there at all. You also stated it gets even worse if you have WD Greens. Was that not a reference to the WEADS / WEARS ?

Yes, really. Reread the following statement which seems aimed at all GPs.

Well your statement seemed to be aimed at all WD GP drives. Mine are the older EADS.

terrastrife, I going to have to refute your claims. My array has a final parity check speed of 75 MB/s and I am using 3 WD Green 2TB drives. They start off at over 100 MB/sec. That puts the difference in speed from 95 MB/s to 75 MB/s a drop of about 22% {the math: (1 - (75/95)) * 100 }, which is nowhere close to your claimed 50% performance loss. Perhaps your drop in performance is from the adding of another drive, regardless of it's type.