RobJ

No problems. It is very normal to have what are often called soft read errors and soft seek errors. The drive system detects them, makes the appropriate adjustments, and retries them, usually successfully. The important number here is 200, unchanged, essentially perfect for this drive. At some point in the past, the read error rate did increase, perhaps because of thermal expansion or contraction, electrical disturbances, drive vibrations, who knows what, and the scaled rate dropped to 188 (as shown in the WORST value), which is still a long way from the failure point of 51. It has since returned to normal, at 200.

The drive looks fine, obviously brand new with 0 Power_On_Hours initially! The UDMA_CRC_Error_Count is 0, and stayed 0. The number 253 seems to generally be used as an indicator of "Not Used Yet" for an attribute, so this probably represents the fact that the function handling UDMA_CRC_Error_Count was called at least once, and therefore since it was the first time, initialized WORST (the number in the WORST column) to its starting value of 200. So that does not really represent a change. At some point, I would like to create a guide to help others understand these SMART attributes. They are unfortunately very inconsistent in their behavior, not only between the different attributes, but between the various drive models, and especially between brands. In some cases, the RAW_VALUE is the counter to watch, in others, it is more important to watch what VALUE does, and there are many other possible behaviors. To understand a particular SMART line, you have to understand how that SMART attribute is usually handled, keeping in mind who the manufacturer is, and to a lesser extent, what drive model it is. I have tried researching it online, but information is really skimpy, nothing authoritative at all from the manufacturers themselves. You can use this table of SMART attributes to help you understand them, but every manufacturer uses a different set of those attributes, even uses the common ones in different ways, even across their own drive models.

Added to the FAQ (with a link to here). Feel free to edit or expand. How much usable space will I get from an unRAID array? If you have any concerns about the direct link to your site, please let me know and I'll make whatever changes you like. You are welcome to edit the wiki yourself, of course.

No problems at all. Since the rate of zero (the RAW number) is the same, there is no real change here. For some reason, the scaled numbers, VALUE and WORST, have been reset. The number 253 usually seems to indicate "Not Used Yet".

Drive looks perfect, brand new with less than one day of service!

That is not normal, both read and write caching are usually enabled. I don't have any ideas as to what to make of it though. You are using a board based on VIA chipsets, which is usually problematic. I can't say it won't work, but I have seen little success with VIA based boards here. I know you said the 3 drives are "Seagate Barracuda ES 750Gb" drives, but they don't look like anything I have ever seen before. Neither the Linux kernel or Smartctl 5.38 were able to identify the manufacturer. They are identified by SMART as (with different serial numbers): Device Model: GB0750C4414 Serial Number: 5QD51Y9T Firmware Version: HPG4 Perhaps someone with experience with the ES series of drives can help here. Squeaking sounds are definitely not normal either, I don't think I have ever heard a hard drive squeak. Are you positive that the squeaks are coming from the drive, and not a fan?

No problems that I can see. Neither the VALUE or WORST dropped from 200, so it is still considered essentially perfect. At some point, it would be good for someone to prepare a table of these attributes, with expected ranges, and comments on their seriousness (or lack thereof) of particular results. Unfortunately, the table would have to take into account all of the inconsistencies between brands and models.

No, I don't know of any reason (for now) that High_Fly_Writes should be given any significance at all. They are not a Pre-fail item, so they aren't considered critical, and don't impact the Pass/Fail health test of the drive. I'm going to suggest to Joe and Brian that they consider dropping any checks of 189 High_Fly_Writes and all of the 240's, as there is no reason to unnecessarily alarm users. In researching through SMART reports that I have seen, only the latest large Seagate drives actually use the High_Fly_Writes attribute. They appear to be counting something associated with High Fly Writes in the RAW_VALUE. VALUE and WORST are just 100 minus the count in RAW_VALUE, until RAW_VALUE reaches 99, and VALUE and WORST hit bottom at 001. The threshold THRESH is only used for items marked as Pre-fail, is otherwise usually meaningless. It sometimes appears to have a good practical threshold value, which I assume means "it is preferable that WORST stay above this value", but has no other impact. In this case, since VALUE drops from 100 to 001, I have to assume that they haven't fully implemented this attribute, or haven't decided a reasonable scale of values. Future drives will undoubtedly change how High_Fly_Writes is implemented and counted and scaled. Somewhere, Brian did some research on it, and had some comments, but I don't know where they are.

I just want to be clear, I did not see any problems with sdq, the other drive, and only what appeared to be cable or connection related errors with sdn. At least from the info I had available, I don't see any problems with either of the drives themselves. I would like to note that although the Power-Off_Retract_Count did increment, its VALUE did not budge from 200 (its peak or starting value), which indicates to me that this is well within expected values, and probably not a concern (at least as far as you can trust SMART data!).

That syslog is a mess! And it's only the latter part too, it is missing the 600 to 900 odd lines of system setup at the beginning. The drive with ID of sdn probably has a poor quality cable. I would replace it if at all possible. And Joe is right, there were page allocation failures for many subsystems, including the share file system, Samba, and possibly involving the networking and Reiser file system modules, which is worrying. In this piece of the syslog, I don't see any kernel panics, so I don't think we can say for sure that there is any damage, such as evidence of flaky memory, or corrupted Reiser file systems, but I never fully trust a system that has crashed. Always better to restart fresh. I certainly would not try to run anything important, once I saw the first sign of suspicious system operation. Those 'Call Traces' definitely qualify as suspicious system operation. Grabbing the syslog and waiting for advice was the correct thing to do. Even though I saw no 'panics' here, to be safe, I would reboot and run a full memory test first, then run reiserfsck on each of the data drives (see the Check Disk File systems page for instructions). I'm sorry, it is somewhat time-consuming, but it is better to be safe. The memory test is probably not needed, so you can postpone it if you wish, but I like to be thorough, and know whether a system is truly trustworthy, especially when I have just had extensive memory-related problems. I would like to say test only the data drives you were actually using, but it appears that there were numerous spin downs to many drives, and the mover ran at least twice, so it looks like all or most of your drives may have been written to. 2 GB of memory should have been more than enough. I can't see any reason so far for the problems, at least not from this syslog.

WeeboTech will probably be here soon with the more expert answer, and I haven't actually used rsync (!), but apart from that, wouldn't you want to use the UNC paths here? //tower/disk1/Backup/MKV Or if you have set up a User Share for Backup, then //tower/Backup/MKV

OK, that is just ridiculous! Do you realize what you have done? Showing us pictures of one of the more elegant wiring jobs I've seen? I was tempted to put up a pic of mine, but no more! And think of all of the other DIY'ers, who have now been so intimidated, their pictures went in the trash, and their machines into the closet! Edit: OK, I over did it a bit, but that was really impressive to me! Mine is rather embarrassingly wired.