From owner-freebsd-geom@FreeBSD.ORG Mon Nov 6 15:12:35 2006 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E056116A6B8 for ; Mon, 6 Nov 2006 15:12:35 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0565543EC0 for ; Mon, 6 Nov 2006 15:11:34 +0000 (GMT) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gh610-0001gO-D6 for freebsd-geom@freebsd.org; Mon, 06 Nov 2006 16:03:58 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 06 Nov 2006 16:03:58 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 06 Nov 2006 16:03:58 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Mon, 06 Nov 2006 16:00:26 +0100 Lines: 9 Message-ID: References: <200611061204.kA6C4FXt079703@lurza.secnetix.de> <01a401c701a3$dc106ef0$b3db87d4@multiplay.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.4 (X11/20060625) In-Reply-To: <01a401c701a3$dc106ef0$b3db87d4@multiplay.co.uk> Sender: news Subject: Re: geom stripe perfomance question X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2006 15:12:36 -0000 Steven Hartland wrote: > It might be interesting from someone familiar with the geom > code to have a look at the linux RAID code to see if there > is any obvious reason why geom performs quite so poorly > under just about every test I've seen. One possible reason could be the 128K request size limit, but apparently it's something hard to get rid of.