From: "Lever, Charles" <Charles.Lever@netapp.com>
Subject: RE: async vs. sync
Date: Tue, 23 Nov 2004 06:30:15 -0800
Message-ID: <482A3FA0050D21419C269D13989C611307CF4B56@lavender-fe.eng.netapp.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Cc: <nfs@lists.sourceforge.net>
To: "jehan procaccia" <jehan.procaccia@int-evry.fr>
Sender: nfs-admin@lists.sourceforge.net
Errors-To: nfs-admin@lists.sourceforge.net

> This is what I expect in term of performances . I will continue my=20
> requests on the DEll/EMC hotline , but maybe the security of=20
> that AX100=20
> storage Processor (raid5, spare disk, double fiber attachement, UPS)=20
> allows me to use async export mode in such a case ?

the "async" export option changes the behavior of the NFS server
daemons, not of the underlying local file system or storage subsystem.
the problem is that changes made by clients will remain in your NFS
server's memory and not get flushed onto permanent storage.

so, i really don't think the storage subsystem will have any effect on
the safety of your data before the data reaches permanent storage.  as
someone else pointed out earlier, the solution is to use battery-backed
main memory when using "async" (prestoserve for solaris?).

as trond said, if your users and backup facilities can tolerate the loss
of data during a crash, then it is perfectly fine to use "async."  most
don't, however.

btw, it is fairly well understood that RAID-5 and NFS servers don't mix
well.  RAID-5's weakest point is that it doesn't handle small random
writes very well, and that's exactly what is required of it when
handling NFS traffic that consists mostly of metadata changes (file
creates, deletes, and so on).  neil explained clearly how to make the
best use of a RAID-5 with NFS: do your local file system journaling
somewhere else.

when trying your workload locally on the NFS server, realize that there
are some optimizations that local file systems make, like caching and
coalescing metadata updates, that the NFS protocol does not allow.  this
affects especially workloads with lots of metadata change operations,
because the NFS protocol requires each metadata update to reside on
permanent storage before the NFS server replies to the client,
effectively serializing the workload with storage activity.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs