--On Monday, June 15, 2009 04:26:21 PM +0200 Felix Frank
<[email protected]> wrote:
For OpenAFS+OSD, it would be helpful for the clients to identify OSD
capable fileservers early. Codepaths can then be separated more easily
for OSD access vs. normal fileserver access.
Similarly, fileservers can store a hint about clients that are OSD
capable, and send OSD-related data only to those. Other clients will (as
is the case already) be forwarded actual file data instead of being
supplied with OSD metadata.
So really, you're asking for two capability bits -- one to advertise an OSD
server, and one to advertise that a client is OSD-capable. I'm not sure I
understand the purpose of either.
Why does a client need to know that a particular fileserver is an OSD
server? AFAIK the only behavioral difference is when accessing data of
vnodes which are _not_ directly resident on the server. Knowing the server
is OSD doesn't save you from fetching vnode status, and doesn't save you
from the possibility that you might have to fetch data from the server. It
does mean you might be able to use OSD access to reach some vnodes, but
that's going to be on a per-vnode basis, and it's going to involve making
different RPC's, so I don't see what a server-level "this server might
contain OSD vnodes" bit buys you.
Similarly, why does a server need to know a client is OSD-capable? Servers
don't decide whether to "forward actual file data" vs sending OSD metadata;
the OSD metadata is provided via FetchStatus and/or another RPC, and calls
to RXAFS_FetchData should still result in real file data. So the only
important thing here is what RPC is being called; a client that asks for
OSD metadata can be assumed to want that, and a client that calls
RXAFS_FetchData can be assumed to want the data that it asked for.
I'm not opposed to adding capability bits for this, but first I want to be
clear on exactly what they're for and what the semantics are.
Particularly...
- What do you have to do/support in order to advertise the bit?
- How are peers expected to behave when they see the bit?
- How are peers expected to behave when they do not see the bit?
- What is the expected behavior when talking to an old peer that doesn't
understand the bit?
- When can the bit change?
- What happens if a peer which supports the new feature fails to notice the
bit?
- Are there any security implications, particularly when capabilities are
unauthenticated?
These sorts of questions should be answered for _any_ new capability bit.
-- Jeff
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
