From: "Roger Heflin" <rheflin@atipa.com>
To: "'jehan.procaccia'" <jehan.procaccia@int-evry.fr>,
"'Olaf Kirch'" <okir@suse.de>
Cc: <nfs@lists.sourceforge.net>, <trond.myklebust@fys.uio.no>,
<mci-unix@int-evry.fr>
Subject: RE: async vs. sync
Date: Mon, 22 Nov 2004 12:06:42 -0600 [thread overview]
Message-ID: <EXCHG2003BjbUf9Sp2W000071ca@EXCHG2003.microtech-ks.com> (raw)
In-Reply-To: <41A2280B.1010005@int-evry.fr>
This might be the issue, (and someone correct this if I am incorrect),
I know I ran into it a couple of years ago, and it is not the easiest
to understand exactly what is actually going on.
There are 2 places where you can put sync and async, one is the exports
and one is on the mount command. They are different.
You want sync on the exports, this will allow a client to survive without
data loss if the server reboots. You want async on the client mount end
and
this will generally give you the speed. With async on the client end
the client is keeping track of what is outstanding if the server crashes,
so you won't lose data. With async on both ends the server tells one that
the data is safe when it is not, and if the server crashes the client things
that the data was safe when it really was not.
If you put sync in both locations then your NFS disk is fully synced and
the application won't even start another write until the last one is
confirmed
finished and on the actual disk. With async on the client end the next
write
will start before the client has received an ack from the server, and this
will
be reasonably fast.
So basically:
exports mount
sync sync -> really safe and really slow
sync async -> Safe and fast
async either -> unsafe and fast.
Running async exports and async mount did not appear (under my testing) to
be faster under a sustained load than did sync exports and async mount.
When
the initial test was started async/async was faster but that quick changed
once
the buffer cache filled up.
Roger
> -----Original Message-----
> From: nfs-admin@lists.sourceforge.net
> [mailto:nfs-admin@lists.sourceforge.net] On Behalf Of jehan.procaccia
> Sent: Monday, November 22, 2004 11:55 AM
> To: Olaf Kirch
> Cc: nfs@lists.sourceforge.net; trond.myklebust@fys.uio.no;
> mci-unix@int-evry.fr
> Subject: Re: [NFS] async vs. sync
>
> Olaf Kirch wrote:
>
> >On Tue, Nov 16, 2004 at 10:48:12AM -0800, Lever, Charles wrote:
> >
> >
> >>i'm just looking for clarification so i can provide a good
> explanation
> >>in the Linux NFS FAQ about the evils of using "async." i'll cruise
> >>through the server code.
> >>
> >>
> >
> >Just about the only reason for async I can think of is if
> you have an
> >incoming data stream you need to write at a constant rate
> (think of a
> >diskless set top box writing an mpeg2 stream)
> >
> >Olaf
> >
> >
> OK, but using sync at my site is really really slow ...
> compare to async ! here's a detailed (options printed)
> demonstration for an untar operation that takes 13 minutes in
> async mode and only 14 secondes in sync mode !!
>
> 1) Export in sync mode
> NFS server (RedHat ES3 kernel 2.4.21-4.ELsmp) options for
> that export:
> $ cat /proc/fs/nfs/exports | grep arvouin
> /p2v5f1 arvouin.int-evry.fr(rw,no_root_squash,sync,wdelay,acl) #
> 157.159.21.55
> $ cat /var/lib/nfs/xtab | grep arvouin
> /p2v5f1
> arvouin.int-evry.fr(rw,sync,wdelay,hide,nocrossmnt,secure,no_r
oot_squash,no_all_squash,subtree_check,secure_locks,acl,mapping=identity,ano
nuid=-2,anongid=-2)
>
> Client running Fedora Core 2, kernel 2.6.8-1.521
> [root@arvouin /mnt/cobra3/mci/test/Test-sync] $cat /proc/mounts
> cobra3:/p2v5f1 /mnt/cobra3 nfs
> rw,v3,rsize=8192,wsize=8192,hard,tcp,lock,addr=cobra3 0 0
> $time tar xvfz /usr/src/redhat/SOURCES/httpd-2.0.51.tar.gz
> real 13m3.686s
> user 0m1.055s
> sys 0m4.354s
>
> 2) Export in async mode:
> Same NFS server, options for that export:
> $ cat /proc/fs/nfs/exports | grep arvouin
> /p2v5f1 arvouin.int-evry.fr(rw,no_root_squash,async,wdelay,acl) #
> 157.159.21.55
> $ cat /var/lib/nfs/xtab | grep arvouin
> /p2v5f2
> arvouin.int-evry.fr(rw,async,wdelay,hide,nocrossmnt,secure,no_
root_squash,no_all_squash,subtree_check,secure_locks,acl,mapping=identity,an
onuid=-2,anongid=-2)
>
> Same client running Fedora Core 2, kernel 2.6.8-1.521
> cobra3:/p2v5f1 /mnt/cobra3 nfs
> rw,v3,rsize=8192,wsize=8192,hard,tcp,lock,addr=cobra3 0 0
> [root@arvouin /mnt/cobra3/mci/test/Test-sync] $time tar xvfz
> /usr/src/redhat/SOURCES/httpd-2.0.51.tar.gz
> real 0m14.802s
> user 0m0.867s
> sys 0m2.886s
>
> My users won't accept the sync performances ! . I have no
> choice, but is running in async mode is really evil as you
> mentioned it ? is there a way to have better performances in
> sync in my case ? As anyone had the same gap in performance
> as me ( here 55 times longer in sync mode !) ?
>
> Thanks.
>
>
> -------------------------------------------------------
> 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
>
-------------------------------------------------------
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
next prev parent reply other threads:[~2004-11-22 18:07 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-16 18:48 async vs. sync Lever, Charles
2004-11-22 15:36 ` Olaf Kirch
2004-11-22 17:55 ` jehan.procaccia
2004-11-22 18:06 ` Roger Heflin [this message]
2004-11-22 18:46 ` jehan.procaccia
2004-11-22 19:10 ` Roger Heflin
2004-11-22 21:44 ` jehan procaccia
2004-11-22 21:52 ` jehan procaccia
2004-11-22 22:20 ` Trond Myklebust
2004-11-22 22:57 ` jehan procaccia
2004-11-23 9:50 ` jehan procaccia
2004-11-23 14:57 ` J. Bruce Fields
2004-11-22 18:08 ` Trond Myklebust
2004-11-22 18:57 ` jehan.procaccia
2004-11-22 19:05 ` Roger Heflin
2004-11-22 20:14 ` Trond Myklebust
2004-11-22 21:04 ` Paul Cunningham
2004-11-22 21:14 ` Trond Myklebust
2004-11-22 22:07 ` Paul Cunningham
2004-11-22 22:26 ` Trond Myklebust
2004-11-22 22:34 ` Configuring NFS service for speed - " Neil Brown
2004-11-22 23:36 ` jehan procaccia
-- strict thread matches above, loose matches on Subject: below --
2004-11-24 19:05 Lever, Charles
2004-11-23 16:36 Lever, Charles
2004-11-23 18:16 ` Dan Stromberg
2004-11-23 14:30 Lever, Charles
2004-11-23 21:46 ` jehan procaccia
2004-11-24 18:45 ` jehan.procaccia
2004-11-24 22:24 ` Neil Brown
2004-11-24 23:14 ` jehan procaccia
2004-11-24 23:34 ` Neil Brown
2004-11-24 22:09 ` Neil Brown
[not found] ` <Pine.GSO.4.53.0412010900500.5486@int1.cdc.noaa.gov>
2004-12-01 17:27 ` jehan.procaccia
2004-11-23 3:53 Lever, Charles
2004-11-23 16:33 ` Dan Stromberg
2004-11-22 22:14 Lever, Charles
[not found] <20041122214605.8E2B31D0FE1@sc8-sf-uberspam1.sourceforge.net>
2004-11-22 21:57 ` Joshua Baker-LePain
2004-11-22 21:50 Lever, Charles
2004-11-22 22:06 ` jehan procaccia
2004-11-23 1:09 ` Dan Stromberg
2004-11-22 19:02 Lever, Charles
2004-11-22 21:25 ` jehan procaccia
2004-11-22 21:45 ` Nicolas.Kowalski
2004-11-22 23:51 ` jehan procaccia
2004-11-22 18:31 Lever, Charles
2004-11-16 18:45 Lever, Charles
2004-11-16 16:15 Lever, Charles
2004-11-16 16:32 ` Trond Myklebust
2004-11-16 17:18 ` jehan.procaccia
2004-11-16 18:08 ` Trond Myklebust
[not found] <482A3FA0050D21419C269D13989C61130435E530@lavender-fe.eng.netapp.com>
2004-07-27 15:07 ` Bernd Schubert
2004-07-26 23:05 John Roberts
[not found] <482A3FA0050D21419C269D13989C61130435E523@lavender-fe.eng.netapp.com>
2004-07-26 21:28 ` Bernd Schubert
[not found] <482A3FA0050D21419C269D13989C61130435E51E@lavender-fe.eng.netapp.com>
2004-07-26 17:05 ` Bernd Schubert
2004-07-26 19:47 ` Jan Bruvoll
2004-07-26 22:06 ` Bernd Schubert
2004-07-27 12:00 ` Jan Bruvoll
2004-07-27 13:00 ` Bernd Schubert
2004-07-27 13:56 ` raven
2004-07-27 14:04 ` Jan Bruvoll
2004-07-27 14:11 ` Jan Bruvoll
2004-07-28 8:56 ` Olaf Kirch
2004-07-28 12:35 ` Bernd Schubert
2004-07-28 12:49 ` Olaf Kirch
2004-07-23 16:20 Linux NFS writes to Solaris very, very slow John Roberts
2004-07-26 15:17 ` async vs. sync Bernd Schubert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=EXCHG2003BjbUf9Sp2W000071ca@EXCHG2003.microtech-ks.com \
--to=rheflin@atipa.com \
--cc=jehan.procaccia@int-evry.fr \
--cc=mci-unix@int-evry.fr \
--cc=nfs@lists.sourceforge.net \
--cc=okir@suse.de \
--cc=trond.myklebust@fys.uio.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.