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[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
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".
Regards.
Victor.
--
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-current
mailing list