BRiT

I'm sorry to hear about your Vista grief. I wish everyone could have the kind of success I have with my Windows and Linux systems. I've had success with my Windows 7 development environments. The only need to reboot is for the rare installing of new devices that require additional device drivers or system services which is the same case for Linux. Sometimes I don't need to reboot in Windows 7 with some of the device driver upgrades, like for the NICs and Graphic Cards. Anyways, back on topic... Any thoughts to having preclear_disk.sh do a quick version check on startup against the unMENU repository to see if there's a newer version available, if so prompt the user if they would like to continue anyways? I'm not proposing a self-updating feature, just a quick warning to the users to upgrade. It's been nearly two weeks since your report simplifications and there's still people asking for feedback on the old formats. Now I know this won't help those running the older versions, but it would cut down on this sort of thing in the future.

To be fair, the latest versions of Windows hardly need reboot either.

Answered your question in the other thread.

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. We can not tell if your disk is good since you did not include the full SMART report. We can only tell you that 3 attributes changed normalized values that are no where near their thresholds. If the disk was failing before the preclear on some attributes they're failing the same way after the preclear. If the disk was not failing before the preclear on some attributes, they're not failing the same way after the preclear.

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.

That is absolutely not normal. What size do they report as inside of BIOS? You might need a motherboard BIOS update, or at worst case you might need a new motherboard or a dedicated SATA controller card.

Are you using the 5.0 beta 2 directly or any chance you're running on a full Slackware 13.1 or 13.2 (Current) distro? I too noticed extreme slowness when preclearing 2 drives at the same time on my Slackware Current distro. There are no system issues, no drive issues, and no controller issues. Separately each drive preclears perfectly fine at the expected speeds. Even benchmarking both drives at the same time with typical 8GB read or write files using dd yields the expected results. The two drives have been through 5 cycles of preclear, 3 separate cycles and 2 cycles simultaneous. From what I remember of the simultaneous preclears I did lately, once a drive moves on to the next phase the preclear of the other drive speeds up to normal. As best as I can tell, there seems to be something a little off with disk i/o priority interacting with preclear on later Linux kernel or Slackware distro. I didn't have this issue when I first started out my system on a Slackware 13.0 distro. I tried renicing and ionicing but neither separately or combined had any impact. I'm a bit perplexed on it as I know there's nothing at fault with the preclear script.

The new format looks great. Hopefully this will enable all users to diagnose their own results.

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?

Thanks for providing this level of detail. This is what I meant when I said banks of smaller drives.

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.