GGatec Performance

Ivan Voras ivoras at freebsd.org
Sat Nov 22 16:48:18 PST 2008


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 the
> share.  If I do a newfs on the 2nd partition, mount it, and create a large
> 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 writing
> over the network.  If I were to, instead, do the same as above except dont
> bother mounting and creating a large file and just sharing out the device 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 will
> barely hit 5MB/s!  I see two possible solutions here that I hope someone 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).


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20081123/bbef3a75/signature.pgp


More information about the freebsd-geom mailing list