From: Dilger, Andreas <andreas.dilger@intel.com>
To: lustre-devel@lists.lustre.org
Subject: [lustre-devel] OBD_CONNECT_* flags
Date: Wed, 10 Jun 2015 06:58:02 +0000 [thread overview]
Message-ID: <D19D2F08.F62A2%andreas.dilger@intel.com> (raw)
In-Reply-To: <55774CE2.30107@cray.com>
On 2015/06/09, 2:30 PM, "Patrick Farrell" <paf@cray.com> wrote:
>Hopefully a fairly quick question... I'm adding a new feature (lock
>ahead) and would like to use an OBD_CONNECT flag to verify it's
>supported on the server. I took a quick stab at adding one, but I'm
>getting lost in the details of how the flags are set and exchanged.
>
>Essentially, I would like the client and server (OSS in this case) to
>both have a particular OBD_CONNECT flag or the client will return
>-EOPNOTSUPP when the feature (an ioctl) is invoked.
>So: Is an OBD_CONNECT flag the right way to do this?
>If so, could anyone give a brief explanation of how that works, or an
>example to build off of?
The client sets the OBD_CONNECT flags for features it supports before
connection to the MDS or OSS (or MGS, but we'll leave that out for now).
The server replies with the subset of those flags that it supports,
masking the client flags with either the MDS_CONNECT_SUPPORTED or
OST_CONNECT_SUPPORTED mask, depending on the service type. The resulting
set of flags are features that both the client and server understand.
Definitely using OBD_CONNECT flags is the intended way to do this.
If this feature only needs to be understood by the OSC and OST, then you
are done - the connect flags are stored for each connection. If the llite
layer needs to be aware of the feature then this is a bit more complex
because the client->OST connections are async and the flags aren't set
until the connection is completed. That is fine for checking features as
needed during runtime on a particular OST, but not possible if you would
need to refuse the mount because of some missing server feature (which I
don't think is relevant for your use case).
In theory, the OBD_CONNECT flags could be different on a per-OST basis if
the OSTs were just being upgraded, but practically this is not the case.
For lockahead this seems manageable, since this is just an advisory
feature, so it would be OK if the lockahead requests weren't executed for
some OSTs.
Cheers, Andreas
--
Andreas Dilger
Lustre Software Architect
Intel High Performance Data Division
prev parent reply other threads:[~2015-06-10 6:58 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-09 20:30 [lustre-devel] OBD_CONNECT_* flags Patrick Farrell
2015-06-10 6:58 ` Dilger, Andreas [this message]
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=D19D2F08.F62A2%andreas.dilger@intel.com \
--to=andreas.dilger@intel.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.