[AFS3-std] Request for a capability bit for RxOSD

[Jeffrey Hutzelman]

--On Monday, June 15, 2009 04:26:21 PM +0200 Felix Frank 
<Felix.Frank@Desy.de> 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