Date: Thu, 12 Nov 2009 12:44:10 -0600 From: "Sam Fourman Jr." <sfourman@gmail.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: freebsd-current@freebsd.org, Dan Nelson <dnelson@allantgroup.com>, Ivan Voras <ivoras@freebsd.org> Subject: Re: Help ZFS FreeBSD 8.0 RC2 Write performance issue Message-ID: <11167f520911121044l74744c30u5a4d9ca008ab863c@mail.gmail.com> In-Reply-To: <Pine.GSO.4.63.0911121147310.9126@muncher.cs.uoguelph.ca> References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> <hdf23m$b6n$1@ger.gmane.org> <20091111204903.GI89052@dan.emsphone.com> <11167f520911111326v13bb442bt36e853afbecdf834@mail.gmail.com> <9bbcef730911111352t12188bdajbca71bcf35a5beb5@mail.gmail.com> <Pine.GSO.4.63.0911121147310.9126@muncher.cs.uoguelph.ca>
index | next in thread | previous in thread | raw e-mail
On Thu, Nov 12, 2009 at 11:02 AM, Rick Macklem <rmacklem@uoguelph.ca> wrote: > > > On Wed, 11 Nov 2009, Ivan Voras wrote: > >> >> I think NFS uses sync disk IO access by default, this may be your >> problem if you are write-heavy. Try setting vfs.nfsrv.async to 1 to >> see if this is the cause of your problems. > > Just fyi, I took a quick look and I don't think this will be a good > idea for NFSv3. (It allows the server to cheat for NFSv2 and avoid > synchronous writes, which was contrary to the standard, but became > fashionable for performance reasons, before NFSv3 came out.) > > For NFSv3, the writes are normally done asynchronously, followed > by a Commit RPC to force them to disk, done by the client when it > is flushing its buffer cache. > > When you set this sysctl, the NFSv3 server (sys/nfsserver, not the > experimental one), all it does is reply to the write RPC that it > has already been committed. This may have two effects, depending > upon the client: > 1 - The client may then choose to not bother with a Commit RPC. > --> This shouldn't help performance much, because the data > will normally have made to disk by now. > *** This might be an interesting experiment to try on a ZFS server > though, since if it does make a significant difference, it > suggests that ZFS does a lot of work figuring out that the > blocks are already on stable storage or something like that. > (ie. It might hint at where to look for a ZFS related perf. > problem.) > OR > 2 - Nothing, because the client doesn't notice it doesn't need to > commit it and does the Commit RPC anyhow. > > Also, it is potentially dangerous, since if the server crashes after > the client has done the write, but before the server has written it > to disk, the data may be lost. (ie. The client might have flushed the > dirty blocks out of its buffer cache, because it didn't think it needed > to do a Commit RPC.) > > rick I guess I am confused a bit. Why is it that sftp has better write speed than NFS? and from what I am hearing there isn't a good way to fox it? what about if I try and tweak the nfs connection paramaters. all of these tests were done with whatever default is. anyone have any Ideas on better client connection parameters? Sam Fourman Jr.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?11167f520911121044l74744c30u5a4d9ca008ab863c>