aim60

This Server has been totally stable for 3 years. An ST32000542AS red balled, and I’m pre-clearing a replacement. In the mean time, I’ve been testing the drive on another pc. Seatools for DOS comes up clean. The UnRaid MyMain Smart web page looks good. Smartctl doesn’t show anything critical. I’m wondering if the problem is the drive or some other component. The end of the Syslog shows the drive failure. 4.7 final, C2SEE w/drive on the internal controller, Celeron 1400, 4GB, Corsair VX450, (1) SIL3132 PCIx SATA controller, Intel PCI NIC, 7 drives in total. Syslog_etc.zip

Not a good idea. Some linux kernels unlock the HPA. Set the drive to 2TB with HDAT2 and verified after a power off. Booted UnRaid RC8a, and it saw a 3TB drive. Figured if I ever wanted to upgrade from 4.7 to 5.0, I should stay away from mucking with the HPA. Anyone holding off for 5.0 Final will have to bite the bullet and buy 2TB drives if you have a drive failures. Wish I upgraded earlier.

I have a 3TB drive that went through multiple Pre-Clear passes on a test 5.0 system. I'd like to use the HPA trick to reduce the size to match the 2TB drive, then use it to replace the failed drive. Its on the on-board controller on a C2SEE, so I wouldn't expect controller problems. Anyone see potential problems? HPA procedure here: http://lime-technology.com/forum/index.php?topic=21325.msg189469#msg189469

My compromise for minimizing power cycles - l keep all drives set to manual and spin everything down at bed time. Whenever they spinup, they stay that way for the rest of the day. Does anyone have a script that changes the spindown delay depending on the time of day?

Nope.. That seems like a very interesting option. As much as I don't mind kludging stuff.. I think that is going a bit too far for me. lol.. @aim60 The cheapest on ebay is just a couple bucks less than GPS, but probably will go with your link. How long have they lasted? Battery Geek seems to be the cheapest on ebay: http://cgi.ebay.com/RBC25-UPS-Battery-Pack-SU1400RMXL3U-RBC8-RBC23-RBC24-/200468876592 $52 shipped, versus GPS is $56 shipped. Also, battery geek is 0.5 ah higher, but not sure that is that big of deal for me. Thanks, flips They lasted 3 years. The first set they sent were their own private label batteries. Their replacements, 3 years later, were another brand. These guys refurb large (as in pallet jacks and fork lifts) UPS's, so I figured they wouldn't risk their reputation selling junk. Toured a large datacenter the other day. They used [uPS's] without batteries. Utility Power -> [electric motor -> large flywheel -> generator] -> load. In case of a power outage, the flywheel keeps the UPS going long enough for diesel generators to kick in and replace utility power. Great idea for anyone that has a diesel generator at home that can kick in in 5 seconds.

I've had good service from these guys http://stores.ebay.com/Gruber-Power-Services but shipping on a Back-Ups 1000 battery was as much as the battery. Still a good bottom line price, but it hurts that 50% of my dollars went to UPS.

Interesting... I don't doubt you, but I see no way for that to occur... (In other words, I'll have to test it myself) If running with no option specified the "default" will be that you've specified in the unRAID "Settings" page. The partition start is set prior to entering the "cycle" loop. It is un-changed (as far as I know) otherwise. Before I start my test, are you sure you have 4k-aligned as the "default" set on your server? (please double-check, so I can duplicate your situation here) Also, once the second cycle is complete, let me know what the output says. You might even run preclear_disk.sh -t /dev/sdc and let it tell you how the disk is partitioned. I'll be curious what it says. Joe L. The default is 4k-Aligned. I'll run -t when the cycle is done. Also, the server isn't needed at the moment. I'll repeat the 2-cycle test to verify. Any files that would be of use? Should have done more verification before posting. What I encountered was the bug that you fixed in version 1.9 (preclear defaults to 63 sector alignment on unRaid 5 with no -a or -A).

Interesting... I don't doubt you, but I see no way for that to occur... (In other words, I'll have to test it myself) If running with no option specified the "default" will be that you've specified in the unRAID "Settings" page. The partition start is set prior to entering the "cycle" loop. It is un-changed (as far as I know) otherwise. Before I start my test, are you sure you have 4k-aligned as the "default" set on your server? (please double-check, so I can duplicate your situation here) Also, once the second cycle is complete, let me know what the output says. You might even run preclear_disk.sh -t /dev/sdc and let it tell you how the disk is partitioned. I'll be curious what it says. Joe L. The default is 4k-Aligned. I'll run -t when the cycle is done. Also, the server isn't needed at the moment. I'll repeat the 2-cycle test to verify. Any files that would be of use?

Joe, running preclear_disk version 1.7 on unRaid 5.0 Beta6a. The default partition format is 4K aligned. Called with "preclear_disk -c 2 /dev/sdc" (no -a or -A). Cycle 1 ran with partition start 64. Cycle 2 is running with partition start 63. If its significant, there are no disks assigned to the array.

I'm currently running horizontally without backplanes. But my CM590 is filling up, and I'll need to consider 5-in-3's or a Norco. I've heard that switching a HD's orientation after months or years of bearing wear is an invitation to premature failure. Any feelings?

The first hard drive that I worked on used these platters. http://www.grandideastudio.com/portfolio/hard-drive-coffee-table The platters were mounted vertically on a horizontal spindle. A byte was written in parallel, one bit on each platter surface. There was a story that during maintenance, with the cabinet opened and the drive running, that the spindle broke loose from its mounting. Rolled across the floor and almost killed someone.

Had a wireless keyboard dongle hanging out of the back of my HTPC. Moved the PC, smacked the dongle on a wall, and almost broke it in two.

Perhaps a better terminology is the unRAID only uses the first NIC it finds. You can set up the second NIC however you like manually. For us linux n00bs, could you list the commands to setup the second nic.

Already spent a week testing the drive. Better to follow your recommendation and RMA it. Thanks

From: http://sourceforge.net/apps/trac/smartmontools/wiki/FAQ#Warning:ATAerrorcount9inconsistentwitherrorlogpointer5Whatsthemeaningofthissmartctlmessage 'Warning: ATA error count 9 inconsistent with error log pointer 5' What's the meaning of this smartctl message? The ATA error log is stored in a circular buffer, and the ATA specifications are unambiguous about how the entries should be ordered. This warning message means that the disk's firmware does not strictly obey the ATA specification regarding the ordering of the error log entries in the circular buffer. Smartmontools will correct for this oversight, so this warning message can be safely ignored by users. (On the other hand, firmware engineers: please read the ATA specs more closely then fix your code!).

I have a 4 month old 2TB EARS drive that’s been running in the array without problems (4.5 Final, jumper installed). After a parity check, it showed 19 pending sectors. After a second parity check the count increased to 49. I swapped the drive out, moved it to a test server (4.7 Final), and ran 5 Preclear passes. Ever since the end of the first pass, Smartctl has shown 0 pending sectors and 0 reallocated sectors. The syslog from the test server shows several hardware errors on the drive, probably during the first preclear pass. I’ve also run WD’s DataLifeGuard long diagnostics and Smartctl long tests. Neither has shown any errors. Should I RMA the drive or put back into the array? syslog.txt

Available 8/24 only. Use coupon code EMCYWNR47.

Be careful with model numbers when ordering. e.g. an APC Back-Ups 550 is a 550 Volt-Amp unit. You need to find the Watt rating for the unit you're interested in.

I screwed 3 1/2 to 5 1/4 adapter brackets to the hard drives, and mounted them 1 per bay in a cm590. Not as convenient as hot swap bays, but I can remove one drive at a time without disturbing the others. And being farther apart, they get good air flow without front fans. Am using 2 140mm top fans & 1 120 rear fan, and all of the drives stay reasonably cool. 5400/5900 rpm drives run a lot cooler than 7200s. I don't plan on running out of drive bays any time soon.

A very interesting action took place here, that caused a resize of your Disk 1, which resulted in the disk being inconsistent with the disk config in unRAID, caused a rewrite of the MBR, then a rebuild of the disk, which was perhaps unnecessary. Your Disk 1 had a Gigabyte HPA installed, and is connected to the first SATA port on the motherboard. No other drives have HPA's. Here are the relevant lines: There is some concern here, because we really don't know yet what actually happened, and therefore don't know yet what will happen when this rebuild reaches the last megabyte of this drive. If the size change is artificial, that is, the kernel is saying that this *should* be the true size, but the hard drive firmware has not truly removed the HPA, then there are going to be drive errors at the end of the rebuild, when the drive refuses writes to that area. If this latest kernel now includes logic to actually remove the HPA *AND* make the Gigabyte board turn off this "BIOS backup in an HPA" feature, then this is a great new feature of the kernel, and the rebuild should write zeroes into that area, clearing it. I have to wonder though if this is going to stop the Gigabyte BIOS from trying to create an HPA again on the *next* boot. It will be good to hear from other Gigabyte board owners with HPA's. What is especially interesting here, is what happens at the end of this drive, and what happens on the next boot. There is another possibility, did you perhaps find a BIOS setting that disabled this feature, and just changed it now? Perhaps the new kernel detects that and tries to recover the space. Just to be clear, there is and was nothing wrong with the drive, but the kernel has attempted to remove the HPA, which changes the size of the drive, and that makes unRAID think the drive has changed. I feel I need to caution you here, as to the action you took, especially so quickly. Any time that the Web Management indicates an action or status of a drive that is not in accord with our understanding of that drive, you really should step back and try to find out what happened first, before proceeding. When it said that the drive needed to be rebuilt, this in effect was similar to it saying that the drive needs formatting, and you would not want to proceed very quickly if you unexpectedly saw that message. A request to rebuild is effectively asking to completely overwrite a drive, in effect losing everything that was stored there (although we hope it will overwrite with what is already there). The first step to take is to check the Device assignments, to make sure that the new kernel has not changed the order of drive detection, and now a different drive is assigned there. I don't think we have had a catastrophic case like that yet, rather, device changes have simply resulted in unassigned drives, but still if the parity drive had somehow been assigned now as Disk 1, it could have resulted in the complete loss of Disk 1. I would want to make absolutely sure that the Disk 1 I will overwrite with the contents of Disk 1, is really the correct drive and serial number. After that, I would want some idea of why it is trying to overwrite this disk. It could be valid, or not, and I would very much want to know if it should not be overwritten/rebuilt. In this case, after verifying the drive assignments, all you needed to do was run the Trust My Array procedure. It would have reported a number of parity errors at the very end of the drive, but that is expected. Being a Linux n00b, don't know whether this affects the unRaid kernel: Kernel Bug - Do NOT disable HPA by default -> leads to data loss https://bugs.launchpad.net/ubuntu/+source/linux/+bug/380138

You basically experienced "resource contention" (too much going on, too little memory for it all to happen at once) One of the pre-clear processes was using some resource others needed, so they waited until it was free. You will benefit from the three parameters I added most recently that allow you to specify smaller block sizes when reading and writing and a smaller number of blocks as well. Those parameters are: -w size = write block size in bytes -r size = read block size in bytes -b count = number of blocks to read at a time They are described in more detail in this post: http://lime-technology.com/forum/index.php?topic=2817.msg39972#msg39972 Joe L. Thanks

Have been burning in (2) ST32000542AS 5900RPM 2TB drives, by running 2 copies of Preclear simultaneously. With version .9.8, each pass takes 30 hours! I manually spindown the array nightly from the standard web interface. During the 4th pass, pressing the Spin Down button caused the web interface to become completely unresponsive. Couldn't even launch the web interface from another PC. UnMenu worked fine, and I could access files files via the disk shares or user shares. Gave up for the night. In the morning, all was well. The syslog showed a 24 minute delay between pressing Spin Down and Unraid trying to spin down the drives. Dec 3 20:51:09 Tower emhttp: shcmd (54): sync Dec 3 21:15:12 Tower emhttp: shcmd (55): /usr/sbin/hdparm -y /dev/sdg >/dev/null Dec 3 21:15:12 Tower emhttp: shcmd (56): /usr/sbin/hdparm -y /dev/sdc >/dev/null Dec 3 21:15:12 Tower emhttp: shcmd (57): /usr/sbin/hdparm -y /dev/sda >/dev/null Dec 3 21:15:13 Tower emhttp: shcmd (58): /usr/sbin/hdparm -y /dev/sdb >/dev/null Dec 3 21:15:13 Tower emhttp: shcmd (59): /usr/sbin/hdparm -y /dev/hdg >/dev/null There are 3 other examples in the log, when the simultaneous Preclear's were running, where pressing Spin Down immediately spun down the drives. 4.5 Beta 11, md_num_stripes=5120, C2SEE, 4GB RAM, disks connected to the integrated ICH10.