libata, NCQ & non-zero offset

[drewvonadasmith]

I'm using a RHEL5/Centos5 variant.

After struggling with various 2 TB hard drive failures, I started using the Hitachi Deskstar and Ultrastar models, and had none of the earlier green feature related or QA problems I had with all others. However, I began seeing SATA controller freezing under heavy loads, like large rsync mirror operations. My controller is an on-board ICH7R running in AHCI mode. The symptoms are that the drive goes off line and begins to log thousands of SMART errors for Spin-Up Retries. Analysis confirms that the drive is 100% OK after, except for the huge SMART log. This happens on two servers, and multiple drives. Changing the drive to 1.5 Gbps interface speed reduces the problem greatly but does not eliminate it.

I'm working with Hitachi engineering on this, and their only theory is that it has to do with "non-zero buffer offset". Apparently this is a feature of NCQ to receive data out of sequence, and Hitachi says that ICH7R is supports NCQ but not this feature. I am told that BIOS is supposed to filter offending commands but BIOS vendors sometimes err. An alternate is to filter them at the driver, which I believe is libata.

Does anyone know anything about this issue? Where might be a good place to make a query about this, with regards to libata? I've contacted the motherboard vendor about the BIOS issue, but I'd like to look into libata also.

Thanks!
Drew

[Segfault]

I'd say get a better controller, don't send a boy to do a man's job.

[drewvonadasmith]

The controller is on the MB and few slots are available. Intel ICH7R is pretty standard; what do you suggest as a "better controller"?

I'd say get a better controller, don't send a boy to do a man's job.