From owner-freebsd-geom@FreeBSD.ORG Mon Nov 6 13:03:25 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 0F5D616A417 for ; Mon, 6 Nov 2006 13:03:25 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63A3143D75 for ; Mon, 6 Nov 2006 13:03:17 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from vader ([85.236.96.60]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.0.1) with ESMTP id md50003173330.msg for ; Mon, 06 Nov 2006 13:02:50 +0000 Message-ID: <01a401c701a3$dc106ef0$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: , "Oles Hnatkevych" References: <200611061204.kA6C4FXt079703@lurza.secnetix.de> Date: Mon, 6 Nov 2006 13:02:41 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Processed: multiplay.co.uk, Mon, 06 Nov 2006 13:02:50 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 85.236.96.60 X-Return-Path: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-geom@FreeBSD.ORG X-MDAV-Processed: multiplay.co.uk, Mon, 06 Nov 2006 13:02:50 +0000 Cc: 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 13:03:25 -0000 Oliver Fromme wrote: > I wonder why people always try to use dd for benchmarking. > It's bogus. dd is not for benchmarking. It works in a > sequential way, i.e. it first reads 256 KB (your stripe > size) from the first compontent, then 256 KB from the 2nd, > and so on. While it reads from one disk, the other one is > idle. So it is not surprising that you don't see a speed > increase (in fact, there's a small decrease because of > the seek time overhead when switching from on disk to > the other). [*] > > The performance of a stripe should be better when you use > applications that perform parallel I/O access. > > Your benchmark should be as close to your real-world app > as possible. If your real-world app is dd (or another one > that accesses big files sequentially without parallelism), > then you shouldn't use striping. Serving large files via FTP this would be just the test to benchmark so I'd say you argument is flawed in that it makes assumptions about the way files are accessed. In addition to this from my tests its only geom that performs so poorly, neither hardware RAID nore sofware RAID under suffers from such poor performance. If your argument where correct then they would all suffer but this is not the case. 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. Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk.