Linux NFS development
 help / color / mirror / Atom feed
From: jehan procaccia <jehan.procaccia@int-evry.fr>
To: jehan procaccia <jehan.procaccia@int-evry.fr>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>,
	Roger Heflin <rheflin@atipa.com>, Olaf Kirch <okir@suse.de>,
	nfs@lists.sourceforge.net, mci-unix@int-evry.fr
Subject: Re: async vs. sync
Date: Tue, 23 Nov 2004 10:50:55 +0100	[thread overview]
Message-ID: <41A307FF.3080300@int-evry.fr> (raw)
In-Reply-To: <41A26EF1.8040404@int-evry.fr>

I found something interesting ! If I export an internal scsi disk of my=20
NFS server (/home) I get good performances,  My problem is with exports=20
from the Dell/EMC Storage Processor , I will open a ticket about that on=20
the hotline ...

Nfs servor exporting an Internal scsi disk in sync mode
$ cat /var/lib/nfs/xtab
/home  =20
arvouin.int-evry.fr(rw,sync,no_wdelay,hide,nocrossmnt,secure,no_root_squa=
sh,no_all_squash,subtree_check,secure_locks,no_acl,mapping=3Didentity,ano=
nuid=3D-2,anongid=3D-2)

Client mount in sync an NFS export in sync also !:
cobra3:/home /mnt/cobra3home nfs=20
rw,sync,v3,rsize=3D8192,wsize=3D8192,hard,tcp,lock,addr=3Dcobra3 0 0
[root@arvouin /mnt/cobra3home/Nfs-test]
$time tar xvfz /usr/src/redhat/SOURCES/httpd-2.0.51.tar.gz
real    0m27.719s
user    0m1.002s
sys     0m4.296s

[root@arvouin /mnt/cobra3home/Nfs-test]
$./test2.sh
Test without directory sync after file creation
=20
real    0m0.568s
user    0m0.031s
sys     0m0.114s
Test2 with directory sync after file creation
=20
real    0m0.904s
user    0m0.094s
sys     0m0.266s


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 that AX100=20
storage Processor (raid5, spare disk, double fiber attachement, UPS)=20
allows me to use async export mode in such a case ?

thanks .

jehan procaccia wrote:

> Trond Myklebust wrote:
>
>> m=E5 den 22.11.2004 Klokka 22:52 (+0100) skreiv jehan procaccia:
>> =20
>>
>>>> [root@arvouin tmp]# mount cobra3:/p2v5f1 -o=20
>>>> async,wsize=3D32768,rsize=3D32768,soft /mnt/cobra3
>>>> [root@arvouin /mnt/cobra3/mci/test/Test-sync]
>>>> $time tar xvfz /usr/src/redhat/SOURCES/httpd-2.0.51.tar.gz
>>>>
>>>> sorry I don't want to wait more than 10 minutes to send that mail,=20
>>>> but again seeing the files apperaing very slowly on the tty it=20
>>>> seems not to be the solution :-( .
>>>>    =20
>>>
>>
>> The following script may help you understand why things are slower in
>> the case of "async" on an untar. It basically just creates a bunch of
>> files: in the first test it does not sync the directory to disk after
>> each file creation, in the second case it does. The test does no
>> reads/writes to the file.
>>
>> Run it on the server and you will see  a clear difference in time
>> between test1 and test2. Run it on the client, and there should be
>> little difference between test1 and test2 (but there will be a heavy
>> dependency on the "async" vs "sync" export flag on the server).
>> =20
>>
> These prediction are perfect, this is exaclty  what happened:
> I reduce the loop from 1000 to 100, it was too long on the client in=20
> sync mode ....
>
> [root@cobra3 /p2v5f1/mci/test/Test-sync]
> $ ./test2.sh
> Test without directory sync after file creation
>
> real    0m0.037s
> user    0m0.010s
> sys     0m0.000s
> Test2 with directory sync after file creation
>
> real    0m6.040s
> user    0m0.000s
> sys     0m0.000s
>
> NFS client, while server export in sync mode
> cobra3:/p2v5f1 /mnt/cobra3 nfs=20
> rw,v3,rsize=3D8192,wsize=3D8192,soft,tcp,lock,addr=3Dcobra3 0 0
> $./test2.sh
> Test without directory sync after file creation
>
> real    0m31.144s
> user    0m0.042s
> sys     0m0.373s
> Test2 with directory sync after file creation
>
> real    0m49.030s
> user    0m0.073s
> sys     0m0.694s
>
> Now NFS server exports in async mode to the client, performances are=20
> far better , even better than direclty on the server when forcing a=20
> sync call after every creation !
> $./test2.sh
> Test without directory sync after file creation
>
> real    0m0.446s
> user    0m0.026s
> sys     0m0.078s
> Test2 with directory sync after file creation
>
> real    0m0.785s
> user    0m0.076s
> sys     0m0.305s
>
> Hopefully I'll try to capture traffic next wednesday when I'll be back=20
> at work ..
>
> Thanks.
>
>> NFSv3 mandates that all directory-related operations should behave as =
in
>> test 2. Only writes to ordinary files may be cached by the server, and
>> when the client sends a COMMIT request, the server should do an fsync(=
)
>> on that file.
>>
>> Cheers,
>>  Trond
>> =20
>>
>
>
>
> -------------------------------------------------------
> 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.=20
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> NFS maillist  -  NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nf
> s




-------------------------------------------------------
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

  reply	other threads:[~2004-11-23  9:51 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
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 [this message]
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=41A307FF.3080300@int-evry.fr \
    --to=jehan.procaccia@int-evry.fr \
    --cc=mci-unix@int-evry.fr \
    --cc=nfs@lists.sourceforge.net \
    --cc=okir@suse.de \
    --cc=rheflin@atipa.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox