BRiT

Yes, there is a new way to sleep with the newer Linux Kernels. You need to change your scripts or addons appropriately.

Try to remove all bootable media (unRAID flash drive). For some quirky reason, sometimes you can only get into the card's bios if there's nothing for the normal bios to boot.

Yeah, that was a bit of a let-down for me, but at the time it was significantly cheaper than the available alternatives. It was part of a NewEgg Combo for even more savings. I haven't looked yet, but I bet if it exists it'll be pricey, but it would be nice to find a short (few inches) reverse breakout-gender-changer cables so it can be used with the typical SAS-to-SATA cable.

I too am using exactly the same board with an E3-1270 Xeon but only 8GB of ECC DDR3-1333 ram. For not it's running unRAID 5.0b12a on top of a Slackware 13.37 64bit distro. The IPMI is a real treat. The NICS are using the e1000e driver. I will be moving over to a base unRAID 5.0b12a (or newer) on top of ESXi 5.x. Then I will use another VM for my daemon programs (media serving, usenet, eggdrop, identd/authd, torrent, etc).

I hope so too... Though the change set that said support for > 2TB LUNS [iBM 2.72] was the latest IBM-branded BIOS I had linked to in the other thread. It predates the December BIOS LSI version I first toyed around with when cross-flashing.

LUNS != Drives. Luns is their logical units for their RAID sets. The 2.72 BIOS does not support > 2.2TB drives considering the newer BIOS from LSI do not. Unfortunately I do not have a > 2.2TB physical drive. The BIOS in the first post is the one I've been running since here - http://lime-technology.com/forum/index.php?topic=7451.msg104148#msg104148

LSI SAS2008. LSI HBAs based on this chip: LSISAS9200-8e, LSISAS9210-8i, LSISAS9211-8i, LSISAS9212-4i4e; SuperMicro HBAs: AOC-USAS2-L8i, AOC-USAS2-L8e; Intel HBAs: RS2WC080.

Things got interesting once again.

You're using a really old version of preclear, one which has an issue with some versions of 'echo'. Upgrade to the current version.

Here is all that you need to know:

One is the entire drive [/dev/sdb] and the other is the first partition of the drive [/dev/sdb1].

Yes. I now run at least 3 preclear cycles on all new drives. I've had a drive or two pass the first pass but die on the second or third. Hard drives failures tend to fall into the bath-tub curve. It's best to get past the initial part before you trust it with your data. The last drives I added to the array went through 5 cycles. Yes, that's around 150 hours of preclear on each one. Fortunately you can run preclear on different drives at the same time.

You can still use them, you merely need to control drive spin down some other way.

At this point on unRAID 5.0 I'd go the other way ... try running smartctl without any "-d" options at all and detect errors to try it with "-d ata".

You merely read the following summary:

1. Use the -c option (lowercase c) followed by the cycle count.

I know the OCZ SandForce-based drives have their own meaning to the SMART attributes. My OCZ Indilinx Vertex 1 drive barely implements SMART and the values it returns have no meaning to consumers. EDIT: Here's the SandForce SMART information: http://www.ocztechnologyforum.com/forum/showthread.php?75786-SMART-Attributes-for-Sandforce-SSD-s-%28Agility2-Vertex2-VertexLE%29

Just waiting a few seconds typically 30 seconds is more than enough will have cache_dirs rescan. It is continually rescanning your directories by using the "find" command. There is no need to stop and start cache_dirs to force rescans.

Usually the fix is they are actually reallocated. It's a little odd that they were removed from the pending reallocation list but were not actually reallocated. Perhaps they were able to be properly read during the preclear and thus removed from the pending list. I would run another preclear cycle on the drive to see how it behaves. Maybe Joe L or someone else would know better.

The new report format of the preclear_disk.sh is all you need to look at to determine if things are good or not.

Feel free to modify your own "go" script to use the /bin/beep command. For instance: beep -f 700 ; beep -f 500 ; beep -f 700 ; beep -f 500

The first version to support advanced format drives also includes the new report format as well. It was released on Jan 14, 2011 as Version .9.9. I know it at least displays the results to standard out. All you have to do is look at the display used to invoke the script. In my syslog I also have the human readable results, it's listed as "preclear_disk-diff". How did you invoke the script?

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.

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.