RobJ

I suspect that there are many users who have installed Cache_Dirs, but don't actually need it. If access to your files is solely through the User Share system, and you don't fall under the NFS exception mentioned by WeeboTech (learned something new today!), then you don't need Cache_Dirs. The User Share system acts as a Cache of Dirs, because it is the merger of the individual disk directories, kept in memory. And if you do access your files at times directly from the disks, but don't have any programs that poll those disk directories and you only rarely 'explore' them (with a file manager, such as Windows Explorer), then you don't strictly need Cache_Dirs either. Cache_Dirs may add some convenience though, because if you do feel like browsing through the directories of any disk, Cache_Dirs will have them in memory and the drive won't have to spin up. I recommend reading the original document on Cache_Dirs, Keep directory entries cached. It's a little dated, but still helpful. If you need to access a file, for example to play it, then you are asking for the content of the file, and that isn't cached. So the disk it is on will have to spin up, causing the delay on first access you see.

This was an option left in by Joe to satisfy users who still felt it accomplished something for them, but it is difficult to see the rationale for that. User shares are a file system maintained entirely in memory, so caching them is just making an extra copy of the file system elements in the same RAM. That seems like a waste of RAM, with no benefit. The idea behind Cache_dirs is to keep in memory those file system elements that are constantly being requested from disk, so that the disk does not have to keep spinning up. I would set this to NO and free up some memory.

It looks like you used "it8728-isa-0028" instead of "it8728-isa-0228". Safer yet, try "it8728-isa-*". Simple, click the 'Insert Hyperlink' button above your edit message box (has an earth icon, located below the Italic button). After the initial URL, add an equal sign and the link, then the display text between the pair of bracketed 'URL's. Like the following: [url=http://ubuntuforums.org/showthread.php?t=2201555]Ubuntu forum link[/url] Displays as: Ubuntu forum link

The Seagate looks fine. A few things to note however: * There is a message about a firmware update for the drive. You should probably check it out, determine whether it sounds serious enough to be required. * At some point in the past, one critical attribute Seek_Error_Rate dropped somewhat lower than normal, to a scaled value of 049. It's currently at 062 which is typical for Seagates, but the fact it dropped that far *may* indicate a drive that is less than perfect mechanically. * The temp sensor seems odd. Was this drive 'refurbished'? On the initial SMART report, it shows a temp of 26 (Celsius), with a lowest ever of 26 and a highest ever of 26. In other words, it's either not working and fixed at 26, or it has been reset and all previous temp history was cleared. On the final report, it does vary a small amount, from 25 to 28 (which seems low). If it has been reset, then others may have been too, and that makes other SMART values less trustworthy, a little more concerning, especially the Seek_Error_Rate, as a very recent drop. I would monitor this drive for awhile, perhaps check a SMART report weekly for a month or 2. Otherwise, the numbers look fine.

Chuckle chuckle! Really, I don't *try* to be a trouble maker! I know you were just trying to make a point, but for anyone that might be confused by Brian's hyperbole(!), drives don't spew garbage, they spew errors. However, it's true that we have heard here of a few cases where it seems provable that a drive returned corrupted data, on the order of 1 bit per 10 gigabytes? With apologies to Jonathan (I don't know your situation), I still remain rather skeptical about some of the individual cases, but I agree it is possible, although extremely unlikely. Brian brings up a good point, that we as UnRAIDers are 'uber diligent' about disk issues, and are far more likely to both detect and be concerned about even one bad bit per terabyte, where as the great unwashed masses of Windows and Mac users will probably never know about it if it happened to them. I think we have a problem of scale here. Yes, we are uber vigilant, and yes we have far more disk storage than they do, which multiplies the probability of the issue, but there are so many many more of them. It's hard for me to believe that (compared to how few there are of us) the worldwide hundreds of millions of Windows and Mac users haven't run into this issue before. They may mostly be ignorant, but not all of them are. And what about the relatively small but very significant enterprise segment, with mostly RAID protected hard drives, have you ever heard of this issue being widely discussed among them? I've heard of discussions of bit rot in the past, but that and similar are not really a problem any more, because of the error correction info embedded in the data sectors. When we had this discussion before, I in essence challenged others to come up with a valid scenario that could explain these corrupted bits, and Joe L and Bubba came up with valid ideas. I only remember one of them, the case where the internal memory was bad. The scenario would be: * we have a given sector being requested, with good uncorrupted data on the disk surface - (data is good) * we read the data into a memory buffer (within the drive) - (data is still good) * using the error correction info and CRC, the data is checked, and found to be good - (data is still good) * the data is corrupted, either bad memory flips a bit, or bug in the firmware or a flaky hardware register causes a byte to be corrupted - (data is bad (but assumed good)) * packet is created with fresh packet overhead and CRC - (packet is good, data is bad) * packet is transmitted to the machine containing this drive, error checked at every step of the way and always found to be good - (packet is good, data is bad) * packet arrives at destination buffer, data is moved to its destination memory location, no errors at all have been reported - (yet data is bad) * if executable, it's run with possibly defective behavior; if streamed, may be played with possibly detectable playback flaw; if stored, will be stored unknowingly corrupted; if it's part of UnRAID parity check, will produce 'incorrect parity' error The one conclusion we can make is that if we are convinced that a drive is doing this, then it MUST be replaced, even if nothing else appears to be wrong with it (eg. a perfect SMART report). I do like the ideas of Jonathan and Brian here, a diagnostic mode with enforced read-only access, and delayed approval of reviewable corrections. I'll probably always do correctable parity checks myself, but the ideas are good and will prove useful in certain diagnostic circumstances. I think Brian also proposed being able to do parity checks across specified ranges, which would clearly be useful here. You could test and retest specific blocks. I'll just end by saying I completely agree with Gary. The chances of one of these bit anomalies occurring seems so small that if I'm going to worry about it, I might as well drive a tank, armor proof the house roof so no airplane tires or satellite debris crash through, get someone else to taste all my food first ...

Controller throughput and bus throughput are certainly important factors. Perhaps the biggest factor is the rotational speed of the drive. If you check the User Benchmarks, Preclear Times wiki section, you can see that rough speeds for 7200rpm drives is 10 hours (+/- 2 hours) per terabyte, and that rough speeds for 5900rpm drives is 13 hours (+/- 1 hour) per terabyte.

DToX, he wasn't actually responding to you, he was announcing an issue he had found, one that should be straight forward to fix. I'm actually happy that you have the same issue I have, needing the Fintek f71882fg driver. I suspect you haven't read my post above (found here). Now that I know someone else needs 'f71882fg', I'll ask Tom if he can add it to UnRAID (didn't want to before if I was the only one). Since yours is very similar except your board uses the k10temp chipset instead of the k8temp chipset, I think you can probably use the sensors.conf file I posted, except change "k8temp-*" to "k10temp-*". Make sure you use an editor that keeps the linux line endings. That should at least give you 2 CPU temps for now, until f71882fg support is added. Be aware though that many users have reported that the k8temp and k10temp chipsets are notoriously unreliable for true temps. Works fine for me though.

preclear_disk.sh -n /dev/sdX It will still do the entire write zeroes phase, plus write the preclear signature, but skip the pre-read and post-read.

Parameters like reallocated sectors are maintained by the drive, not Preclear, so just Obtain a SMART report and you will have the equivalent of the preclear_finish report. The Preclear start and finish reports are before and after SMART reports, the preclear_rpt is a comparison of those plus a little summary info.

Yeah, renaming the Cores does not seem to work, you have to rename the 'temps'. I haven't read enough to fully understand why. 'MB Temp' and 'CPU Temp' are the 2 labels that Dynamix is looking for, and they don't mean a thing as to what the true source of their temp numbers are. We use sensors.conf to force renaming the first 2 ports from the default values to what Dynamix is looking for. I don't know what 'Physical id 0' is, you will have to do some research on coretemp. You might try the 'modinfo coretemp' command, may produce some helpful info. Who knows, 'Physical id 0' might be the max of the 4 core temps! In your example it is, but that could be coincidence.

Try a simple one like this: chip "coretemp-*" label temp1 "MB Temp" label temp2 "CPU Temp" If you get anything at all, then you can experiment with changing temp1 and temp2 to other things. Make sure this sensors.conf is put into /etc/sensors.d, then refresh the Dynamix screen. If it works, then make sure it is copied to /boot/config/plugins/dynamix for reinstallation after each boot.

Good write up! I've added it to the UnRAID Topical Index, Backups topic. You may also want to examine it for previous discussions about backups.

Done.

What happens when you try the modprobe it87 command at a command prompt? If it says 'device busy', you might try what pauven did here (near the end of the post). Or try what xamindar did here, forcing a different ID.

Here's a quick and dirty setup for AMD based boards that use the k8temp driver, most of those with Athlon 64 or FX or Opteron CPU's. It does not show the motherboard temp, only the temps for the first 2 cores, but since the temps on the Dynamix screens aren't labeled, that's OK. It should work for most k8temp-compatible boards, but apparently some of these boards do not reliably show correct temps. Hopefully yours will, as mine does. * Install the Dynamix System Temp plugin, and reboot. You should see the 2 temp icons above and to the right, but with blank temps. * Copy the attached sensors.conf.txt file to the flash drive, to the path /boot/config/plugins/dynamix. In Windows, this path would be something like \\tower\flash\config\plugins\dynamix. Rename it to sensors.conf (remove the .txt). * At a console, copy the same sensors.conf to /etc/sensors.d, and refresh your Dynamix screen. (Or you can reboot again.) * If it worked, your Dynamix screen should display the 2 temps. They aren't labeled, but just remember that they are CPU core0 and core1. This is partly from memory, if I've missed a step, or something behaved differently than stated above, let me know, and I'll revise this. Why would someone do this instead of the longer but more complete Wiki instructions (found here)? * To see if it works first, before trying the longer procedure. * You don't feel like installing Perl and dealing with the technical questions of sensors-detect. * Because like me your board requires a driver not installed with UnRAID. My board needs the Fintek driver f71882fg. You can check here for more board and sensor chip driver info. Edit: Really sorry, I forgot one of the most important steps. Inserted above. sensors.conf.txt

Wiki page was: Setting up lm_sensors to display CPU/motherboard temperatures in add-ons such as SimpleFeatures Renamed to: Setting up CPU and board temperature sensing I've updated the wiki page for Dynamix, added a few Dynamix specific notes, and renamed it. Well technically I moved it to the new name, with a redirect at the old name. So the old name still works, but lands you on the wiki page under the new name. If you wish, bonienl, you could edit your OP to point to the new name. Also, it would be nice if you could check it over for accuracy.

In my experience, by far the most likely cause of all CRC errors is the cables. I'd concentrate most on them (besides it's the cheapest thing to fix!). You say you changed the cables. Were the replacements known to be high quality and good cables, tested on other drives? I strongly recommend never skimping on SATA cables, especially since very good quality ones can be obtained so cheaply at MonoPrice. Try swapping a suspect cable with one known to never cause errors, then see if the errors follow the cable. Make sure the cables are not tightly tied together, especially tied with power cables. They look very neat that way, but are more likely to suffer interference and crosstalk. Check the connectors on both ends, and the connections on the drives and the ports on the card, make sure they are clean, no apparent dust or corrosion. Make sure the power cables are well connected too, especially any power cable splitters. If in doubt, try swapping suspect connections with known good ones, and test. Another less likely possibility is the power supply. Flaky power can cause drive interface issues. I suppose overheating drives could too, but you would have mentioned that.

No good ideas here. Just to eliminate a possibility, can you try re-running with adjusted email options, as the -M 4 option runs some code not used by anything else. Try -M 3 and lower, and perhaps with no email at all. Are you receiving the emails correctly, both with and without the -c option? Most likely, Joe L will have to help you, when he has time.

Drive couldn't be more perfect (but you probably knew that, right?)

The important number for those is the VALUE, which for both is 100, as in 100% perfect, can't be any more perfect than that. It's not that they are close to the threshold, but that the manufacturer has factory set the thresholds to start so close to 100, who knows why. Your SMART reports for that drive appear to be perfect, nothing to worry about.

It's hard to conclude too much from just a short syslog excerpt. It's best to attach the entire syslog, zipped, plus a SMART report for the drive. There is evidence of a bad sector, plus some other failure, but I'd rather not make any conclusions without seeing the very first error reported, plus the SMART info.

I did some research, and found only 2 possibilities - the drive SMART firmware tried to write to the SMART log but SMART was not enabled at that instant (possibly at drive startup), or there is a bug in the SMART firmware on that drive. Not something to worry about, as it only happened once (the second is a retry of the first), and that was a long time ago.

I was too tired to take much time with it, sorry. This SMART report is intact, thanks. The line above shows 81 Current Pending sectors, a very ominous sign, especially when you only have 5 operational hours on the drive. It means it has already found 81 sectors that are probably bad. As near as I can tell, you have started Preclear 3 times, then aborted it quite early, probably because of the errors and how long it was taking, but these short passes make this even more ominous, in that you shouldn't find even one error over the entire drive, and you found 81 in just the first 1 or 2 percent. What I based my opinion on was the syslog you attached and the 2 syslog excerpts you posted. They all show a series of errors logged by the exception handler. All of them are noted as 'media error' which means a problem with a physical sector on the drive surface. More specifically, the error flag raised for each of those sectors is 'UNC' (short for 'UNCorrectable'), which means the sector was found to be corrupted so much that even the embedded error correction info could not fix it. Because these first Preclear passes are just read passes, we CANNOT conclude for sure that the drive is bad yet, until the drive attempts to fix them, by rewriting them correctly. At that point, the drive will determine if the magnetic media under the sector is good or bad, and either return the sector to service, validly rewritten, or remap it elsewhere (as a reallocated sector). The drive MAY be bad, but the SMART report is not showing any mechanical issues, so far, so it's possible the magnetic surface is good but has been scrambled some how??? Not likely, but possible. An immediate zeroing pass would probably be a good next step, skipping the Preclear Pre-Read, and forcing writes to all sectors. It should rather quickly help you decide if the drive is worth further effort or not. Syntax I believe would be "preclear_disk.sh -W /dev/sdd".

I would run another Preclear or 2 on it, check for additional reallocated sectors. If you can obtain clean results, no further adverse numbers, then it is usable. With that many reallocated sectors, I know that some users would prefer to reserve the drive for secondary uses, such as holding backups.

You have a series of bad sectors on this drive, very early on it too. The SMART report was not very useful, as it was truncated on the right side at 80 columns, cutting off the RAW numbers. Not sure what did that.