BRiT

For future reference, always upgrade to the latest version of preclear_disk.sh available at the time BEFORE you start your preclear cycle(s). The new results format enable you to self diagnose with ease. Your friend's drive is fine.

If you like the Lian Li cube case, you might also like some of the Mountain Mods cube-style cases too. Though they don't include as many 5.25" bays, so not as easily usable for Hot-Swap Trays. Personally, I wasn't as impressed with the quality of the paint job on my MountainMod U2-UFO Opti-1203 considering the outlandish pricing on it, but it served it's purpose for my water-cooling system. I picked it up close to 5 years ago so maybe they've improved since then. You should always be able to trust Lian Li quality though. I do like all the 5.25" bays on the Antec and Lian Li models, both the 1200 and the cube-case.

Once again, Preclear.sh only reports DIFFERENCES between SMART reports before and after. Your drive could be failing before and if afterwards it fails exactly the same, the Preclear.sh will not show any differences. Your drive could be perfectly fine before and if afterwards it's exactly the same, it won't show any differences. On the SMART reports, you need to compare the "VALUE" and "WORST" to the "THRESHOLD". As long as those first two VALUE and WORST are above TRESHOLD you should be fine as long as the "WHEN_FAILED" column is clear. In most cases the RAW_VALUE is only of interest to the drive manufacturer, though there are some few data items that are of interest to the users, Id #5 - Reallocated_Sector_Ct, Id #196 - Reallocated_Event_Count, Id #197 - Current_Pending_Sector, Id #198 - Offline_Uncorrectable. I do not see any "errors" on your drive reports.

I can't be certain, but you might need a complete power cycle (off then on) for the setting to take affect. That's the case for firmware updates. Maybe that setting is the same?

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.

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

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.

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.

IIRC, a flaw in your trivial solution is the partition table is written at the very beginning of the drive, as is the filesystem tables.

Interesting idea, but how would you suggest handling the following situation: 1) replacing a failed Data Drive X with a larger Data Drive Y, where size(y) > size(x). You've made this typical and likely scenario rather complex.

They do not, at least not by emHttp.