RobJ

Questions to consider - * Spin status (active/standby state) - this once was handled by temps showing or not, I prefer not using this method, as I believe we are moving toward always showing temps for those drives that support it. Then it was handled by a steady or blinking green ball. Now it's a green or grey ball. The question is, keep it roughly the way it is, with spin status mixed into drive status, or separate the spin status - add a second column with up and down arrows, large enough to click on to spin up or down (hover text could be "Standby - click to spin up" and "Active - click to spin down"). This option unfortunately means a little more coding (but little testing time) ... * If spin status stays mixed into ball color, how should it be represented, green/grey like the current? Or slow blink, or animation switching between filled and unfilled shapes? (Does the fact that the border stays drawn (filled/unfilled) remove the 1-bit problem, and the differing backgrounds problem? * I like Tom's comment about yellow-blink representing a rebuild in process, might be nice for any rebuild including parity. (subject to complaints about blinking though) * Sounds like everyone likes the new shapes (green=round, yellow=diamond, red=square, blue=? ? ?, grey=? ? ?), any further objections, especially from those who most need them? Are red and blue confused by certain color-blind people? * I thought I remembered seeing an orange ball, probably in a past release, and I *think* it was an array state. Am I wrong? Is that changed now? * User Share State colors - I agree with WeeboTech, I'd rather not see red for an informational color use, blue would be better. And since the share state color is informational only, perhaps there's something better than yellow? Grey?

The drive looks great! Enjoy it. (I'll bet you looked at those RAW numbers for the read and seek error rates? Don't! They mean nothing to us, only to the manufacturers, and they are typical of Seagates. What's important for the error rates is the VALUE, and both are perfect!)

Tom released -rc3 with kernel 4.0.4, because of some important BTRFS fixes. And -rc4 is in testing...

I'll leave that up to you. You have already run another Preclear pass on it, as the 2 sectors showed up at the end of the second pass. I suspect you'll feel more confident after one more pass.

I think the disk is fine, just false positives. It's rather unusual to suddenly find them on a read pass, just after all sector media has been refreshed. But on subsequent testing, they were fine and put back online. The only thing I can think of is a possible power issue during the second post-read. Any power outages or lightning strikes around then?

Thank you!

Raw_Read_Error_Rate has bottomed out, far below its Threshold. If you can read the drive at all, salvage everything important off it ASAP. Because it's FAILING SMART, it should be an easy RMA, if that's possible, and in warranty. Just curious, what drive model is that? I've never seen an ATA error listing of 8, it's always the last 5 errors, not 8. Plus, it uses 252 for as-yet-unused values, somewhat unusual.

Throughout the history of the wiki, the demand (for info) has far outstripped the supply. Or put another way, there are far more users wanting information, than there are users willing to put it into the wiki. It's almost completely a community effort, but volunteers have been few and far between. If anyone reading this is interested in helping, please see Wiki editors needed.

Can I modify my request? I'd like to add to the diag zip file all the .cfg files from the /boot/config folder, plus super.dat and go. Perhaps later, you could add every cfg and log file, in their tree structure, from the /boot/config tree. No hurry, any time in the next week! (would love it before v6 goes final!)

You can delete it, as it's just ignored, superceded by the CacheDirs plugin. I have to say it's the first instance I'm aware of, but if one user has it there, then there may be an instruction somewhere suggesting putting it there, so there may be others with it there too. I'll add a note about removing it. From the little anecdotal evidence available so far, it seems like 1GB may be fine, but certainly 2GB would be 'finer'. Either way you go, let us know how well or poorly it works for you. Thanks for your feedback!

Yep, that's a corrupted Reiser file system. Whenever you start up, it's going to mount it normally, until you do the particular file I/O that touches the file system corruption, then it's going to remount it read-only. Please run Check Disk File systems on Disk 4.

You should probably check the syslog. If file system corruption is detected, the file system is changed to read only. You may want to check the file system on the destination drive you were copying to.

I completely concur. You had pending sectors drop on both the preread and the post read (which should never happen), and then not be cleared to zero on the zeroing phase! Something is really wrong with that drive. Another Preclear, even if perfect, would not restore my confidence in it. The only other thing I could suggest is to try the manufacturers test tool on the drive, more from curiosity than anything else.

The UNC flags indicate UNCorrectable sectors. This was only a selection of the associated error lines. There should also be exception lines indicating 'media error'. You've got more bad sectors. Sorry.

In a way, that's good, and we can hope that that explains the surprising pending sectors. Another clean Preclear should prove it.

If this were the result after your very first Preclear, then the drive is probably fine, but you would want to monitor it for a year. But above, it looks like the pending sectors showed up AFTER a Preclear, and that should never happen. While the drive looks fine at the moment, I'm not ready to trust it, and I would recommend Preclearing it twice more, only trusting it if it stays perfect through both. Seems too coincidental, but is there any chance the drive previously Precleared perfectly, then just after that finished, you detected a power outage or power spike or nearby lightning strike?

Since you are about to trash that parity info, I can't think of any reason to do a parity check. I'd stop it, replace the drive, and start the rebuild now, save some hours.

Just my opinion, but #3 is clearly the best. #1 is not an option, sorry. With those pending sectors, it probably cannot be used to rebuild any other drive that failed, so you don't really have full parity protection now. #3 restores your parity protection the quickest. Once finished, the pressure is off, and you can do whatever you want when you want. But yes, it means a delay in your intended use for the 4TB drive.

The "Raw_Read_Error_Rate=8" is not a problem, because the raw value for that attribute is meaningless. What's important is the VALUE for it, 200, which is perfect. What IS a problem is the "Current_Pending_Sector = 2". As was stated above, that HAS to be zero. If this SMART report occurred right after a Preclear then that is a bad sign. Preclear it again, and if Current_Pending_Sector stays non-zero, I would not use that drive, it can't be trusted.

Just a caution before you throw out the drive too quick, pending sectors may or may not be bad. The numbers you showed do indicate the drive needs some repair work, but do not mean the drive is bad, until after testing it. Technically, 'pending' means 'pending full testing', which happens once you tell the drive you don't care about the current data stored there. You do that by writing to it, so that the drive now knows you are OK'ing overwriting the current data. It then can thoroughly test the sector to see how safely it saves test patterns, and if good, saves the data you requested to be saved there and unmarks it as pending. If it decides the sector cannot be trusted, then it is remapped to a good spare sector. A sector is marked as a 'current pending sector' when it fails to be read correctly, even after applying the error correction info. That can happen either because of weak or damaged magnetic media under the sector, or because of electrical activity (spikes and outages while writing) that have scrambled too many bits in the sector. I tend to call the latter ones 'soft errors', because the physical sector is completely fine, and testing will prove that. If you have had a power outage or sparking or other serious power issues, then the 64 sectors may just be soft errors, and the drive be perfectly fine, once tested and rebuilt.

Drive looks fine, no issues. Popular pass counts are one and three, I run just one pass, but many like 3 passes. Just means the pre-read found a sector where the data was scrambled enough that the ECC (error correcting) info could not fix it. But further testing found that the sector media underneath the sector was good, so good data is now written there. If in doubt, run another pass.

You definitely do not want to use it for your parity drive! If you have time, you might try one more pass on the fourth drive, but connected to a different port. If it still is a slow writer, that won't usually matter too much as an unRAID data drive, since typically you are archiving data to it, not using it for applications. It will be best reserved for old backups, and files that rarely change, operations that involve few writes but many reads.

There's now a case-in-point, concerning the value of re-formatting your v5 flash drive when upgrading to v6, see here.

There do not appear to be any issues evident with any of the drives, apart from a slower write speed for the fourth drive. The only difference is that the fourth drive reads a little faster than the others, but writes half as fast as the others. For the fourth drive, preread time was 11 hours vs. 11.5 hours for the other drives, and postread time was 21 hours vs. 21.5 hours for the others. Write speed was 20 hours vs. 10 hours for the others. You can examine the complete SMART reports for each drive, to see what their firmware is (in the 'INFORMATION SECTION'). Perhaps one of the drives has a different firmware version. If you did all 4 drives simultaneously, then there may be differences in the drive controllers and busses used. It would still be hard to explain writes being much slower and reads faster though.

Nice page, thanks! I'm going to point to it. So much of the wiki is old, written for v4 and v5, which are all 32 bit. Limited memory is probably the reason.