Joe L.

Doesn't really instill me with confidence I know... but you had two different disks with similar symptoms. More than likely on different cables connected to different ports on your old MB. The only common factors are Your old MB. Your old power supply MS-Windows Which one did you have the most confidence in? Joe L.

I would not trust windows to write to those drives... Apparently, it did not handle the writing very well. It could have been anything if the disk is now plugged into different connectors, with better connections, etc it might just be fine. Joe L.

Is it the same motherboard and power supply?

If that drive was in the same "windows" server, it makes me think that there was something in it preventing proper "writes" to the drives... perhaps a marginal power supply? Something common which preventing the writes from occurring properly on the drives. Again all the sectors marked as un-readable were able to be re-written in place, and not actually re-allocated at all.

When did the initial 3 un-readable sectors get detected? Was the disk previously used?

Three after the PRE-READ was expected. Reading would never re-allocate sectors. Zero re-allocations after writing indicates all the un-readable sectors were processed in place. Zero re-allocated after the POST-READ indicates all three sectors were able to be written in their original locations, and did not need to be re-allocated. The drive is working pretty decently. (You can still keep an eye on it, but it was able to handle the 3 sectors initially marked as un-readable.) Joe L.

No, not if you trust it to be 100% perfect and do not care if a file written to it cannot be read back and transferred to the protected array. From people posting here, about 1 in 5 drives has issues, do you feel lucky...? ? ?

That's it. Nothing else needed. It will tell you if it was successful.

you are fine. Apparently, 34 sectors were re-allocated before you performed the preclear, and the same 34 existed afterwords. In other words, no additional were detected. I'd go ahead and use the drive, but monitor it over the next months/years. I've got several old drives where an initial number of re-allocated sectors does not change, and they work perfectly fine. If you have time, give it another preclear cycle. I hate to ask this but I searched and could find it but what type of errors am I looking for. I have another 10 drives to do and I don't want to keep bugging you. Is there anything special I should be looking at? Or is ok to just post them for someone to take a look at? Thanks for the quick response. jets look for no change in the reallocated sector count, and no change in those pending re-alllocation, ((preferably zero for both, but a number that does not change after several cycles is ok as long as it is low) and no attributes marked as FAILING_NOW, and a preclear status that says it was successful.

you are fine. Apparently, 34 sectors were re-allocated before you performed the preclear, and the same 34 existed afterwords. In other words, no additional were detected. I'd go ahead and use the drive, but monitor it over the next months/years. I've got several old drives where an initial number of re-allocated sectors does not change, and they work perfectly fine. If you have time, give it another preclear cycle.

I would not use it. All of the sectors pending re-allocation were re-allocated were apparently re-written in place when the disk was zeroed, BUT 20 more were identified as un-readable in the post read phase. It is possible it is an issue with the power to the disk, but more likely the disk itself. Joe L.

yes

nope... looks to me like it stopped responding. does it respond to a smartctl report? It could be the disk, the cable, the power, the backplane/drive tray. We've seen them all. It has not been successfully pre-cleared. Trust me. try preclear_disk.sh -t /dev/sdi and see what it says. Only takes a few seconds to test if it has a pre-clear signature. Joe L.

other than it being pretty cool, no.

1. It will tell you the preclear was successful 2. After assigning the drives to the array, it will present a "Format" button. It takes a bit of time for 3TB drives, but probably under 10-15 minutes. It does run slower if multiple are being formatted at the same time. 3. Parity creation runs at between 60 and 100 MB/s on most modern hardware (it is near the limit the disks can be read). If you figure 10 seconds per Gig, and you have 3000 Gig with a 3TB drive, that translates to 30,000 seconds. Therefore you can estimate a time of somewhere near 8.333 hours, or longer if your parity calc speed is slower.

no

just cache_dirs -w

A 3 TB drive has an entirely different signature when pre-cleared. It will not be recognized as pre-cleared if cleared with 1.11

thank you. you are right. /ver does not exist.

I agree, sounds high. You should calibrate your wattmeter, even if crudely, by plugging in a known wattage electric lamp. A 40 Watt incandescent bulb should read near 40 watts on your meter. If it reads somewhere near 70 or 80 watts, then the power supply reading might not be right either. It sounds like a very inefficient supply if it is going to be off most of the time. 30 watts when off is a lot, even if you get an employee discount from your electric company. (no, I do not work for the power company, but I think I must look into it... my last bill was over $300 dollars.)

These types of issues cause hair-loss. Because you can pull your hair out trying to locate the random elusive parity error after you assign the drives to the protected array. It is exactly why the post-read test was added to the preclear script... because one unRAID user had a disk drive that would occasionally not return what was written, but not show any other error of any kind. In other words, if installed on a MS-Windows box, you would never notice an occasional program crash or blue-screen. But here, on unRAID when every bit is checked on a drive, we notice, and care. At least you know not to trust the array(or disk) until it can be pre-cleared and entirely read back correctly. Remember, it only takes 1 mis-read bit out of trillions to cause the post-read error you encountered. The interesting part is, each sector has its own checksum on the disk, so it was apparently read correctly, and the SATA communications has its own error checksum when communicating with the disk controller, so it is not likely the cable, but that leaves the cache memory in the disk, the disk electronics, the controller electronics, the power supply, the memory in the server, the motherboard in the server, and pretty much everything except the mouse connected to the server as suspect. I'd start with the easiest, a memory test, preferably run overnight. If the server cannot pass that, nothing else matters. It needs to be corrected first. The memory might just not have the correct Voltage, Timing, or clock speed, especially if it is premium RAM. Some BIOS set those parameters correctly automatically, some do not. Joe L.

It indicates one of the blocks of zeros written to your drive was not read back as all zeros. in other words dd if=/dev/sdc count=200 bs=8225280 skip=121200 | sum did not return a sum of zero. This can be caused by a bad disk, bad memory, bad motherboard chipset, or a bad disk controller, or even a bad power supply. The issue is you cannot trust values written to that disk unless you isolate if it is the disk, or something else. In any case, that same type of error will cause random parity mismatches. You'll run parity checks, and there will randomly be errors, and if you have multiple disks you be pu;;ing your hair out trying to find the root cause. You can try the command above "dd" command again, but I would do another pre-clear, preferably on a different disk controller port, to see if the disk can be successfully written and then read.

Unless your power supply has a physical switch that interrupts the power conductor from the cord to its electronics, it is not really "off" when you press the momentary button on the PC case. It is still supplying the standby 5volt supply that is used to power the LAN chipset and the electronics used to monitor the power pushbutton on the case. Unfortunately, most consumer electronics works the same way. Very few have an actual "power switch" these days. (and if it has any remote control that can turn it on, it cannot really completely be turned off) The only difference you'll find is how much current they draw when "turned off" waiting for you to put the button on the server to them on.

You did not add command as I described, so the echo is still running immediately. You need to add the line as I gave in my example. echo "echo 3 >/proc/acpi/sleep" | at now + 1 minute not as you added it echo 3 > /proc/acpi/sleep | at now + 1 minute

Because post-read is verifying what was written is all zeros. Pre-read is not verifying, it is just sending the contents read to /dev/null as existing contents could be anything Is that a 3TB drive?