Date: Sun, 23 Nov 2008 01:47:58 +0100 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-geom@freebsd.org Subject: Re: GGatec Performance Message-ID: <gga983$n94$1@ger.gmane.org> In-Reply-To: <44f12db00811211633w52c7b600s20e13f4255a82948@mail.gmail.com> References: <44f12db00811211633w52c7b600s20e13f4255a82948@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?gga983$n94$1>