linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Xin Zhao <uszhaoxin@gmail.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	linux-fsdevel@vger.kernel.org
Subject: Re: Why must NFS access metadata in synchronous mode?
Date: Thu, 01 Jun 2006 01:55:40 -0400	[thread overview]
Message-ID: <1149141341.13298.21.camel@lade.trondhjem.org> (raw)
In-Reply-To: <4ae3c140605312104m441ca006j784a93354456faf8@mail.gmail.com>

On Thu, 2006-06-01 at 00:04 -0400, Xin Zhao wrote:
> Until kernel 2.6.16, I think NFS still access metadata synchronously,
> which may impact performance significantly. Several years ago, paper
> "metadata update performance in file systems" already suggested using
> asynchronous mode in metadata access.

...and how many NFS implementations have you seen based on that paper?

> I am curious why NFS does not adopt this suggestion? Can someone explain this?

a) NFS permissions are checked by the _server_, not the client.

b) Cache consistency requirements are _much_ more stringent for
asynchronous operation. Think for instance about an asynchronous
mkdir(): how should the client guarantee exclusive semantics (i.e. that
mkdir either creates a new directory or returns an EEXIST error)? how
should it guarantee that the server will have enough disk space to
satisfy your request? how should it guarantee that nobody will change
the permissions on the parent directory before the metadata was synced
to disk?,...

People are considering how to implement this sort of thing using the
NFSv4 concept of delegations and applying them to directories. It is not
yet obvious how all the details will be solved.

Trond


  reply	other threads:[~2006-06-01  5:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-01  4:04 Why must NFS access metadata in synchronous mode? Xin Zhao
2006-06-01  5:55 ` Trond Myklebust [this message]
2006-06-01 16:27   ` Xin Zhao
2006-06-01 17:26     ` Trond Myklebust
2006-06-02  3:42       ` Can Sar
2006-06-02  4:06         ` Trond Myklebust
2006-06-01 21:40     ` Andreas Dilger

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=1149141341.13298.21.camel@lade.trondhjem.org \
    --to=trond.myklebust@fys.uio.no \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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).