From owner-freebsd-geom@FreeBSD.ORG Mon Nov 6 12:05:17 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 40DB616A47E for ; Mon, 6 Nov 2006 12:05:17 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id B437B43D49 for ; Mon, 6 Nov 2006 12:05:15 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (aronkd@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id kA6C4GR9079704; Mon, 6 Nov 2006 13:04:21 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id kA6C4FXt079703; Mon, 6 Nov 2006 13:04:15 +0100 (CET) (envelope-from olli) Date: Mon, 6 Nov 2006 13:04:15 +0100 (CET) Message-Id: <200611061204.kA6C4FXt079703@lurza.secnetix.de> From: Oliver Fromme To: freebsd-geom@FreeBSD.ORG, Oles Hnatkevych In-Reply-To: <961295086.20061105000919@able.com.ua> X-Newsgroups: list.freebsd-geom User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 06 Nov 2006 13:04:21 +0100 (CET) Cc: Subject: Re: geom stripe perfomance question X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-geom@FreeBSD.ORG, Oles Hnatkevych 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 12:05:17 -0000 Oles Hnatkevych wrote: > I wonder why geom stripe works much worse than the separate disks that > constitute stripe. It depends on your workload (or your benchmark). > I have a stripe from two disks. Disks are on separate ATA channels. > [...] > Stripesize: 262144 > [...] > Now let's read one of them and stripe. > > root# dd if=/dev/ad1 of=/dev/null bs=1m count=1000 > 1048576000 bytes transferred in 14.579483 secs (71921343 bytes/sec) > > root# dd if=/dev/stripe/bigdata of=/dev/null bs=1m count=1000 > 1048576000 bytes transferred in 15.882796 secs (66019610 bytes/sec) > > What I would expect is doubling the speed of transfer, not > slowing down. Am I wrong? Or is geom_stripe inefficient? > I tried to do the same with gvinum/stripe - the read > speed was degraded too. And with gmirror depending on slice size speed > was degraded differently. 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. Best regards Oliver PS: [*] It could be argued that the kernel could prefetch the next 256 KB from the other disk, so both disks are kept busy for best throughput. The problem with that is that the kernel doesn't know that the next 256 KB will be needed, so it doesn't know whether it makes sense to prefetch them or not. dd has no way to tell the kernel about its usage pattern (it would require an API similar to madvise(2)). -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "It combines all the worst aspects of C and Lisp: a billion different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript." -- Jamie Zawinski, when asked: "What's wrong with perl?"