Joe L.

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.

Hey Joe, not sure if you missed my post, but given the weird results of this preclear, I could use your input Thanks! Sorry, I did miss it. This line is weird... 65535 sectors were pending re-allocation after zero of disk in cycle 1 of 1. I would not expect for sectors to be pending re-allocation after being written. (and it is the highest count I've ever seen) Makes me want to RMA the disk for buggy firmware. (did you perhaps run two pre-clears on it at the same time, with one writing, while another was reading?) In any case, there were still 47 sectors that it could not re-allocate, and on that I'd RMA the drive. You should, if you decide to keep the drive put it through at least one more preclear cycle, and if cannot come through with all the sectors re-allocated, and no new ones detected as unreadable, RMA it.

Interesting in that the end-to-end error says FAILING_NOW, but the overall smart status is PASSED. I would RMA the drive on just that. Buggy firmware. Yu can ignore any warnings from the preclear script about fdisk and gpt partitions on drives over 2.2TB. The GPT partitions are expected, and fdisk is only being used to read the MBR, not partition the disk, so it is safe. Joe L.

yes, but it will be slower since the USB rate is slower than an SATA cable directly connected.

Ignore the mail subject. Apparently it is not looking at the actual results. If the preclear said " Disk /dev/sdi has NOT been successfully precleared == Postread detected un-expected non-zero bytes on disk==" then it is NOT cleared. I'd run another pass, and capture the actual screen output, not the mail although it really does not matter where the errors were, if it was unable the read back all zeros, the disk is really messed up. I'd not trust it in my array. On the other hand, it could just be that your power supply is marginal, or the memory in your server is marginal, or not configured properly for voltage, clock speed, or timing. You are on the right track as far as troubleshooting the issue. Eliminate the easier items first.. (memory test) Joe L.

I don't think it is modified, as the md5sum is identical. I just wanted to make sure it was not possibly evaluating quotes as it was being extracted and changing the resulting logic. (and the md5sum shows it is not) As far as needing both the quotes and the backslash, well. there is a lot of logic in the script attempting to help you invoke the script correctly. It appears the logic validating the directory names is expecting to not see spaces in share names.

unRAID 5.X will look in "event-named" directories under /usr/local/emhttp/plugins/ for an executable script in a "plugin-name/event" directory and invoke it as it stops services prior to un-mounting the disks on array stop /usr/local/emhttp/plugins/sanzbd/event/stopping_svcs You can put something like this in your "config/go" script to move a copy of your script to that location each time you reboot. mkdir -p /usr/local/emhttp/plugins/sanzbd/event/ cp /boot/sabnzbd_shutdown /usr/local/emhttp/plugins/sanzbd/event/stopping_svcs chmod +x /usr/local/emhttp/plugins/sanzbd/event/stopping_svcs The actual plugin name (shown in blue above) does not matter other than do not use directory names with spaces. You do not need to have a plugin with that name, but it is where the event system looks. You can put event related files there as needed. They are invoked in lexical order.. As an example, if you had /usr/local/emhttp/plugins/sanzbd/event/stopping_svcs /usr/local/emhttp/plugins/01_joe/event/stopping_svcs /usr/local/emhttp/plugins/02_joe/event/stopping_svcs 01_joe would invoke first, 02_joe second, and sanzbd third. The actual /boot/sabnzbd_shutdown file would then have as its contents: wget -O - localhost:8081/shutdown?session=blah One warning. If any "event" script fails to end, or waits for user input, the entire unRAID shutdown process will stop and wait forever to continue. To see other potential events look in /usr/local/sbin/emhttp_event Edit: fixed name of event from stopping_services to stopping_svcs in examples.

Assuming I did not make a coding error, and assuming your directory name does not have a backslash in it, you should be able to use -i "TV Shows" How did you install cache_dirs??? Did you use the recently posted plugin? Or download it from the first post in this thread? What do you get when you check the md5sum: cd /usr/local/sbin/cache_dirs md5sum cache_dirs 25ce0b04e39d07bb85921d3f7e05a5e0 cache_dirs

Your version of the preclear script is several versions old. You should always use the newest version As if now it is 1.13. Those are media errors (un-readable sector errors) Feb 25 06:25:29 10 preclear_disk-diff[30056]: 0 sectors were pending re-allocation after zero of disk in cycle 1 of 1. (Misc) Feb 25 06:25:29 10 preclear_disk-diff[30056]: 1 sector is pending re-allocation at the end of the preclear, (Misc) Feb 25 06:25:29 10 preclear_disk-diff[30056]: a change of 1 in the number of sectors pending re-allocation. (Misc) Since it occurred in the post-read, it means you were unable to read one of the sectors written. That is not a really good sign. It indicates either a bad platter sector, or a marginal electronics, or a marginal power supply voltage causing poor supply regulation. I'd try another preclear. Joe L.

This is not good: Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 2 twice (so far) the disk was not able to spin up to speed. Typically, it indicates significant mechanical wear. There is also a lot of hardware error correction taking place. Notice now the normalized value (46) is getting closer to the failure threshold (0) and the "worst" value (14) is very close. 195 Hardware_ECC_Recovered 0x001a 046 014 000 Old_age Always - 146458279 If the spin-retry-count gets higher I'll start taking it as a serious number, but, I've been monitoring these drives for the last 3 months (On my desktop) and it hasn't increased recently, so, for all I know it may have been right as I was placing it in it had a dodgy PSU connection/etc. When I first got this drive I didn't do any real tests on it at-all until ~ 3 months ago. As for the Hardware_ECC, can you explain what that does? Wikipedia just says:- (Vendor specific raw value.) The raw value has different structure for different vendors and is often not meaningful as a decimal number. Only reason why I'm not so eager to take it out of my array is because I obviously no longer have any warrant on it (Had it for 3 years+) so, it's either in my array or being used for nothing. All drives perform hardware error correction. (it is as if they have their own internal way of correcting data, typically by re-reading and comparing internal checksums.) Just keep an eye on the drive. If the normalized numbers start getting closer to their failure threshold, consider moving data off it that might be accessed frequently. I realize it is an older drive, Since it is working, odds are it will work a lot longer. I have two disks in my first unRAID server that are a quite a bit older (over 7 years). I just keep an eye on them too, and so far, they are working perfectly. 9 Power_On_Hours 0x0012 092 092 000 Old_age Always - 62767 and 9 Power_On_Hours 0x0012 092 092 000 Old_age Always - 62488 Interestingly, neither have ever had a sector pending reallocation or re-allocated. (They are IDE and 500Gig. They were the biggest available at the time the server was originally built, and over $300 each... ouch. Times have sure changed.) Joe L.

This is not good: Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 2 twice (so far) the disk was not able to spin up to speed. Typically, it indicates significant mechanical wear. There is also a lot of hardware error correction taking place. Notice now the normalized value (46) is getting closer to the failure threshold (0) and the "worst" value (14) is very close. 195 Hardware_ECC_Recovered 0x001a 046 014 000 Old_age Always - 146458279

It indicated the disk has failed.!! The data sent to it did not match that written to the disk.. (probably bad internal memory or electronics on the disk) It is FAILING_NOW, therefore, you should NOT use that disk. RMA it. The "-a or -A" are meaningless on disks larger than 2.2TB and ignored, even if you supply them as command arguments.

If you need to use it, go ahead, but keep an eye on it. Joe L.

Go back to page 73 of this thread for more discussion of these parameters. I was trying to do 3TB. Increased -b parameter is what you need. Did that but did not find anything concerning a -b parameter... Since there does appear to be a relation with these parameters (I conclude this from your reply) I will take my chances and do the preclear without the extra parameters, if only to see if that makes the difference.. Sorry, wrong thread. Try this instead. When I tried it on 3TB with the defaults (no parameters) I ran out of memory. The originally suggested -b 200 parameter was too conservative and caused it to be very slow. -b 256000 was suggested and I stopped mine during post-read and restarted it like this. I have no experience with 3TB drives, nor with your disk controllers (whatever they might be, odds are they are not the same as my older motherboard's) Smaller blocks sizes will slow things down some, as more calls to read the disk must occur. If you are getting 50MB/s, then it will take 20 seconds per GB to read the disk. You have 4000 GB to read ( 4000 * 20 = 80,000 seconds = 22.22 hours ) At 26 hours, I'd say something is slowing you down... (buss bandwidth, or disk controller bandwidth) or there are errors showing in your syslog and the disk controller keeps re-setting the disk in an attempt to keep going. Most people get around 100MB/s on the outer cylinders of a disk and 50 to 60 MB/s on the inner cylinders. Joe L.

That is exactly what will happen. It only looks for the shut down in between each individual "find" command. Joe L.

I would guess you are maxing out your BR10i.

That is what I'd do.

yes, easiest is to add /boot/cache_dirs -w to the end of the /boot/config/go script. You can add any other parameters you use when starting it, but make sure you use the -w option. Also, of the command was downloaded to a directory other than /boot, change the path. Joe L.

Thanks Joe - this array has never been started, and has nothing on it, data-wise. The two WD green drives are still going, on pass 2 of 3. The Samsungs finished, with what appears to be some red flags. Also - it looks like the slow down is gone again. it seems that the pre-read is the step that this happens at when there's another disk being written to..i thought the BR10i can handle that type of bandwidth, but perhaps it maxes at about 150MB/s ? Can I trouble you to look at these two logs and let me know what I should be freaked out about? Nothing too bad, other than the second drive looks like it has been bounced a bit at some point in its past: G-Sense_Error_Rate 0x0022 100 100 000 Old_age Always - 3

We'll see what the disk looks like after the preclear. It shows 0 sectors re-allocated. (That is good, as it indicates the disk has been able to write successfully to the original sector.) It shows 6 sectors pending re-allocation. (This is bad, as it indicates they were identified in the most recent pass of the badblocks program...) It shows 150 reallocation events, which again indicates a constant trickle of sectors that are unreadable, but can be written in place. (the original "writes" to those blocks were marginal) Now, this can all be explained by either a defective disk drive, OR a drive that is sensitive to power supply noise or low voltages. (as when supplied on either a marginal supply, or connected through a number of high-resistance connectors/splitters, or sharing a power supply rail with a lot of other drives) In other words, if you can, try a different power connection. Did I ask you yet? What specific make/model power supply are you using? And what mix of disks are you powering? Joe L.

i thought that error was related to not having the array started. If i start the shutdown from the webui, will it cancel the pre-clears? or should i wait for them to finish? Unless you've never started the array, the error is unexpected. The file is created the first time you start the array.

Thanks again Joe! i really appreciate all your help, and the fact that you are usually so very quick to respond to help requests, it means a lot! Since it will take longer to order a new drive than to run any tests, I'm going to run this one now... badblocks -c 1024 -b 65536 -o /boot/badblocks_out.txt -svw /dev/sdk then I'll run this when it finishes (unless the drive explodes because of the first one ) preclear_disk.sh -W -A /dev/sdk 26 hours later, it's done. It says "Pass completed. 9 bad blocks found" Good, you originally had 9 blocks marked for re-allocation in your prior SMART report. Now, get a new SMART report and see what the current statistics show. That is what will be shown on the SMART report/ It does have linefeeds, but not carriage returns. MS-Dos uses both. You can read the file easily if you use an editor that recognizes UNIX/Linux files. (many seem to like notepad2) The SMART firmware on the disk should have already done just that. Get a new smart report. It will take just a few seconds and let you know what has happened on the disk. With any luck you'll see 9 sectors re-allocated, and none pending re-allocation. smartctl -a /dev/sdk Joe L.