From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Xin Zhao <uszhaoxin@gmail.com>
Cc: Matthew Wilcox <matthew@wil.cx>, Neil Brown <neilb@suse.de>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-fsdevel@vger.kernel.org
Subject: Re: Urgent help needed on an NFS question, please help!!!
Date: Thu, 10 Aug 2006 20:38:54 -0400 [thread overview]
Message-ID: <1155256734.5826.94.camel@localhost> (raw)
In-Reply-To: <4ae3c140608101528s69c50e2do554e0b908c2a1cf1@mail.gmail.com>
On Thu, 2006-08-10 at 18:28 -0400, Xin Zhao wrote:
> Also, delegations are about caching. That's true. It improve NFS
> performance because a client with a lease does not need to worry about
> server change and can manipulate files using local cache. But if
> speculative execution can achieve the same goal without incurring the
> cost of lease renewal and revoke, delegation becomes less useful.
What am I missing? AFAICS the main purpose of speculative execution
would appear to be to reduce the latency of syscall execution on
clients. That doesn't suffice to replace caching even by a long shot.
Delegations are all about _not_ sending commands to the server when you
don't need to. They make NFS scale to larger numbers of clients.
> So my question is essentially: if speculative execution is there, why
> do we still need delegation? Can delegation do anything better?
Speculative execution is where? I see one academic paper detailing a
couple of lab experiments, but no published code. Do you know of anyone
who has reproduced these results in real life environments?
I'm particularly curious to see how they resolved the requirement that
"...speculative state should never be visible to the user or any
external device.". The fact that they need to discuss having to roll
back operations like "mkdir", which create (very) user-visible state on
the server, is rather telling...
Trond
next prev parent reply other threads:[~2006-08-11 0:39 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-10 5:04 Urgent help needed on an NFS question, please help!!! Xin Zhao
2006-08-10 5:11 ` Neil Brown
2006-08-10 5:54 ` Xin Zhao
2006-08-10 6:03 ` Neil Brown
2006-08-10 15:15 ` Xin Zhao
2006-08-10 16:11 ` Matthew Wilcox
2006-08-10 16:23 ` Xin Zhao
2006-08-10 16:54 ` Matthew Wilcox
2006-08-10 17:08 ` Xin Zhao
2006-08-10 17:38 ` Trond Myklebust
2006-08-10 17:28 ` Trond Myklebust
2006-08-10 18:02 ` Xin Zhao
2006-08-10 19:59 ` Trond Myklebust
2006-08-10 22:25 ` Xin Zhao
2006-08-11 0:44 ` Trond Myklebust
2006-08-10 22:28 ` Xin Zhao
2006-08-11 0:38 ` Trond Myklebust [this message]
2006-08-10 23:42 ` Bryan Henderson
2006-08-10 17:50 ` Bryan Henderson
2006-08-10 18:15 ` Xin Zhao
2006-08-11 0:07 ` Bryan Henderson
2006-08-10 21:00 ` Peter Staubach
2006-08-10 6:04 ` Xin Zhao
2006-08-10 6:15 ` Xin Zhao
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=1155256734.5826.94.camel@localhost \
--to=trond.myklebust@fys.uio.no \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=neilb@suse.de \
--cc=uszhaoxin@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).