Re: Any objections/comments on axing out old ATA stack?

On Mar 31, 2013, at 7:04 AM, Victor Balada Diaz <victor@bsdes.net> wrote:

> On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote:
>> Hi.
>> 
>> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA 
>> stack, using only some controller drivers of old ata(4) by having 
>> `options ATA_CAM` enabled in all kernels by default. I have a wish to 
>> drop non-ATA_CAM ata(4) code, unused since that time from the head 
>> branch to allow further ATA code cleanup.
>> 
>> Does any one here still uses legacy ATA stack (kernel explicitly built 
>> without `options ATA_CAM`) for some reason, for example as workaround 
>> for some regression? Does anybody have good ideas why we should not drop 
>> it now?
> 
> Hello,
> 
> At my previous job we had troubles with NCQ on some controllers. It caused
> failures and silent data corruption. As old ata code didn't use NCQ we just used
> it.
> 
> I reported some of the problems on 8.2[1] but the problem existed with 8.3.
> 
> I no longer have access to those systems, so i don't know if the problem
> still exists or have been fixed on newer versions.
> 
> Regards.
> Victor.

So what I hear you and Matthias saying, I believe, is that it should be easier to
force disks to fall back to non-NCQ mode, and/or have a more responsive
black-list for problematic controllers.  Would this help the situation?  It's hard to
justify holding back overall forward progress because of some bad controllers;
we do several Tbps off of AHCI controllers with NCQ enabled on FreeBSD 9.x,
enough to make up a sizable percentage of the internet's traffic, and we see no
problems.  How can we move forward but also take care of you guys with
problematic hardware?

Scott

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"