From owner-freebsd-current@FreeBSD.ORG Thu Mar 28 16:02:57 2013 Return-Path: Delivered-To: freebsd-current@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 D252BE79 for ; Thu, 28 Mar 2013 16:02:57 +0000 (UTC) (envelope-from mj@feral.com) Received: from virtual.feral.com (virtual.feral.com [216.224.170.83]) by mx1.freebsd.org (Postfix) with ESMTP id 9EDD315E for ; Thu, 28 Mar 2013 16:02:57 +0000 (UTC) Received: from [192.168.135.7] (76-14-49-207.sf-cable.astound.net [76.14.49.207]) by virtual.feral.com (8.14.4/8.14.4) with ESMTP id r2SG1t9F019043 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 28 Mar 2013 09:01:56 -0700 Message-ID: <51546975.3050103@feral.com> Date: Thu, 28 Mar 2013 09:01:57 -0700 From: Matthew Jacob User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Any objections/comments on axing out old ATA stack? References: <51536306.5030907@FreeBSD.org> <51536EFD.4060202@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (virtual.feral.com [216.224.170.83]); Thu, 28 Mar 2013 09:01:56 -0700 (PDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 16:02:57 -0000 On 3/28/2013 8:27 AM, Scott Long wrote: > On Mar 27, 2013, at 4:13 PM, Matthew Jacob wrote: > >> On 3/27/2013 2:22 PM, 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? >>> >> Some people have expressed performance concerns about ATA_CAM. I have not validated those concerns. Does anyone know of any? > The albatross of "CAM is slow" comes up over and over, but I never see any data to support the claims. So here's an anecdote of my own. > Yes, I understand that. Like I said, they didn't give me details about it, but it did seem like some data they were throwing around showed a falloff that was significant. However, they have a number of other differences which, for whatever reason, may not have played well. I'm waiting for more info on it.