Joe L.

Believe it or not, I do appreciate the feedback. (I learned long ago I simply do not know it all) We have different approaches to the same desired result. The preclear script was originally written to do just that, pre-clear a drive and write the appropriate "preclear-signature" to the disk. Over time, the additional feature of performing a pre-read, and then a post-read were added to force the disk to identify sectors it could not read reliably. At that point, it became a tool to burn in a new disk and get it past the infant mortality stage before using it for precious data. Although your 5 minute "seek" test is as valid a test as any, it barely subjects the disk to the same temperature changes that occur over a far longer preclear cycle. Those same temperature changes will definitely exist when reconstructing a failed drive, or even when checking/calculating parity. For that reason, I do not feel a 5 minute is the definitive test of a drive's ability to seek when it gets warmer. Granted, rapid seeking might uncover some mechanical resonance related issue my less aggressive, but random seeking might not..., but they both test for much the same issue. Unfortunately, your custom seektest is not stock on unRAID (I had to use only what was distributed in the base unRAID distribution) Remember, I specifically wanted to the disk to identify unreadable sectors prior to the subsequent "writing" of zeros so SMART firmware could trigger a re-allocation of the sectors marked as un-readable. I still had to perform the read of the entire disk... so why not perform a bit of seek exercise too and the tiny additional time it added (your estimate .5%) did not change the preclear time very much, so it was far better than just a linear "read" of track after track. If the disk has difficulty in seeking, but recovers internally without posting an error externally, it does show in the speed of the preclear process and in the SMART report. There have been plenty of disks RMA'd because their preclear speed was a fraction of other equivalent drives. for a drive surface test, badblocks in full read/write 4 pass mode is as good as any and included with recent versions of unRAID. However, even it cannot be trusted... See here: http://lime-technology.com/forum/index.php?topic=23792.0 Joe L.

Joe, I understand what you intend the above dislocation enhancement to accomplish, but I'd suggest that you (take a step back and really) think about it. I had given it a lot of thought. The intent is to put the disk through a bit of a torture test. I purposely wanted the disk to do something other than a linear read. I knew it would take a bit more time. If the disk heads cannot be positioned to tracks, then I do not want the disk in my server. All the read results of the random and first/last sectors are thrown away, the entire idea is to force the disk to seek in a random way all over the disk. It definitely slows the process down a little. When reading (in the post-read phase) the same process is performed but the linear blocks contents analyzed. Don't worry, if a disk cannot seek, it will try again... I've rarely seen anyone with "seek" issues, and there probably have been thousands pre-cleared, but plenty with un-readable sectors where the checksum at the end of the sector does not match the contents of the sector. It was not my intent to make the disk make more audible noise... but it was my intent to exercise the disk and not just give it the easy task of a linear read. In fact, if you read the comments in the code it says: # Torture the disk, by reading random blocks from all over # calculate three (random) block numbers to be read somewhere # between block 1 and the max blocks on the drive, the goal is to shake the drive to an early # death if it has any mechanical issues, before it is holding data in our unRAID array. # read three random blocks from the disk and two fixed blocks. We use a random # blocks to try to ensure they are not in the cache memory # and to get the disk head moving randomly on the disk. # # the two fixed blocks are "direct" read, bypassing the buffer cache. They are the first # and last cylinder on the disk. # read a random block. # read the first block here, bypassing the buffer cache by use of iflag=direct # read a random block. # read the last block here, bypassing the buffer cache by use of iflag=direct # read a random block. # Now, also read the blocks linearly, from start to end, 200 cylinders at a time.

In addition to linearly reading blocks of 200 "cylinders" from the first sector to the last, both the pre-read and the post-read ALSO intersperse reading the very first sector, the very last sector, and three other random sectors in between for every 200 sectors read. basically, it works like this: Looping start # read a random block. # read the first block, bypassing the buffer cache by use of iflag=direct # read a random block. # read the last block, bypassing the buffer cache by use of iflag=direct # read a random block. # Then, read the next set of blocks linearly, from start to end, 200 "cylinders" at a time. Looping end It is easy for the pre-read or post-read to attempt to read a high numbered sector. Joe L.

All it would take is any process running the sync command to flush all the disk buffers. I do not think that is it though, as sync alone would not clear the cache. Instead, I suspect a massive use of RAM is requiring it to be freed for reuse for another process. What version of unRAID are you running? What processes do you have running at 4:30 AM in cron that might use a LOT of memory? Joe L.

Ah, thanks. I will issue a feature request. The button labeled "Move now" could offer "Pause" or "Stop now" if the mover is running. Regards Harald I like the idea, but suggest "Stop Mover" to reduce confusion as to the button's purpose when it is displayed.

The command used by "mover" to actually move the files is the "rsync" command. Typing killall rsync should kill it.

Completely normal, as the post read is also verifyin all the bytes read are zero. The pre-read just sends the output to /dev/null and usually runs at 2 or 3 times the speed of the post read.

Drives over 2.2TB do not use an MBR based partition. The -A and -a options of preclear_disk.sh are completely ignored. There is a partition created to fool older utilities into thinking the disk is entirely allocated. That "protective" partition is always starting on sector 1 and is for the full 2.2TB the older MBR style partition could define. It is not used at all by the reiserfs file system. It uses a GPT partition, and that always is 4k aligned. Joe L.

looks like the biggest user of memory is java running subsonic.

what does free -l and ulimit -a and ps -eo size,pid,user,command | sort -n show while the errors are occurring? The last "ps" command will show where your memory is being used by processes. Joe L.

You are trying to interpret the RAW value for that attribute. You cannot. It is not a simple "count" as it is for some others. Only the manufacturer knows how to interpret the RAW value, and they are not telling. The NORMALIZED VALUE is 100, and has not changed, and is nowhere near the affiliated failure threshold. Given only the newest of the smart reports, that looks like a great drive. Oh yes, ALL drives perform hardware error correction. Yours is no exception. Some report it, some only report when it fails. Joe L.

Probably not. Which specific attributes have you concerned? Joe L.

But doesn't it wipe the MBR on step 4 & 5? Why is it still corrupt(?)? It is still corrupt because the bytes tested as "out4" and "out5" were not supposed to contain zeros. (At that point in time out4 should have been 00170, and out5 should have been 00085.) Those two bytes should have been written in step 6. If, as you say, the disk stopped responding at all, and does not even respond to an fdisk -l command, that would explain it. (The disk could have died, or a cable to it may have come loose, or it is loose in a drive tray, or the power to it is insufficient and it locked up refusing to respond until power cycled, or the disk controller locked up, or a disk it is paired with locked up the pair of drives on the controller.) Joe L.

It is not my opinion.. It is the disk's manufacturer. That attribute is FAILING_NOW. I would not trust that disk with my data. Joe L.

I'd say yes, absolutely.

Looks fine other than this 194 Temperature_Celsius 0x0002 059 052 000 Old_age Always - 41 (Min/Max 16/48) It appears as if the disk has gotten as high as 48C degrees. That is a but higher than I like to see. (I prefer to stay under 40C) Make sure the disk has enough cooling. The preclear shows it got up to 42C in it. so it is not just in its old life where more cooling is needed. You are welcome.

I never use the -u option personally, since user-shares are already (and only in) memory. They do not exist physically on a disk. Their actual disk blocks are on the physical disks. User-shares are basically pointers to the actual disk shares. The -u option was added so you can experiment. It might help, it might not, but in the end it is a request for a specific block from the physical disk you are trying to avoid if it is already been cached. Let us know how it works for you. As I said, I never use it. Joe L.

I'd say use it in a "Windows" computer, where an occasional crash or data corruption would never be noticed. Unless it is power supply related, there is little else you can do. Joe L.

Looks like a perfectly fine drive to me. Only issue, probably in its prior life, are the power off retracts 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 284 These were where power was turned off when the disk heads were still loaded. (apparently you just hit the power switch) however, the normalized value of 200 has not budged, and nowhere near the failure threshold of 0, so no need to worry. Would this value increase if I had something along the lines of a BSOD? There was a phase where I literally had BSODs every minute, and, I wouldn't be surprised if I racked up at-least 200 in the time it took me to fix it (Which was just saying "Fuck it" and reinstalling windows). Yup, that would do it. Joe L.

Version 1.14 of the preclear script does not exist here, and I wrote the preclear script. I only go up to 1.13. Sorry. you'll have to go to its author for analysis. Joe L.

Looks like a perfectly fine drive to me. Only issue, probably in its prior life, are the power off retracts 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 284 These were where power was turned off when the disk heads were still loaded. (apparently you just hit the power switch) however, the normalized value of 200 has not budged, and nowhere near the failure threshold of 0, so no need to worry.

Or, it could be somebody who has tie-wrapped all the SATA cables together, or worse, tie-wrapped them to power cables, making it neat looking, and inadvertently maximizing the noise pickup potential from one to another. (In other words, making the likelihood of induced noise CRC/corrupted packets issues much higher) Memo to builders... do not bundle unshielded SATA cables.. It is a recipe for CRC errors. Joe L.

Wow... really buggy firmware. It should never do that... I'd stay clear of that make/model/firmware; Device Model: WDC WD30EZRS-11J99B1 Firmware Version: 80.00A80 Joe L.

look in the system log. If no errors, it is just a very slow drive. (older drives were much slower) Joe L.

The preclear script has nothing that is limited to 65535... It simply reports what it gets from the smartctl reports it invokes while it is processing. I'd suspect the drive, not the script. If anything else might be involved it is your system RAM, or power supply. Joe L.