RE: NFS Help! Terrible performance with sync, fast performance with async

	Write back cache is a caching method in which modifications to
data in the cache aren't copied to the cache source until absolutely
needed. Write-back caching is available on many microprocessors,
including all Intel processors since the 80486. With these
microprocessors, data modifications (e.g., write operations) to data
stored in the L1 cache aren't copied to main memory until absolutely
necessary. In contrast, a write-through cache performs all write
operations in parallel -- data is written to main memory and the L1
cache simultaneously. 

	Write-back caching yields somewhat better performance than
write-through caching because it reduces the number of write operations
to main memory. With this performance improvement comes a slight risk
that data may be lost if the system crashes. 

	Let me know if you would like some more detail into this.

Thanks,
--Eric Gunnett

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Chris Wornell
Sent: Wednesday, November 22, 2006 10:07 PM
To: Discussion of Red Hat Enterprise Linux 3 (Taroon)
Subject: RE: NFS Help! Terrible performance with sync,fast performance
with async

After some more research, I found the culprit.  The write policy on the
RAID controller was set to "write through".  When I changed the policy
to "write back", I got the increase in performance I was looking for.

Can anyone give a dumbed-down explanation between write through and
write back. The information I found, even on wikipedia was too sparse
for me to get a firm grasp. I'm not completely clear on what the data
store is exactly (though I assume it would be the onboard RAM on the
RAID controller) and what cache lines are.

And my last question is after reading about NFSv3 more, I found that
async on NFSv3 appears to be a hybrid of what NFSv2 async and sync.  I
read that when an NFSv3 server has async enabled on a share, the server
will reply to the client that the data has been written, but the client
will still hold the data in it's cache until the server replies back
with a commit.  To me, this looks like the compromise I'm looking for in
getting the performance of async but the safety of sync.  Can anyone
comment on this?  How do I know this behavior is happening if I enable
async for a share?

Thanks for your help and happy holidays everyone!

Thanks,

Chris Wornell
Network Administrator, Information Technology
Peerless Systems Corporation
http://www.peerless.com
office: 310.727.5723
fax: 310.727.5715
mailto:cwornell-KWjJJj/cdYZWk0Htik3J/[email protected] 

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Stephen John
Smoogen
Sent: Tuesday, November 21, 2006 10:41 AM
To: Discussion of Red Hat Enterprise Linux 3 (Taroon)
Subject: Re: NFS Help! Terrible performance with sync,fast performance
with async

On 11/21/06, Stephen John Smoogen <[email protected]> wrote:

>
> To be honest, this may be a place where Linux is just going to suck.
> The NFS server stuff has a lot of issues to deal with.. and reading
> http://nfsworld.blogspot.com/ (which I am guessing is from Sun ) there
> are a lot of places where it hasnt been optimized.
>

-ENOCAFFEINE

http://nfsworld.blogspot.com/ is from someone who has worked on NFS
for a long time

http://blogs.sun.com/erickustarz/ is from someone at sun

http://nfs.sourceforge.net/

>From the faq..
Does your application open its files with the O_SYNC option? That will
force NFS Version 3 to behave exactly like (synchronous) NFS Version
2.

I think bonnie++ and cp do this unless told otherwise.. which could be
why they bog down without sync. If the mention in the nfsworld blog
are correct about file timeing.. this could also cause problems with
any Linux NFS v2/v3 server. It would be interesting what the iozone
comparisons between v2/v3/v4 would be.




-- 
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

--
Taroon-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/taroon-list

--
Taroon-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/taroon-list

--
Taroon-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/taroon-list