From owner-freebsd-geom@FreeBSD.ORG Sun Nov 23 00:48:18 2008 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 660151065677 for ; Sun, 23 Nov 2008 00:48:18 +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 DDE958FC1D for ; Sun, 23 Nov 2008 00:48:17 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1L4392-0008AC-27 for freebsd-geom@freebsd.org; Sun, 23 Nov 2008 00:48:12 +0000 Received: from 93-138-21-34.adsl.net.t-com.hr ([93.138.21.34]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Nov 2008 00:48:12 +0000 Received: from ivoras by 93-138-21-34.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Nov 2008 00:48:12 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Sun, 23 Nov 2008 01:47:58 +0100 Lines: 67 Message-ID: References: <44f12db00811211633w52c7b600s20e13f4255a82948@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig499FA8DC023DBB22F93E4234" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 93-138-21-34.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) In-Reply-To: <44f12db00811211633w52c7b600s20e13f4255a82948@mail.gmail.com> X-Enigmail-Version: 0.95.7 Sender: news Subject: Re: GGatec Performance 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: Sun, 23 Nov 2008 00:48:18 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig499FA8DC023DBB22F93E4234 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Joseph Yeager wrote: > I've been messing around ggatec lately and have noticed that I see= a > drastic decrease in write speed when I share out devices as opposed to > files. For instance, lets say Server2 is trying to share a drive to > Server1. Server2 has 2 partitions, one for the OS and the other for th= e > share. If I do a newfs on the 2nd partition, mount it, and create a la= rge > file on the mount I can expect a slowdown of about 5-10MB/s compared to= > native speed (the drive writes at about 50-55MB/s natively) when writin= g > over the network. If I were to, instead, do the same as above except d= ont > bother mounting and creating a large file and just sharing out the devi= ce I > see a major slowdown. Where I can easily get 40-50MB/s with the former= > method, the latter method has trouble hitting 15MB/s. Sometimes it wil= l > barely hit 5MB/s! I see two possible solutions here that I hope someon= e can > help me with: Raw drives in FreeBSD are always accessed synchronously - there is no block-level caching (and no block devices). A big file located on a usual file system with default settings will be practically always cached both for reading and for writing. Among other things, this means that a power failure will almost certainly result in a corrupted file system that is stored within that file (but the "outer" file system on the physical drive will survive). You can test this theory by mounting the file system which hosts your big file with a file system inside it as synchronous (-o sync) - you should achieve about the same low performance as accessing the raw drive (there will still be read-caching which will influence your performance).= There is nothing you can do to improve this on the software level. The biggest improvement for this particular problem would be to use a faster network - so the network drive is accessed with minimal latency and mimics the performance of local drives (see also: iSCSI performance, since it's effectively the same thing on a different protocol). --------------enig499FA8DC023DBB22F93E4234 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkoqD4ACgkQldnAQVacBcjNiQCgj4k5QIyKmP5mPgXUNpgj7vNi /IYAoNVDOAs306xkkgvibf0nqzUGvxsM =LXQn -----END PGP SIGNATURE----- --------------enig499FA8DC023DBB22F93E4234--