>> I took a look at using the smart tools as you suggested, but have now >> found that the disk in question is a RAID1 set on a DELL PERC 3/Di >> controller and smartctl does not appear to be the correct tool to >> access the SMART data for the individual disks. After a little >> research, I have found the aaccli tool and used it to get the following information:
> Sadly, that controller does not show you SMART attributes. This is one of > the biggest problems with the majority (but not all) of hardware RAID > controllers -- they give you no access to disk-level things like SMART. > FreeBSD has support for such (using CAM's pass(4)), but the driver has > to support/use it, *and* the card firmware has to support it. At present, > Areca, 3Ware, and Promise controllers support such; HighPoint might, but > I haven't confirmed it. Adaptec does not. > What you showed tells me nothing about SMART, other than the remote possibility > its basing some of its decisions on the "general SMART health status", > which means jack squat. I can explain why this is if need be, but it's > not related to the problem you're having. Thanks for this additional information. I hadn't understood that there was far more information behind the simple SMART ok/not ok reported by the PERC controller. > Either way, this is just one of many reasons to avoid hardware RAID controllers if given the choice. I have seen some mentions of using gvinum and/or gmirror to achieve the goals of protection from Single Point Of Failure with a single disk, which I believe is the reason that most people, myself included, have specified Hardware RAID in their servers. Is this what you mean by avoiding Hardware Raid? > I hope these are SCSI disks you're showing here, otherwise I'm not sure how the > controller is able to get the primary defect count of a SATA or SAS disk. So, > assuming the numbers shown are accurate, then yes, I don't think there's any > disk-level problem. Yes, they are SCSI disks. Not particularly relevant to this topic, but interesting: I would have thought that SAS would make the same information available as SCSI does, as it is a serial bus evolution of SCSI. Is this thinking incorrect? > I understand at this point you're running around with your arms in the air, > but you've already confirmed one thing: none of your other systems exhibit > this problem. If this is a production environment, step back a moment and > ask yourself: "just how much time is this worth?" It might be better to just > newfs the filesystem and be done with it, especially if this is a one-time-never-seen-before thing. >> I will wait and see if any other list member has any suggestions for >> me to try, but I am now leaning toward scrubbing the system. Oh well. > When you say scrubbing, are you referring to actually formatting/wiping the system, or are you referring to disk scrubbing? I meant reformatting and reinstalling, as a way to escape the issue without spending too much more time on it. I would of course like to understand the problem so as to know what to avoid in the future, but as you make the point above, time is money and it is rapidly approaching the point where it isn't worth any more effort. Thanks for all your help. Best Regards, Brendan Hart __________ Information from ESET NOD32 Antivirus, version of virus signature database 3571 (20081030) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"