From owner-freebsd-hackers Thu Jun 17 1:55: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.oeno.com (ns.oeno.com [194.100.99.145]) by hub.freebsd.org (Postfix) with SMTP id 5BBDF150F5 for ; Thu, 17 Jun 1999 01:55:05 -0700 (PDT) (envelope-from will@ns.oeno.com) Received: (qmail 27329 invoked by uid 1001); 17 Jun 1999 08:55:04 -0000 To: crossd@cs.rpi.edu (David E. Cross) Cc: hackers@freebsd.org Subject: Re: vinum performance References: <199906170743.DAA16929@cs.rpi.edu> From: Ville-Pertti Keinonen Date: 17 Jun 1999 11:52:43 +0300 In-Reply-To: crossd@cs.rpi.edu's message of "17 Jun 1999 10:43:31 +0300" Message-ID: <86so7rqkdg.fsf@not.demophon.com> Lines: 26 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG crossd@cs.rpi.edu (David E. Cross) writes: > I have a drive that is rated at ~16 Meg/second, and indeed it delivers on the > order of 15+ Meg/second. If I use Vinum to create a concatinated device > of 2 such units performance drops to 2.5 Meg/sec. This seems like a > drastic drop in performance. Any ideas what I am doin incorrectly? You've accidentally striped subdisks on the same drive? ;--) Like Greg Lehey said, you haven't really provided enough details. The minimum info required would be: - Is this read or write performance? Many disks are shipped with write caching disabled, and write performance can be significantly worse than read performance. It shouldn't be quite *that* bad, though, I get better write performance with slower disks, write caching disabled and mirroring (with the default 3.2 vinum - which has debugging compiled in, look at the bss size...). - Are you testing through the filesystem? (How are you testing?) Maybe you're doing a dd test and accessing /dev/vinum/vol/* rather than /dev/vinum/rvol/*... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message