On 5/25/2023 7:35 PM, Marcio Barbosa wrote:
Hello everyone,
Hello Marcio,
I hope this email finds you well. I am writing to inform you that I have recently published an internet draft requesting the allocation of a new capability bit. The internet draft, titled "Introduce VLDB_CAPABILITY_LOCKTIMESTAMP", is now available and can be found at the following location: https://www.ietf.org/archive/id/draft-barbosa-afs3-vlcapabilities-lock-00.txt
Thank you for publishing the I-D which might be misnamed. The I-D proposes changes to two existing structures defined in src/vlserver/vldbint.xg and the operation of the RPCs that pass the structures as parameters. The affected types are:
* struct nvldbentry * nbulkentries * struct uvldbentry The affected RPCs are: * VL_GetEntryByNameN (OUT) * VL_CreateEntryN (IN) * VL_GetEntryByIDN (OUT) * VL_ReplaceEntryN (IN) * VL_ListEntryN (OUT) * VL_ListAttributesN (OUT) * VL_ListAttributesN2 (OUT) * VL_GetEntryByIDU (OUT)The proposal is that the following structure fields which are currently reserved and are required to be zero be repurposed to store a 32-bit timestamp representing the time a lock was issued.
* struct nvldbentry.spares2 * struct uvldbentry.spares2Although it is true that IBM as part of the AFS 3.5 release repurposed struct nvldbentry.spares1 as nvldbentry.matchindex the field is only defined for use as part of a new RPC: VL_ListAttributesN2. Best practice is not to modify the semantics of the structures used in existing RPCs. Instead, new RPCs should be allocated to indicate that the caller understands the new semantics. If the new RPC is supported by the server, then it will be executed with the expected semantics. Otherwise, RXGEN_OPCODE is returned indicating to the caller that the requested functionality is unavailable. The caller then falls back to an older version of the RPC.
In general, service capability bits should not be used for the purpose of altering the behavior of existing RPCs. The allocation of CLiENT_CAPABILITY_ERRORTRANS when queried by the fileserver is used to alter the output of RXAFS RPCs based upon whether or not the client understands the portable UAE error tables. The VICED_CAPABILITY_ERRORTRANS informs the client whether or not the server is capable of returning UAE error codes. If VICED_CAPABILITY_ERRORTRANS is unavailable the client needs to be careful with processing the return codes because the fileserver's OS error code assignments might not match those of the caller.
Service capability bits for UBIK services are particularly problematic because there is no requirement that all servers in the cell run the same version. Lets say that VL_CAPABILITY_LOCKTIMESTAMP was allocated for the purpose of indicating that nvldbentry.spares2 is a non-zero timestamp value if the entry is locked. There is no guarantee that the VL_GetCapabilities RPC result will be returned from the same server that responded to the VL_GetEntryByIDN RPC. If VL_CAPABILITY_LOCKTIMESTAMP was set on the server that responded to VL_GetCapabilities but the server responding to VL_GetEntryByIDN is older and doesn't support that behavior, then the caller might believe that the zero nvldbentry.spares2 field indicates that the entry isn't locked.
For UBIK services, the callers are not told which server responded to a given RPC. The only way of knowing if a new behavior was supported is to issue a new RPC and fallback to an older RPC if it is unavailable.
The nvldbentry and uvldbentry structures are used as both input and output parameters. This is because the way a client such as vos makes a change to the database entry is by fetching the current entry, modifying it, and writing it back to the server. Any specification that documents the new use of the field must indicate how the server is expected to handle the field when the structure is provided as input to the vlserver.
Since its introduction the spare2 field of struct nvldbentry and uvldbentry has always been set to zero when returned from the vlserver. If a vlserver was to set this value to a non-zero value, there would be no confusion for a caller that received it. While I am not in favor of modifying the semantics of existing RPCs, in this case returning the lock timestamp would not be harmful assuming that no one ever stole the selected field for a private use thinking it would never be used.
For the reasons described above I do not believe that allocation of the VL_CAPABILITY bit is warranted.
The I-D says that one of the motivations for auditing and troubleshooting. I will caution that because the VL service is UBIK, there is no guarantee that a VL RPC returning a nvldbentry or uvldentry was answered by the coordinator that it is not safe to trust any lock state including a lock timestamp. I am aware of proposals that have been made to use VL debugging RPCs to identify which server is the coordinator for the purpose of issuing RPCs solely to the coordinator. However, such an approach is racy. The coordinator's term can expire immediately following the response to the debugging RPC. Therefore, the results from such an approach cannot be trusted.
I hope you find this feedback useful.As I am not familiar with the current status of the AFS3 standardization process I will defer to someone else to respond to the question of timelines and milestones for standardization.
Allocation registries are maintained by [email protected]. See https://registrar.central.org.
Sincerely, Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
