Date: Sun, 31 Mar 2013 15:02:09 -0600 From: Scott Long <scottl@samsco.org> To: Victor Balada Diaz <victor@bsdes.net>, Alexander Motin <mav@freebsd.org> Cc: "freebsd-current@freebsd.org FreeBSD" <freebsd-current@freebsd.org>, "freebsd-stable@freebsd.org Stable" <freebsd-stable@freebsd.org> Subject: Re: Any objections/comments on axing out old ATA stack? Message-ID: <C699FE76-B456-49C7-8D3A-DD54F98DAFC1@samsco.org> In-Reply-To: <20130331130409.GO3178@equilibrium.bsdes.net> References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >>=20 >> Since FreeBSD 9.0 we are successfully running on the new CAM-based = ATA=20 >> stack, using only some controller drivers of old ata(4) by having=20 >> `options ATA_CAM` enabled in all kernels by default. I have a wish to=20= >> drop non-ATA_CAM ata(4) code, unused since that time from the head=20 >> branch to allow further ATA code cleanup. >>=20 >> Does any one here still uses legacy ATA stack (kernel explicitly = built=20 >> without `options ATA_CAM`) for some reason, for example as workaround=20= >> for some regression? Does anybody have good ideas why we should not = drop=20 >> it now? >=20 > Hello, >=20 > 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. >=20 > I reported some of the problems on 8.2[1] but the problem existed with = 8.3. >=20 > 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. >=20 > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C699FE76-B456-49C7-8D3A-DD54F98DAFC1>