All of lore.kernel.org
 help / color / mirror / Atom feed
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:44:54 -0400	[thread overview]
Message-ID: <1155257094.5826.101.camel@localhost> (raw)
In-Reply-To: <4ae3c140608101525u7b6eeaebjca351ba850173544@mail.gmail.com>

On Thu, 2006-08-10 at 18:25 -0400, Xin Zhao wrote:
> The inter-VM inode helps reduce communication cost used to retrieve
> file attributes in a VM environment. In a network environment, it is
> possible for a client to direct see the inode caches of the server.
> But in the virtual server environment, where both client and server
> running on the same physical host, this would be possible.
> 
> If clients have read-only access to server's inode cache, they can
> directly retrieve file attributes without incurring expensive
> getattr() rpc call. Of couse the delegation is able to allow a client
> to trust local cached file attributes without worry about server
> change. But this only works when file is not shared by multiple
> clients. Right? Does NFS4 has some other mechanisms that can further
> improve performance on metadata access?

Not metadata access, no. That would require some seriously messy locking
rules.
It improves performance by allowing a client to access the block device
directly for data reads and writes if it has the capability of doing so.

  Trond


  reply	other threads:[~2006-08-11  0:45 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 [this message]
2006-08-10 22:28                   ` Xin Zhao
2006-08-11  0:38                     ` Trond Myklebust
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=1155257094.5826.101.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 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.