Joe L.

You can kill it at any time it is in a "read" cycle and not affect what was already written. If you kill it in the middle of its "write" cycles the disk will not be marked as pre-cleared. You would be skipping the more important part where it identifies unreadable sectors. I personally would not. I had said I was going to post a newer version of preclear_disk.sh, I guess I better get busy and get it to where it can be tested. Joe L.

Your disk is perfectly healthy. No current "Value" (normalized) is at or below its affiliated failure threshold. In fact none are even close to their affiliated failure thresholds. There are no re-allocated sectors, nor any pending re-allocation. Joe L.

Please explain further... have you started the unRAID server after adding the drives? (You would not see anything as a share on the LAN if the array was not started) What do you see on the unRAID management console in your web-browser? Joe L.

I agree, usually is has been reported when the disk was partitioned previously. I don't really know if it will be recognized by the OS if you just pn-plug and re-plug the power cable to the drive, but I guess you can try that first. Yes. We really do not know. It might have just failed in its first few hours of its life If you invoked the command when in a "screen" session then logging of and then re-attaching to the running screen session should have left everything just fine. Without "screen" logging off would just terminate any preclear session you might have started and you would just have to start again. Joe L.

what about me? Your disk has stopped responding. This behavior seems to occur when a previously un-jumpered drive has had a jumper added after it had initially been partitioned. right now, you cannot even get the disk to respond to any command. From prior reports, the drive will not respond again until you power cycle it. (remove and re-apply power by power cycling the server) It may also be necessary to specifically write zeros to the first sector on the disk to have it not lock up again. Some have used window's utilities to perform what they call a "low level format" but in reality they are just writing zeros as the last drives that let users perform low-level-formats to them are probably 15 years old or older. To blank out the MBR you can type this command after first power cycling the drive. dd if=/dev/zero of=/dev/sdb count=8 Then, if successful you'll be able to get the drive to respond to commands Try this to see if it is responding: fdisk -l /dev/sdb If it responds, you can try the preclear script once more. Joe L.

When I wrote the script I never anticipated a disk would simply stop responding. My newer version of preclear_disk.sh should handle it better. (It won't make the disk respond, but it will exit more cleanly when the disk does not respond. Would you like to give it a try? I can zip it up and put attach it for a quick test. You are perfect for the test, since you have a disk that is not responding right now.) Joe L.

The difference is that I get out4= 00000 and out5= 00000, 0+0 records in & out, 0 bytes copied. I tried some commands and got a script error... root@Tower:/boot/config# ./preclear_disk.sh -v ./preclear_disk.sh version: .9.8 root@Tower:/boot/config# ./preclear_disk.sh -t /dev/sda Pre-Clear unRAID Disk ######################################################################## ######################################################################## ./preclear_disk.sh: line 825: [: too many arguments ============================================================================ == == Disk /dev/sda is NOT precleared == ============================================================================ I was running this pre-clear at the same time as other disks. Should I try again by itself? Is there a way to bypass *all* the tests? BTW, I did not jumper it because I am setting things up to get ready for 5.0b3 to support these WD Green drives. Yes, the drive has stopped responding. (and the script was not coded to deal with that very elegantly) Most people find they'll need to power cycle the drive to get it to respond again. Even after that, many have had to clear the first few sectors to get it to respond sanely after changing the jumper (or adding it after the drive has been used without it being installed) Basically, we've found it does not even respond to anything when locked up. Not even an fdisk -l /dev/sdb will get complete results until you power cycle. As far as skipping "tests" sorry... can't unless you don't want to clear the drive and ensure it is cleared. Joe L.

That line says that The current normalized value is 100 The worst normalized value ever was 100 The failure threshold is 0 The current value is the initial value (initialized value) from the manufacturer. It has not moved from the initial value. Since the current value is not equal to or less than the failure threshold, this SMART parameter has not failed. The raw value has meaning only to the manufacturer, and they are not telling how to interpret it. Sorry to tell you this, but you were scared only because you've not yet learned how to read a smart report. There is nothing wrong with that parameter. Joe L.

We cannot tell by what you posted other than the reports say the disks were successfully pre-cleared. The output from the pre-clear was the difference, as reported by the Linux "diff" command, between the smart report taken at the beginning of the pre-clear process and the one taken at the end. What your printouts you show are the factory initial values of 253 being replace by a new starting point of 200. This is normal for almost all drives and brands (some start at 200, some parameters start at 100) Since we only see differences, we have no way to know if a parameter was failing initially and is still failing in exactly the same way. (it would not be different, but identically failing, so not show in the "diff" output) As far as we can see, all looks fine. Joe L.

Thanks Joe L. I tried the hdd on the mobo port and an mv8 card, the hard drive failed both times, power supply is single rail 650 watt so should be no issues there. I will run the seagate tool on the drive see what happens. Trouble is a 500gb hdd is hardly worth the postage cost to return it now True, but some have reported a larger drive is sent in return... who knows, it might turn into a 1TB drive.

It will likely fill the syslog and crash the server again... but if you start it and see the errors in the syslog, just stop it. It is probably just a bad drive, unless it is a bad disk controller port, or a power supply unable to keep up with the power demands.

Your drive looks great. You are welcome.

I'd suggest you perform a full parity "Check" now. There should be no parity errors. (The sectors pending re-allocation are a different matter) Joe L.

It is not a separate cache maintained by this script. It is the normal disk buffer cache keeping the most recently accessed blocks of data in memory. The cache_dirs script simply does the equivalent of you requesting a directory listing (but very frequently), forcing the access of the data blocks representing the directory entries. Since it does this frequently, they never end up as the least recently accessed blocks and do not get reused once they've been read the first time from the physical disks. This minimizes the need to spin up a physical disk, so access is fast. I am confused... I thought the purpose of this was the cache the directory listing so that when I request my movie list the drives wouldn't take time or have to spin up? Is this not the case? If it is then when I add a new movie when is the directory listing which I believe is cached at this point updated? cache_dirs constantly accesses the directory listings, in an attempt to keep them in the disk buffer cache shared with ALL disk operations. The hope is that normal playing of movies will not access disk blocks faster than the periodic scan of directories by cache_dirs causing them to be the least-recently accessed. When you add a new movie it will be in the directory cache immediately, since it is the most recently accessed disk blocks. The end effect is that drives should be able to so to sleep and still present a directory listing, since their directory blocks are in the in-memory disk buffer cache. Joe L.

Yeah, I did run it through the preclear script. It took around 28 hours, and thats the syslog that i couldn't save properly to post here. The disk is unasigned now, and im planing to keep it that way until the day that my parity drive goes tothe roof with the "current pending sectors". Every day adds 2 or 3 to the count. I'd not wait if the current pending sectors on the parity drive are increasing by a few counts a day. I'd replace it and get a RMA process started on the old one. Joe L. I could try to do that but the thing is that i live in Chile, and if I replace the drive now and another drive goes bad from now until March i will be F*****, because here in chile i don't have any chance to get that kind of drive. So I was expecting get the RMA in my next trip to the USA (march) and try to hang on with this drive until that. I see... If it is your parity drive you can actually take some preventative measures. Here is an idea, see what you think. A sector pending re-allocation is one that the disk was unable to read properly. The pending-reallocation logic is waiting for that same sector to be written again so it can re-allocate it from its spare pool of sectors. Unfortunately, the parity disk sectors are not normally written unless the equivalent sector on one of the data disks is written. What you could do is force unRAID to re-write all the parity disks sectors. For 99.99999999% of them, it will write exactly the same contents as it currently contains. For those 2 or three sectors it would give the SMART firmware the opportunity to re-allocate the sectors it could not read. The first step is to perform a normal parity "Check" This will allow all the drives to read all their sectors and if there are any un-readable, hopefully re-allocate them. Once the parity check is complete, get a set of SMART reports, one from each of your drives. Hopefully none of the data drives will have sectors pending re-allocation. Then, if there are pending-reallocation sectors only on the PARITY drive, Stop the array Un-assign the parity drive on the "devices" page. (leave the parity disk unassigned for the next two steps) Start the array with the parity disk un-assigned. Stop the array once more. Re-assign the parity drive on the "devices" page. Start the array with the parity disk re-assigned. This last step will force unRAID to think the parity drive needs to be completely re-written. It will, of course, be re-writing all the parity disks sectors, including those pending re-allocation. For 99.99999999% of them, it will write exactly the same contents as it currently contains. For those few sectors pending re-allocation it would give the SMART firmware the opportunity to re-allocate the sectors. With any luck this will allow the SMART firmware to re-allocate all the sectors pending re-allocation. You'll have the time to get to the USA in March to obtain a replacement drive. To re-group if anything goes drastically wrong (another disk concurrently fails) you can use the "trust my parity" procedure since you know that parity is good (the process above was just re-writing exactly what is already on the parity disk.) Then you would be in exactly the same situation as you are now if a data disk were to fail, using parity and the other data disks to simulate the failed disk. Joe L.

Linux will use as much memory as it can for the buffering of disks. Even when using 4Gig or RAM the first time you play a 5Gig movie all of it could get used. Remember, the least-recently-accessed gets re-used. So you can rewind a movie a few minutes really quick. Joe L.

It is not a separate cache maintained by this script. It is the normal disk buffer cache keeping the most recently accessed blocks of data in memory. The cache_dirs script simply does the equivalent of you requesting a directory listing (but very frequently), forcing the access of the data blocks representing the directory entries. Since it does this frequently, they never end up as the least recently accessed blocks and do not get reused once they've been read the first time from the physical disks. This minimizes the need to spin up a physical disk, so access is fast.

which of the "cache" are you referring to. The "cache" disk that allow quick writes to an un-protected disk that is later moved to the protected array? The cache disk is "merged" into the view of the share contents, so the file is instantly available for reading or writing, it is just not protected by parity until the file is moved into the protected array. So.. you can add a movie, and have it on a "cache" disk, and still play it as if it was in the protected array. or The disk buffer cache, which holds in memory anything sent to , or read from the disks? The disk buffer cache is will use as much memory as you have in the server. It will re-use the least recently used block of memory when asked to read or write a disk block not already in its cache of recently used disks contents. It is instantly updated as disks are accessed. The least-recently used blocks are re-used if a new disk block is accessed. Joe L.

Yeah, I did run it through the preclear script. It took around 28 hours, and thats the syslog that i couldn't save properly to post here. The disk is unasigned now, and im planing to keep it that way until the day that my parity drive goes tothe roof with the "current pending sectors". Every day adds 2 or 3 to the count. I'd not wait if the current pending sectors on the parity drive are increasing by a few counts a day. I'd replace it and get a RMA process started on the old one. Joe L.

That drive's smart report looks good. I'm a bit confused... Have you run it through the preclear script? (It's only been powered up about 64 hours)

Or should i just run the preclear again?? Why? There was nothing wrong with what you posted. The drive looked fine. Because i just checked the syslog that i have here and is empty, so I thougt that the one that I posted is empty too... So i have no idea if the drive is good or not perhaps we are talking about different drives. In any case, you can get the full SMART report on the drive by typing: smartctl -d ata -a /dev/sdX where sdX = the device name of your specific device. There is no need to run the preclear script just wait hours for it to invoke that exact same command to see the final status of the drive. Joe L.

Or should i just run the preclear again?? Why? There was nothing wrong with what you posted. The drive looked fine.

Actually, at the start of the preclear there were 226 sectors marked for possible re-allocation. After the pre-clear, there were none. No re-allocations occurred. This indicates it was able to successfully write them to their original locations. (and possible indicates an issue with the power supply or connectors you used previously with that drive. Might have had too much noise or vibration for the drive to work properly) nothing glaring otherwise, in fact ... the normalized read-error rate improved during the process. I'd say use the drive.

This "MBR preclear error" seems to stem simply from a different implementation of "echo" in my environment. My version of echo wants "\0" preceding octal numbers, and has no idea what I'm talking about when given, for instance, "\252" in the script: root@nickserver:/usr/src/linux# echo -ne "\252" \252root@nickserver:/usr/src/linux# "Step 6" # set MBR signature in last two bytes in MBR # two byte MBR signature echo -ne "\252" | dd bs=1 count=1 seek=511 of=$theDisk echo -ne "\125" | dd bs=1 count=1 seek=510 of=$theDisk The script is expecting out4 = 00170 and out5 = 00085 echo -ne "\252" | dd bs=1 count=1 seek=511 of=/dev/sdc >& /dev/null echo -ne "\125" | dd bs=1 count=1 seek=510 of=/dev/sdc >& /dev/null root@nickserver:~# dd bs=1 count=1 skip=511 if=/dev/sdc 2>/dev/null |sum|awk '{print $1}' 00092 root@nickserver:~# dd bs=1 count=1 skip=510 if=/dev/sdc 2>/dev/null |sum|awk '{print $1}' 00092 echo -ne "\0252" | dd bs=1 count=1 seek=511 of=/dev/sdc >& /dev/null echo -ne "\0125" | dd bs=1 count=1 seek=510 of=/dev/sdc >& /dev/null root@nickserver:~# dd bs=1 count=1 skip=511 if=/dev/sdc 2>/dev/null |sum|awk '{print $1}' #out4 00170 root@nickserver:~# dd bs=1 count=1 skip=510 if=/dev/sdc 2>/dev/null |sum|awk '{print $1}' #out5 00085 on the official unRAID distribution we get: root@Tower:/boot# echo -ne "\0252" | od -d 0000000 170 0000001 root@Tower:/boot# echo -ne "\252" | od -d 0000000 170 0000001 root@Tower:/boot# echo -ne "\0125" | od -d 0000000 85 0000001 root@Tower:/boot# echo -ne "\125" | od -d 0000000 85 0000001 Actually, I think you should be thanked too. The difference is subtle enough, but as you can see, the version of "bash" distributed by unRAID does not need the leading zero. I'll add it to the preclear script, as it makes it less likely to break as upgrades to unRAID's distribution occur. Thanks. You are welcome. Your contributions and experience will be helpful to others. Enjoy your new server. It is a learning experience. apparently the "\" in the two numbers was being translated to its "decimal" equivalent and it is why both of the MBR trailing bytes were set to 92. ("\" = decimal 92) PS. Arn't you glad I put some comments in the preclear-script? I hope you did not cringe too much in how I had to code some of the process. I had to use what was available, and it was a challenge to partition a disk exactly like unRAID, especially when some of the linux utilities give conflicting results. Joe L.

First.. some definitions. Parity errors are when there is not an even number bits across a series of drives at the identical bit position set to a "1" The errors you are seeing when pre-clearing drives have absolutely nothing to do with parity as they are not yet assigned to the parity protected array. The errors you are seeing are ICRC errors. (checksum errors in communication with the disks) That typically indicates problems in either the cables used, the disk controller ports used, the power supply, or the disks themselves. Since there are two different disks, they are least suspect. As far as not telling you why the pre-clear was un-successful, welll... it is... On step 10... Testing if the pre-clear was successful out4 = 00092 and out5 = 00092 were both the un-expected values. Basically, the values read back from the drive were not as expected. Yes, they probably were caused by the ICRC errors when attempting to read the data from the drive. The two errors are probably on the same disk controller even though they are on different disks. One might have caused the other. I agree that a 480 Watt Antec supply should not have a problem with 3 disks, but if it is a multi-rail supply and the one rail powering the CD drive, graphics card, 3 disks, all the fans, and motherboard, it may be close to its limit if older drives, especially if it is not working properly. 12 amps for the disks, 1 or 2 for the case fans, a few more amps for the motherboard and video card, and it will be close to the single rail limit of an older supply. If it is not regulating well, it might be causing enough noise on the 12Volt bus to the disks to cause CRC errors. From your other post I see you are using "experimental" drivers that nobody else in unRAID is using. That, to me, indicates you are not a linux newbee. (it may also be a mistake in judgment, as support other than in very general terms is impossible... and non-existent from lime-technology) Because you are experienced enough to compile your own kernel I think you'll be able to look at the pre-clear shell script and see where the specific verification steps are performed checking for specific values. Because you are using those drivers, it is impossible for me to easily tell if the drives involved are SATA or IDE. If IDE, then it could easily be the cable used for the two disks. It might be defective, or it might be an older 40 conductor cable instead of a 80 conductor cable. You might have bundled the disk cables tightly to the noisy power cables. If SATA you might have the SATA controller in IDE emulation mode. In any case, these same errors will only cause hair-loss if you do not resolve them NOW before you start using that set of hardware for an unRAID array. It has nothing directly to do with the pre-clear script, but it does show how the pre-clear process will expose them. Any drive that cannot be read back "correctly" is a problem. you'll face constant random parity errors, and pull out your hair trying to resolve the issue. The disks themselves are probably OK (even if they are not currently pre-cleared) Once you resolve the CRC errors, you can attempt the pre-clear process on them again. Joe L.