From owner-freebsd-stable@FreeBSD.ORG Mon Apr 1 13:14:24 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9464FE0C; Mon, 1 Apr 2013 13:14:24 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from equilibrium.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id 3648F296; Mon, 1 Apr 2013 13:14:23 +0000 (UTC) Received: by equilibrium.bsdes.net (Postfix, from userid 1001) id D0DD92283F; Mon, 1 Apr 2013 15:14:15 +0200 (CEST) Date: Mon, 1 Apr 2013 15:14:15 +0200 From: Victor Balada Diaz To: Scott Long Subject: Re: Any objections/comments on axing out old ATA stack? Message-ID: <20130401131415.GQ3178@equilibrium.bsdes.net> References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Alexander Motin , "freebsd-current@freebsd.org FreeBSD" , "freebsd-stable@freebsd.org Stable" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 13:14:24 -0000 On Sun, Mar 31, 2013 at 03:02:09PM -0600, Scott Long wrote: > > On Mar 31, 2013, at 7:04 AM, Victor Balada Diaz 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.