Any objections/comments on axing out old ATA stack?
Victor Balada Diaz
victor at bsdes.net
Mon Apr 1 13:14:24 UTC 2013
On Sun, Mar 31, 2013 at 03:02:09PM -0600, Scott Long wrote:
> On Mar 31, 2013, at 7:04 AM, Victor Balada Diaz <victor at 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 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?
Being able to configure quirks from loader.conf for disks AND controllers would be great
and is not hard to do. If you want i can do a patch in two weeks and send it to you. That
way it's easy to test disabling NCQ and/or other things in case of hitting a bug. Also
being able to modify the configuration without a kernel recompile would be a big
improvement because we could still use freebsd-update to keep systems updated.
Anyway, my comment was not against dropping old ata code, but more on the "comments on
regresssions on the new one".
La prueba más fehaciente de que existe vida inteligente en otros
planetas, es que no han intentado contactar con nosotros.
More information about the freebsd-stable