From: Nicolas Williams <Nicolas.Williams@Oracle.com>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] Queries regarding LDLM_ENQUEUE
Date: Wed, 20 Oct 2010 12:13:49 -0500 [thread overview]
Message-ID: <20101020171348.GU1635@oracle.com> (raw)
In-Reply-To: <269E1A0D-2117-4ADC-BCDE-67A60EA9B974@oracle.com>
On Wed, Oct 20, 2010 at 11:00:53AM -0600, Andreas Dilger wrote:
> On 2010-10-20, at 10:46, Paul Nowoczynski <pauln@psc.edu> wrote:
> >> The name_to_handle() only needs to be called on a single node, and
> >> open_by_handle() is called on the other nodes. I agree that this
> >> doesn't avoid the full O(n) RPCs for the open itself but at least
> >> it does avoid the full path traversal from every client and on the
> >> MDS (replacing it with an MPI broadcast of the handle).
> >
> > excuse my ignorance, but why does open_by_handle() need to issue an
> > RPC? If it's to obtain the layout, couldn't the layout be encoded
> > into the 'handle'?
>
> In theory, yes. Practically, there is a size limit on the handle, and
> in large filesystems the layout is larger than this limit.
>
> Also, it depends on whether we want the MDS to have consistent
> behavior with the resulting open file descriptor or not.
>
> I suppose in many cases it would be possible to fake out an open file
> on the client without telling the MDS, but then there will be strange
> problems in some cases (e.g. stat() of the file, errors on close,
> etc.) that would result since the MDS won't know anything about the
> other openers. Maybe that is acceptable, I don't know.
Well, if we're going to add openg() (or whatever its name), we might as
well add variants of stat() that don't require getting the size when the
app doesn't need it, and forget about SOM, or forget about SOM when we
know that a file might be open by unknown clients (recover issues here).
Another possibility is that the handle encodes the current size, and
that to write past that size requires an RPC to establish open state,
but this ignores truncation.
Another possibility is to say that a handle is only good as long as the
original file descriptor remains open (recovery issues here), and that
client can tell the MDS that it will be sharing its handle with other
clients. Or that client could tell the MDS what all the clients are
that will share that handle (recovery issues here too).
Some sort of additional RPC seems hard to avoid here, but maybe it could
be async for clients opening by handle.
Nico
--
next prev parent reply other threads:[~2010-10-20 17:13 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-18 23:33 [Lustre-devel] Queries regarding LDLM_ENQUEUE Vilobh Meshram
2010-10-19 15:46 ` Fan Yong
2010-10-19 20:28 ` Vilobh Meshram
2010-10-19 22:53 ` Andreas Dilger
2010-10-20 2:04 ` Vilobh Meshram
2010-10-20 7:55 ` Andreas Dilger
2010-10-20 8:11 ` bzzz.tomas at gmail.com
2010-10-20 8:24 ` Andreas Dilger
2010-10-20 8:30 ` bzzz.tomas at gmail.com
2010-10-20 8:38 ` Nikita Danilov
2010-10-20 14:45 ` Nicolas Williams
2010-10-20 13:30 ` Eric Barton
2010-10-20 13:40 ` bzzz.tomas at gmail.com
2010-10-20 14:51 ` Paul Nowoczynski
2010-10-20 14:55 ` Nicolas Williams
2010-10-20 15:16 ` Paul Nowoczynski
2010-10-20 16:07 ` Andreas Dilger
2010-10-20 15:22 ` bzzz.tomas at gmail.com
2010-10-20 16:43 ` Paul Nowoczynski
2010-10-20 16:49 ` bzzz.tomas at gmail.com
2010-10-20 17:11 ` Paul Nowoczynski
2010-10-20 17:18 ` bzzz.tomas at gmail.com
2010-10-20 17:25 ` Paul Nowoczynski
2010-10-20 17:27 ` Andreas Dilger
2010-10-20 17:29 ` Nicolas Williams
2010-10-20 17:40 ` bzzz.tomas at gmail.com
2010-10-20 18:01 ` Andreas Dilger
2010-10-20 18:09 ` bzzz.tomas at gmail.com
2010-10-20 16:35 ` Andreas Dilger
2010-10-20 16:46 ` Paul Nowoczynski
2010-10-20 17:00 ` Andreas Dilger
2010-10-20 17:13 ` Nicolas Williams [this message]
2010-10-20 17:30 ` Andreas Dilger
2010-10-20 17:01 ` Nicolas Williams
2010-10-22 2:33 ` Vilobh Meshram
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=20101020171348.GU1635@oracle.com \
--to=nicolas.williams@oracle.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.