All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] SOM safety
Date: Tue, 5 Jan 2010 15:55:12 -0600	[thread overview]
Message-ID: <20100105215512.GB1516@Sun.COM> (raw)
In-Reply-To: <FCF9512F-B081-4307-AA58-9A161790073D@sun.com>

On Tue, Jan 05, 2010 at 02:50:51PM -0700, Andreas Dilger wrote:
> On 2010-01-05, at 11:39, Eric Barton wrote:
> > The MDS must guarantee that any SOM attributes it provides to its
> > clients are valid at the moment they are requested - i.e. that no file
> > stripes were updated while the SOM attributes were computed and
> > cached.  This guarantee must hold in the presence of all possible
> > failures.
> >
> > Clients notify the MDS before they could possibly update any stripe of
> > a file (e.g. on OPEN) so that the MDS can invalidate any cached SOM
> > attributes.  Clients also notify the MDS with "done writing" when all
> > their stripe updates have committed so that the MDS can determine when
> > it may resume caching SOM attributes.
> 
> This brings up an interesting question.  When the client does a lookup  
> on a file, or first opens it, the client gets the cached size from the  
> MDS (assuming SOM cache is valid).  However, after this initial  
> update, what guarantee does the client have that the size is still  
> valid?  Must it do further MDS getattr or OST glimpse operations in  
> order to revalidate the size?  I don't recall any lock bit that the  
> MDS gives the client that tells the client that the file size it has  
> is still valid.

Well, the guarantee should be from the time the MDS responds to the
client until the stat() call returns to the application.  After all,
POSIX talks about system calls, not client/server messaging.  That means
that the client effectively holds a lock on the cached attributes for a
bit.

> In this regard, it seems that SOM would only provide an improvement on  
> the initial "ls -l" operation, and subsequent "ls -l" operations would  
> be slower than the current "readdir + statahead + DLM lock  
> cache" (which would not need to do any RPCs for the second "ls -l").

If the client can hold that lock for as long as no one is writing, then
the client can cache that information for that long.

Nico
-- 

  reply	other threads:[~2010-01-05 21:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-05 18:39 [Lustre-devel] SOM safety Eric Barton
2010-01-05 21:50 ` Andreas Dilger
2010-01-05 21:55   ` Nicolas Williams [this message]
2010-01-05 22:25   ` Oleg Drokin
2010-01-11 17:05   ` Vitaly Fertman
2010-01-06 17:09 ` Aleksandr Guzovskiy
2010-01-06 17:28   ` Nicolas Williams
2010-01-06 18:10     ` dzogin
2010-01-11 21:41 ` Vitaly Fertman

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=20100105215512.GB1516@Sun.COM \
    --to=nicolas.williams@sun.com \
    --cc=lustre-devel@lists.lustre.org \
    /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.