During the first week of December 2005 there was a discussion on this mailing list regarding how Byte Range Locking backed by AFS File Locks would be released in OpenAFS for Windows (and by proxy, AFS clients on UNIX/Linux.)
Over the last couple of months the Elder's have considered the issues raised in this thread. As a result, the Elders agreed that OpenAFS 1.4.1 would *not* ship with Byte Range Locking backed by AFS File Locks. The Windows client will include the full implementation of Byte Range Locking in the SMB Server *but* the locking engine will not obtain an AFS File Lock before issuing locks to the requesting applications. The Byte Range Locking in the SMB server will protect files from conflicts between applications on the local machine. The UNIX/Linux AFS client does not currently have a byte range lock engine available. Having come to this decision the Elders considered the question of how OpenAFS can begin to back Byte Range Locks with AFS File Locks in future releases. The Elders would like the following goals to be satisfied: + Byte Range Locking backed by AFS File Locks should be added to Windows and UNIX/Linux/MacOS X clients at the same time. + AFS File Lock promotion/demotion functionality should be added to avoid lock management race conditions. + A mechanism should be added that will allow cell administrators some ability to advertise a policy advising the client whether or not to use AFS File Locks to back locally managed Byte Range Locks. * The mechanism used for providing advertising policy should be general enough to allow it to be used with new features in the future. The first goals is simply a question of coding. The last three goals require an architectural decision about extending the AFS3 wire protocol. It is believed that adding a new RPC to support lock promotion/demotion will not be controversial. Satisfying the last two goals most likely will result in some significant discussion. A new mailing list, [EMAIL PROTECTED] has been created to host discussions related to extensions to the AFS3 wire protocol. The Elders considered the following proposal. The existing OpenAFS 1.4.x clients and file servers implement a GetCapabilities RPC that return an array of 32-bit masks. At the present time only one bit is defined. It is proposed that in addition to defining new capabilities (aka features) that bits be allocated to advertise policy. In particular, it is proposed that a bit be allocated to indicate that "the client *may* back local byte range lock allocations with AFS File Locks". This policy advertisement would be non-binding. Utilizing the GetCapabilities RPC to advertise this policy will provide granularity on a per-server basis. This would allow cell administrators to run mixed cells in which some servers are used for clients that may request AFS File Locks and other servers for clients that should not. Assuming this proposal is acceptable, the mechanism will be extended to all of the servers by adding GetCapabilities RPCs to those that do not already support them. These changes would be made to the forthcoming 1.5.x development release series and then in the 1.6 stable release series. In the 1.5/1.6 releases, a compile time option will allow the file server to be built suppressing the advertisement. By default, the file servers will advertise the flag to all clients that ask. The 1.5/1.6 releases will eventually include the following additional functionality: + The OpenAFS for Windows client will support 64-bit Windows platforms + Multiple local Kerberos realms for those organizations that have synchronized Windows and MIT/Heimdal Kerberos databases for client principals + Extensions to the Protection Server to enable multiple names to be associated with a single AFS ID. This will allow separate Kerberos 4 and Kerberos 5 names to be associated with an ID to address the "instance" vs "component" separator conflicts and an ability for users to treat both [EMAIL PROTECTED] and [EMAIL PROTECTED] as alternative identifications for common user "Jeffrey Altman". Your feedback is appreciated. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
