Date: Fri, 30 Jan 2009 16:07:59 -0800 From: Brent Jones <brent@servuhome.net> To: Alfred Perlstein <alfred@freebsd.org> Cc: freebsd-performance@freebsd.org, freebsd-stable@freebsd.org Subject: Re: NFS writes calling FSYNC and ASYNC not consistent Message-ID: <ee9f3b480901301607o7dd31e09sa3f9ea8f07852e4@mail.gmail.com> In-Reply-To: <20090129230247.GF4375@elvis.mu.org> References: <ee9f3b480901281909r3ad1350cye45ab992c6c0a91c@mail.gmail.com> <20090129230247.GF4375@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 29, 2009 at 3:02 PM, Alfred Perlstein <alfred@freebsd.org> wrote:
> Apologies for being terse, in a hurry here.
>
> 1) -o async doesn't work with NFS, don't use that.
> 2) how big are the text versus binary files?
I tested with a 6MB text file, and a 2GB binary file. Text file would
go ~1MB/sec, issuing FSYNCs for every block write size (32KB default)
One thing I found that another FreeBSD user discovered exactly
explains my situation:
In bin/cp/utils.c (source) there is a check, if the file is less than
8MB or so, it uses mmap, if the file is larger, it will use write()
I modified the source and recompiled to -never- use mmap, only to use
write(), and my performance increased about 100 fold (from 1MB/sec
over NFS, to over 100MB/sec).
Changed line 143:
original:
fs->st_size <= 8 * 1048576) {
New:
fs->st_size <= 8 * 8) {
It will use mmap still if the file is larger than 64bytes (if it uses
bytes there, pretty sure it does).
But is much faster for files ~1KB to 8MB now.
Regards
> 3) how are you copying them over nfs?
>
> I suspect, (could be wrong of course) that the ascii files
> are a lot smaller than the binary files, so what's happening
> is that for binary files, the client is issuing write-behind
> async, however for ascii files its issuing the writes at
> close time which will force the sync flag.
>
> -Alfred
>
--
Brent Jones
brent@servuhome.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ee9f3b480901301607o7dd31e09sa3f9ea8f07852e4>