From: Peter Staubach <staubach@redhat.com>
To: Michael <mikore.li@gmail.com>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>, nfs@lists.sourceforge.net
Subject: Re: can anyone explain this state?
Date: Wed, 17 Aug 2005 10:40:33 -0400 [thread overview]
Message-ID: <43034C61.6010402@redhat.com> (raw)
In-Reply-To: <bc57270905081706392d1706aa@mail.gmail.com>
Michael wrote:
>
>Thanks for your feedback!
>
>Yes, I know it should be cache related, but you can see it took me
>more than 1 minute at the first time copy 100Mfile from nfs server,
>but suddenly the second time took 4 second.
>How can the cache result to this? NFS client cache ability? ok, if it
>is, that means NFS client could cache at least 90M data of 100M, then,
>how to explain the last 2 copies? with rsize=8k,first time copy 100M
>file took 9 seconds, but the second time took 7 seconds, if cache work
>as great as rsize=1k, why not the second time copy take less than 1
>second?
>
The cache on the client can definitely account for the first two times.
As for the second two, I don't know. Was the client, network, and server
otherwise completely quiescent? What is the configuration of the client?
Can it safely cache 100MB without loosing any data because older data needed
to be pushed out to make room for newer data? I expect so, but it would be
good to check.
What does the network traffic look like between the client and the server
during these cp commands? That might tell you more about what is going on
in your environment.
Thanx...
ps
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2005-08-17 14:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-17 11:13 can anyone explain this state? Michael
2005-08-17 12:02 ` Trond Myklebust
2005-08-17 12:26 ` Peter Staubach
2005-08-17 12:31 ` Peter Staubach
2005-08-17 12:39 ` Trond Myklebust
2005-08-17 13:39 ` Michael
2005-08-17 14:40 ` Peter Staubach [this message]
2005-08-17 14:50 ` Michael
2005-08-17 23:51 ` Greg Banks
2005-08-18 0:18 ` Trond Myklebust
2005-08-18 13:41 ` Michael
2005-08-18 14:02 ` Trond Myklebust
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=43034C61.6010402@redhat.com \
--to=staubach@redhat.com \
--cc=mikore.li@gmail.com \
--cc=nfs@lists.sourceforge.net \
--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.