Joe L.

Actually, the preclear script logs its reports on the flash drive in /boot/preclear_reports You might look there. If the report is not there, then it finished the clearing step, but not the post-read phase to see if it was successfully zeroed. Joe L.

Ha! I think you need glasses if that's all the change you see But I totally get the need for a better description than the change-log. I don't have the time right now to go into details and I don't remember everything I did but this is what I wrote earlier: I have added adaptive depth level, to prevent cache_dirs from thrashing disks when they are otherwise occupied and cache is evicted. I found the cache was often evicted with the number of files I had when system become occupied with other things. I added the ability to adjust depth automatically based on whether scans are judged to cause disk access or not. It judges that a disk has been accessed during scan if scan takes a long time or if any recent disk access was made (and no recent disk access was made before scanning). The purpose being to avoid the situations where cache_dirs will continuously search through my files keeping disks busy all the time. Before it was also rather difficult to tell if cache_dirs was 'trashing' my disks, now its quite clear from the log if logging is enabled (though the log is rather large at the moment). If disks are kept spinning for some consecutive scans, the depth is decreased, and future rescan is scheduled at higher depth. If the file '/var/log/cache_dirs_lost_cache.log' exists then it will write a log that is easily imported into spreadsheet (excel) so its easier to check whether it trashes disks with current settings. I also added the kill I mentioned and some other quite minor bug-fixes. If you need more let me know, and I might supply more detail over christmas. If you think it looks good and useful I might do a clean up run on the script. I havn't felt like spending more time on the script if nobody but me used it. Best Alex no, not moved on... Just have precious free time to be as heavily involved as I was a few years ago. (when I was not working.) My servers are both built with out-dated hardware. I cannot contribute in the same way I did in the past. (One is an original server sold by Limetech, with IDE based drives, the second newer, but incapable to handle virtualization) I do follow the threads... and respond occasionally... Joe L.

I would try running the short smart test before doing anything that would power cycle the disk. type smartctl -t short /dev/sdi then wait for the time it indicates and get a new smart report smartctl -A /dev/sdi followed by the same steps for the long test, waiting several hours or more as indicated when invoked before getting a subsequent smartctl -A report. (Don't forget to disable any spin-down timers, as spinning down the disk will terminate the long test.) smartctl -t long /dev/sdi waiting hours as needed, then smartctl -A /dev/sdi It might have currently stopped responding to read requests, but might start again if power cycled. The actual issue could be with the disk controller OR the disk itself. (That is not a good behavior, as if you cease being able to read a disk it is a very bad thing in any network-storage-device)

Actually, it said "0 bytes copied" so it could not read the disk when it was trying to. Might be fine in operation, but I expect you might want to keep an eye on it. Can you get a smart report on the drive right now? (does it respond at all to read requests?) What do you see when you run this command that attempts to read the disk's first 195 sectors: (it will print, at most, 30 lines of text) dd if=/dev/sdi count=195 | od -c -A d | sed 30q

based on the smart report, it is highly likely to be bad cabling to the drive, or cabling picking up noise from adjacent cables. (if you neatly tie-wrapped all the drive cables, you've caused the problem. Do NOT run the cables all parallel to each other or to power cables.) It might also possibly indicate a power supply at its limits, with the power supplied to the drive being noisy causing the checksum errors in communicating with the drive that are showing in the SMART report:

Then it indicates your disk is dropping off-line in some way and can no longer be accessed. (either a bad disk, or a power supply that cannot supply proper power to the disk, or a disk controller that is stopping to respond, or a loose cable or connector, or loose drive tray, or back-plane. ) Sorry to say, difficiult to isolate which it might be) Thanks Joe. I think that I am just going to RMA the drive even thought it passes all of the Seagate SeaTools tests. I am using a Norco 4224 case and I have tried preclearing the drive in multiple slots to eliminate the possibility of a bad cable, or PCI-E card with no luck. I was able to preclear an old 2 TB drive just fine so I am suspecting the drive. Better to RMA the drive now, then to have it stop responding when attempting to load it with your data (or fail when using it to recover another failed disk). Joe L.

Then it indicates your disk is dropping off-line in some way and can no longer be accessed. (either a bad disk, or a power supply that cannot supply proper power to the disk, or a disk controller that is stopping to respond, or a loose cable or connector, or loose drive tray, or back-plane. ) Sorry to say, difficiult to isolate which it might be)

exactly. Thee signature is partly based on the drive size. When seen as its full size on your main system, it would have the wrong preclear-signature, and the wrong partition-type.

PRetty sure it says the same thing regardless if it is pre-cleared, or not.... but skips the lengthy clearing step it would normally perform if once it starts on the process of adding the drive to the array. I did not see in your syslog any evidence of you actually adding the disk to the array. Did you press the button to actually add the disk, or just stop because it says it will clear the disk? Joe L. I stopped it because it just clears it again. I tried removing the Dynamix plugins and preclearing and then adding the drive, but have the same problem of it wanting to clear the drive again. No matter what I seem to do, it keeps saying wanting to clear the drive and never lets me get to the format drive. Are you sure you are using the latest version of preclear? Are you using unRAID v6? There was an issue with the preclear signature on v6 which has been fixed in the latest version of preclear I am 100% sure I am using the latest version. 1.15. If I do a preclear_disk.sh -v it outputs 1.15. I am on unRaid 5.0.6 SO I upgraded to unRaid 6 Beta 12 and tried preclear and then tried adding and getting the same exact problem. I am almost at capacity, what can I do? It is pretty obvious... Does the disk still test as "precleared" when you invoke: preclear_disk.sh -t /dev/sdX (where X = your drive letter) If that test says it is pre-cleared, it is... and you can add the disk to your array and let unRAID do as it wants, regardless of what the screen seems to say. If I'm right, it will skip the step of writing zeros to the entire drive and add it to your array. If I'm wrong, it will write zeros to the drive and then add it to your array. Either way, it ends up added to your array. Joe L.

PRetty sure it says the same thing regardless if it is pre-cleared, or not.... but skips the lengthy clearing step it would normally perform if once it starts on the process of adding the drive to the array. I did not see in your syslog any evidence of you actually adding the disk to the array. Did you press the button to actually add the disk, or just stop because it says it will clear the disk? Joe L.

It looks great. Joe L.

PM me a link. Your changes sound interesting and useful. I'll review and incorporate the improvements. Joe L.

Well... maybe... but maybe not. The preclear report said: == Disk /dev/sdi has NOT been successfully precleared == Postread detected un-expected non-zero bytes on disk== Basically, it wrote all zeros to the disk, but when it went to read them back to verify the write was successful, there were some bytes that were not zero. That is a very bad thing, since you cannot rely on the disk to store your data accurately. Nor can you rebuild any other failed disk accurately if one were to fail. I would try a parity check at this point. It might have an error or two as it expected all zeros... Joe L.

My first gut instinct response is that it is a memory related problem. I know you said you tested it, but not with the disks also drawing power. What make/model power supply are you using? Many have reported issues with over 6 or 7 drives on a multi-rail power supply... perhaps it is the interaction of both drawing from the power supply. If a single-rail power supply is being used, I would try a different version of unRAID (with a different version of "bash" as it seems to be the one with the segfault) from your syslog: segfault at 2 ip 0807e3a0 sp bfd912a0 error 4 in bash[8048000+be000]

Good that your memory tested OK. It is always the first suspect. What version of unRAID? I suppose it is possible for newer versions to have an issue with malloc/free in (apparently) either the shell or "dd". Nobody else has reported the same issues. In any case, you can use the -r -b and -w options to the preclear script to alter the memory "dd" uses when pe-clearing.