RobJ

Howdy, and thank you for the all of the work you have put into this. I don't know if you are interested in adding this, especially since it's a changeable variable per session and because it's probably only useful for troubleshooting. But you can find the ata numbers for some of the drives with the lsscsi -vgl command (they are in the middle of the path displayed). There are problems, they are only available for standard disk controllers (like onboard ports and controllers that use AHCI), not drives on SAS or other non-standard controllers. And technically, they are the channel ata numbers, not the full ata device symbols, so there may be multiple drives with the same ata number if it's on an IDE channel, or port multiplier, or other multi drive channel (with SCSI ID's like sd 8:0:0:0 and sd 8:0:1:0).

Speaking of anomalies, I suppose I'm one. I still don't use User Shares, so would appreciate support for disk shares. I have been wanting to try this as a plugin, once development settled down and there was sufficient testing. I would also like to add it to the upgrade guide, as a recommended plugin. I'll wait a little longer though for that.

Outstanding work! I'll try to get this linked in the wiki.

You haven't seen my special version And what's the time frame for release? I hope it's configurable, I'd prefer root beer and ice tea!

That was true for my system, and appears to be true for others.

Looks fine to me! Sectors that appear bad may be because they ARE bad, or may just look like it because an electrical spike occurred while the sector was being written, causing scrambled data to be written. Once tested and rewritten, they prove that the underlying physical media was undamaged, so they are restored. That appears to be what you have.

It happens on boot, after the boot menu is shown and unRAID is selected and loaded, and a minimal kernel is running, but before anything on it is opened, probably before it was mounted at /boot. It's not logged in syslog or dmesg, the only place I saw the output was on the attached console.

That's a very nice piece of writing, and a good discovery, thank you! It accords completely with my own suspicions, after the ACPI reading I've done and all of the ACPI issues I've long seen in our many syslogs. It needs to be quoted more often. Occasionally I compare syslogs with older ones from the same system, and notice a BIOS upgrade. Rarely do I see any changes in the number of ACPI issues present, so clearly there was little or no interest in fixing them for the Linux world. I'd have to hunt, but I don't think I EVER see a syslog without any ACPI issues. If there are, it's uncommon. When I look through syslogs showing a system that is 'waking up', it is absolutely amazing that a system that looks so broken can possibly return fully and reliably to operational status! It's improving now, much better than the earlier years, but it still looks scary.

I would upgrade to v6.1, it's final now. There a few plugins you won't be able to add until they achieve 6.1 compliance.

Thanks RobJ, I have replaced the Toshiba and in the process of rebuilding. So to clarify, you suggest running the preclear on the Toshiba to clean out the pending sectors? It's still under warranty, I had in mind to RMA it. Is it worth keeping at this point? I was planning on just writing zeros (with the -W switch) and sending it back. Would the zeroing of the drive alone fix the pending sectors? Some users are quick to RMA. My preference is to try to clean it, while monitoring the SMART info. I would hope that the first Preclear clears all pending sectors, then the second Preclear has no changes at all, indicating some stability. Some users would Preclear it one more time, dare it to misbehave. If it takes more Preclears, then my confidence in the drive starts dropping. No experience. Hopefully someone else will respond.

No problem here. That's a historical counter, indicates there was one in the past, but it's fine now. The Current Pending Sectors ARE a problem! They MUST be dealt with. Do you have a replacement drive? Preferably, you want to unassign it, start and stop the array without it, then assign the replacement drive and let it rebuild onto it. Then Preclear the Toshiba above twice, until clean, no pending sectors.

Please see Need help? Read me first!, and attach the diagnostics zip.

V6 completely supports 3 different file formats, and the array can mix them up, all of one type or some of each type. Parity protection does not care about what's on a disk, including what file format it is in.

I should have known you were on top of it!

JonP, this is rather worrisome. Those SCSI ID's can change, just as much as the sd symbols and the ata numbers. It's true that some systems seem to be more 'stable', especially small systems with no added disk controllers, but otherwise, I can't see how hard coding the SCSI ID in will work across boots. It will at times, but not reliably. A user could reboot and it would stop working, then reboot again, and it would start working, if that session happened to match the same lsscsi list. If you have multiple diagnostics zips available, test this yourself, compare the lsscsi.txt files.

Nice work! Nice additions! There's one change that I personally don't like, but is a great idea for others (so just ignore me!). That's the addition of the ata numbers to the drive names in the SMART folder. I can see how that will be a really nice help for most, because the main reason you want the ata numbers is when you are looking at exceptions in the syslog, and want to know which drive. For me, it makes a little more work when I want to compare an older SMART report with a newer one, because ata numbers are variable and change a lot, almost as much as sd symbols. But that's much less important than making it easier for inexperienced users. I suppose if you are adding that, you might consider adding disk number and symbol (e.g. _ata4_md2_sdj or _ata4_d4_sdj, _ata7_par_sdc or _ata7_p_sdj, _ata13_cache2_sdw or _ata13_c2_sdw). See what you started! I still would like to see, some day, a Main page text mockup, with drive names and symbols (and ata numbers!), with errors and I/O counts and free space and status info (abbreviations for color balls/icons). It would really help give an at-a-glance view of what the user is seeing. I know this is more work though ... Unless there's more going into the qemu folder, non-log files, could it be combined into the logs folder? The Diagnostics page needs updating (something you already know). There's no Help text for it, but the whole page IS help text!

I assume you are talking about a hash of the flash GUID? It's unique, controlled so hard to game, non-identifiable once decently hashed, and deterministic so nothing to store (or client storage code to write). I see it on the Vars page, down at - Or it could be grepped from the syslog.

Perfect time for a SMART long test! Since the long test examines every sector, it should (if the code is done right) reinitialize the overall counters, as to how many are really remapped. It's probably a coincidence, but can't help noticing that both VALUE and WORST for Reallocated_Sector_Ct is 57, same as the leading integers of the RAW 57240. Could be a bug there. Unfortunately, that doesn't make sense from a programmatic view, as it's 57 and 57000, VERY different numbers. The one way you can estimate the number of spares a given drive model has is to find one with a number of reallocated sectors and see how far it dropped the VALUE for Reallocated_Sector_Ct. It dropped it 43% for your drive with a count of 57240, so if you extrapolate that, you get an estimate of about 130,000 spare sectors, an obviously crazy number! What we need is a SMART report for another ST3000DM001-9YN166 with reallocated sectors, to see what the real spare count should be. You are at 6300 operational hours now. Back at 2860 hours, something went wrong, ostensibly with uncorrectable sectors. The reported LBA numbers are meaningless though, so it's hard to tell what actually was wrong. Certainly not confidence building in this drive. All other numbers look fine, with a very few runtime bad blocks and uncorrectable sectors, nothing that correlates with 57000 of them though, or even 240 of them. Kinda funny but the Raw_Read_Error_Rate has improved with every single SMART report, has never been worse than 99 (almost perfect).

I'm sorry, I realize I skipped right over the obvious. The count of 57240 is clearly not a real number, roughly 10 times the possible maximum, just a random number, indicating corruption in the SMART system. I completely forgot to state that, just assumed others would automatically recognize that. It would be interesting to see the SMART report, see what other corruption it reveals. It wouldn't surprise me if there actually aren't ANY sectors reallocated, but probably going to be hard to tell for sure.

You may want to Preclear it one more time, see if you get the same result with no change. But after that, it's going to be your decision. I have several drives with corrupted SMART stuff, that I've lived with for quite awhile. One drive was hit indirectly by a lightning spike, ruined the SMART firmware, but nothing otherwise (had to turn off SMART detection on that computer or it wouldn't boot). It slowly clicks 7 times on power up, then runs perfectly and fast, for the last 3 to 4 years. Another drive suddenly showed ALL spares used, max number of reallocated sectors, yet tests fine. Another has temps that jump around 30 degrees once or twice a year, was 96 C, now 61 C, but actually same temps as others (about 33 C). In each case, I saved anything important off, and used them only for non-vital stuff, until roughly a year had gone by, then trusted them with anything. One is finally dying, but I got an extra 3 odd years from it, with no losses. Or you can RMA it.

For the current v6 versions, the temps were moved to the bottom, toward the right, just to the left of "unRAID webGui c 2015 ...". They aren't in the upper bar any more.

That's a recent change, I believe, and a significant one. Apart from a recent post by bonienl, I don't think I have seen any mention of it anywhere! It IS in the Help info for Enable disk shares. I'll make a note about it in the upgrade guide. This is explained in more detail in the 6.1rc1 release announcement Indeed it is! I must have skimmed right over it!

That's a recent change, I believe, and a significant one. Apart from a recent post by bonienl, I don't think I have seen any mention of it anywhere! It IS in the Help info for Enable disk shares. I'll make a note about it in the upgrade guide. bonienl, hoping you will see this, there's a misspelling in the Help info for this. I don't know what 'partiticapting' is, but it sounds like too much adult fun for this board!

Sounds about right. Except, I would probably recommend using mc (it is a part of unraid now). It should be much less scary than rsync for newbies. You're right. I've revised it. Thank you!

Not sure where this should go, but wanted to say, nice improvements to the Upgrading to UnRAID v6 guide, and also nice to see additions to the Diagnostics zip. In connection with the Diagnostics, I'd like to suggest a few tweaks - * change the lspci command to lspci -knn (more helpful info) * change the lsscsi command to lsscsi -vgl (more helpful info, also adds the ata numbers!) * add a ps list, not sure the best options, perhaps ps -eF ? Getting the right ata numbers for the drives would be very useful.