From owner-freebsd-current@FreeBSD.ORG Tue Apr 27 14:41:46 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2DC81065672; Tue, 27 Apr 2010 14:41:46 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id 0CC1F8FC19; Tue, 27 Apr 2010 14:41:45 +0000 (UTC) Received: by ewy24 with SMTP id 24so4022603ewy.33 for ; Tue, 27 Apr 2010 07:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=CnFhT2EW2zhgVncf+lxqj47R4Wi90gKpDctsVM23k00=; b=HrPE5Jc726ixDcqg1mnLYWhXVGO5vesG5C9IhAa8+kJQdICk3zG7YqXbwYsP6lqvcp DXV8oxfwh1o1SqOcIXXHqSCXgF35TIv7n7c8kQzBQlbwWglSoeXMc97zKoDBOW8xs3Uy LxiCwsU/n1fsprVv19uHfVKXeFc2LdxdxBhRk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=Lw0hXWLIfD6Y6hNF5RjrdaQ9eq4xdVKSN7+Qcs64mOfy3ANFgOn1Us8YX2CNkLa+SV MA9PqXMy3rKysXhho5xEtDKwzLeXkL1b2FFdpj1V8UZHiBq82V2Wu9ptQhN0jaOvpGDT sn1kbh5iKluGZg7HTVAQDpE3Cm9uo7AS6Sjmk= Received: by 10.102.216.24 with SMTP id o24mr3225033mug.67.1272379301653; Tue, 27 Apr 2010 07:41:41 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id e10sm22401360muf.8.2010.04.27.07.41.40 (version=SSLv3 cipher=RC4-MD5); Tue, 27 Apr 2010 07:41:41 -0700 (PDT) Sender: Alexander Motin Message-ID: <4BD6F797.5090205@FreeBSD.org> Date: Tue, 27 Apr 2010 17:41:27 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <4BD06BD9.6030401@FreeBSD.org> <4BD099E6.6000402@FreeBSD.org> <4BD0A689.8000508@thekeelecentre.com> <4BD0ACD2.3040805@FreeBSD.org> <86och53tpl.fsf@ds4.des.no> <4BD6EDD6.8010403@FreeBSD.org> <86fx2h3rr6.fsf@ds4.des.no> In-Reply-To: <86fx2h3rr6.fsf@ds4.des.no> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Maxim Sobolev , FreeBSD-Current , Richard Tector , freebsd-geom@FreeBSD.org Subject: Re: Switchover to CAM ATA? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Tue, 27 Apr 2010 14:41:47 -0000 Dag-Erling Smørgrav wrote: > Alexander Motin writes: >> Dag-Erling Smørgrav writes: >>> Most pseudo-raid kit has nifty features like checksum offloading, >>> composite writes etc. which can improve performance considerably. You >>> can't access those from GEOM. >> Have you ever seen them documented? > > ISTR I got the info from sos@ at some point. I have several Promise > cards lying around and was working onm RAID5 offloading, but I stopped > when ZFS became usable. Out Promise driver doesn't even have ATAPI support, not speaking about more advanced features. >> Does the need to specifically handle dozens of incompatible >> implementations with limited resources worth those (probably not >> major) benefits? > > The details probably vary from controller to controller, but the > capabilities are pretty much the same: perform the same write operation > to several disks at once, split a write operation across several disks, > compute and write parity. > > IIRC, composite writes are already supported but not used. I haven't dug really deep into current ataraid(4), but AFAIK it is all done in software. At least there is no any offloading support on the controller drivers level. None of ata(4) drivers do anything except executing one ATA command at a time. Looking that most of modern controllers threat every SATA channel independently, with separate request queue, status, interrupts and so on, I can hardly imagine how could they partially accelerate such things. The only alike example I know is a parity calculation accelerator in Marvel ARM SoCs. But it is completely separate device, unrelated to SATA controller. Any URLs? -- Alexander Motin