This page was last updated 04/06/10
Organizations that rely on OpenAFS for Windows are encouraged to financially support its on-going development. For the most part, all of the small projects that can be done in a few hours time have all been addressed. What are left are larger more strategic projects which can only be accomplished by dedicating the appropriate developer resources. Organizations do not have to pay the full cost of these projects by themselves. Secure Endpoints Inc. will co-ordinate contracts with multiple organizations in order to distribute the cost. Please send e-mail to openafs@secure-endpoints.com with questions, feedback, or offers of support
The AFS Client Service has come a long way in the last three years. For a summary of the progress please read the latest OpenAFS for Windows Status Report. Still, there are many things that can be done to improve the user experience and performance of the product.
The existing OpenAFS Client relies on an SMB server implementation (similar to Samba) to export the AFS name space to Windows Applications. This has a number of negative side effects that would be avoided if the OpenAFS for Windows client were to be implemented via a combination of Network Redirector and File System Filter drivers. The current OpenAFS client on Windows is not a true Windows file system. Instead it operates as a SMB translator service. The Windows OpenAFS client creates a SMB fileserver on the client machine, and Windows accesses this SMB server as a normal Windows shared volume. For each I/O operation made to this virtual SMB server, the OpenAFS client translates the SMB request into a comparable operation on the OpenAFS fileserver. This impacts the Windows OpenAFS client in a number of negative ways:
The semantics of the CIFS file system are different than the semantics provided by OpenAFS. Because Windows sees the OpenAFS file system as an CIFS share, it has no way of acquiring the true capabilities or semantics of OpenAFS. This causes some applications to perform poorly when they expect the semantics of CIFS, which OpenAFS does not necessarily provide.
The use of the translator service requires data to be received by the OpenAFS client via RX, translated into SMB packets, and then sent over the virtual loopback interface to the actual SMB server on the same machine. This results in a number of extra data copies, which greatly reduces OpenAFS performance. Making OpenAFS a native Windows file system will reduce the number of data copies and protocol translations, which will increase performance.
The CIFS/SMB protocol does not provide any mechanism for the server to inform a client that an operation is actively being processed even if it is taking a long time to complete. The CIFS clients in Windows 2000 and above implement a dynamic timeout algorithm that estimates how long a request should take based upon the prior response time of the server and the amount of data being transferred. As the OpenAFS SMB server and cache manager are local to the machine, it is frequently the case that the response time in on the order of hundreds of microseconds. When a request to read or write large amounts of data from/to a file server occurs or if the needed volume is temporarily busy, the CIFS client will frequently timeout the request and tear down the SMB virtual circuit. This has a negative impact on applications as it results in all file handles being invalidated and all locks being dropped which must then be re-established.
In order for the UNC server name "AFS" to be visible on all clients, the Microsoft Loopback Adapter (MLA) must be installed in order to provide a private network adapter to which the "AFS" Netbios name can be bound. The installation of the MLA negatively effects several popular software licensing and anti-spyware products which use the network adapter MAC address as a unique key.
The solution is to replace the SMB server with a native Windows File System Redirector that can be supported on Windows 2000 SP4, Windows XP SP2, Windows 2003 SP1, Windows XP 64, Windows 2003 R2, Windows Vista, Windows 7, Server 2008 and Server 2008 R2.
Development has been completed. Awaiting integration into a future OpenAFS 1.7/1.8 release. See http://www.openafs.org/roadmap.html for timelines.
Microsoft Windows users are used to the "Windows Offline Folders" functionality which permits them to synchronize local copies of files or folders from a CIFS server to their local disk for use when disconnected from the network. UMichigan long ago implemented a read-write disconnected mode for the UNIX AFS client which permits users to continue using data within the AFS cache while in an offline mode. Once the client is restored to an online state the modifications made to the cache buffers are written back to the file server provided that there are no conflicts. If there are conflicts a manual conflict resolution process must be initiated.
Implementing disconnected operations requires much more than just making the contents of the AFS cache available. Many issues affecting the end user experience must be addressed.
Estimated implementation time: TBD
The OpenAFS cache manager on Windows uses a single memory mapped paging file as the cache. This imposes a couple restrictions. First, on 32-bit operating systems the cache cannot be larger than the largest contiguous memory address region which is typically between 650MB and 1.2GB depending on other software packages that have been installed. Second, as the paging file is memory mapped into the afsd_service address space, there is no mechanism by which the virtual memory associated with the service can be limited without reducing the overall cache size.
The goal of the second level cache architecture is to provide an open plug-in interface by which third parties can implement their own second level cache. This would permit afsd_service to limit use of the paging file for file/directory status objects, volume metadata and the active working set of file contents. When a cache miss occurs in the paging file, a call would be issued to the second level cache implementation. Only if the second level cache does not hold the required data would the file server be contacted.
By producing an open interface, the second level cache could be implemented as a distributed peer-to-peer cache within a local area subnet as opposed to a single local file cache.
Estimated implementation time: TBD
The existing AFS Shell Extension adds an "AFS" menu when the current folder or selected objects exist within the AFS name space. This menu is a hodge-podge of items. A few of the items appropriately belong on a context menu but are in the wrong place and most of the items should be Property sheets or should display the information to the end user in a different manner. The following is a proposal for a replacement.
OpenAFS should provide a custom column handler to introduce several new detail columns that would display additional information about objects within AFS. For example, columns can be provided to optionally display and perhaps edit:
Estimated implementation time: 18 to 24 hours
Instead of the existing handler that simply adds an "AFS" menu containing everything, the new handler will selectively modify the existing context menu's behaviors when the current folder is located within AFS.
Estimated implementation time: 12 to 16 hours
A variety of property sheets will be added. Some will be context sensitive and others will be general tools.
An "AFS File" sheet
An "AFS Mount Point" sheet
An "AFS Symlink" sheet
An "AFS Volume" sheet
An "AFS ACL" sheet
For any given item the "AFS ACL", "AFS Volume", and "AFS Directory" sheets will be added to the Properties dialog. The "AFS File", "AFS Symlink", and "AFS Mount Point" sheets will be added when an item of that type is selected.
Estimated implementation time: 60 to 80 hours
An AFS Tool Band will provide graphical shortcuts to:
Estimated implementation time: 12 to 16 hours
A tool tips handler provides support for additional information about an object when the user hovers the mouse over the object. Tool tips could be used to display the destinations for symlinks and mount points.
Estimated implementation time: 12 to 16 hours
A metadata handler can be used to provide enhanced information about selected objects with the "Details" box within the Folders view.
Estimated implementation time: 18 to 24 hours
The Explorer Shell namespace can be extended by providing a plug-in to Windows Explorer called a Shell Namespace Extension. These extensions create a virtual namespace within Windows Explorer and have full control over how the namespace is rendered to the user. A new namespace can be attached to the current Shell namespace as a child of an existing namespace, including file system folders allowing the user to navigate to the new namespace.
Estimated prerequisite implementation time: 62 to 108 hours
The number of volumes in typical cells for large organizations are frequently counted in the tens of thousands. The Recent name space will show users the most recently accessed volumes from which file data was either read or written. Users will be able to pin volumes within the name space and can easily map drive letters to any listed volume. Volumes are represented as shortcuts. Opening an entry in this name space will redirect the user to a permanent path that can be accessed by applications.
Estimated implementation time: 45 to 72 hours
A name space extension can be developed for individual cells which will dynamically select the user's personal volume based upon the Kerberos principal name stored in the AFS token used to access the cell.
Each organization develops their own layout for volumes in their cell which are frequently based around users, projects, groups, departments, classes, etc. When there are thousands of volumes within each category it can often be challenging for end users to find the particular data they are searching for. The AFS Name Space extension permits custom name spaces to be defined which can be used to assist end users in finding the volumes that most interest them.
Once
a volume is selected, drive letters can be conveniently mapped.
Estimated implementation for first organization: 220 to 334 hours
Subsequent organizations: 70 to 100 hours (includes custom installers and organization specific deployment guide)
The existing control panel provides a mixture of functionality related to the logged in user as well as the system-wide configuration of the AFS Client Service. Configuration of the AFS Client Service should require administrative access which should not be available to all users. To improve the user experience, the control panel should only contain functionality that is applicable to the user. All of the administrator privileged functionality should be moved to the Microsoft Management Console. Microsoft Windows Vista will enforce this functional split by preventing processes from starting with administrative privilege even when the user is an "Administrator" unless the user explicitly grants the permission. Separate processes that run only with Administrative privilege must be created when changes to the machine or service configuration is required.
Therefore, the new OpenAFS Control Panel will only provide the following functionality:
The AFS Group Editor will provide all of the functionality of the pts command line tool. Shortcuts to this panel will accessible from the AFS Explorer Shell Extensions.
Estimated implementation time: 36 to 48 hours
This panel will duplicate some of the configuration capabilities of Network Identity Manager and permit the user to select which Network Identities will be used to obtain tokens for which cells.
Estimated implementation time: To be determined
A shortcut to start the OpenAFS Client Service MMC Plug-in will be provided if the user has administrative privileges.
Estimated implementation time: 2 to 3 hours
The Microsoft Management Console (MMC)has become the standard for configuring policy for Windows Services. The AFS Client Service is highly configurable and yet only a small fraction of the options can be adjusted via the existing AFS Control Panel. The majority must be set by manually adding or modifying registry values. The list of registry values used by OpenAFS for Windows is documented in Appendix A of the Release Notes.
The MMC will also provide access to:
This project is being worked on by Brant Gurganus. See the project web site. http://code.google.com/p/openafsclientmmc/
Microsoft Vista's User Account Control requires that privileged operations such as starting or stopping services or modifying machine configuration cannot be performed by processes that are executed as normal users. This requires that the Network Identity Manager AFS Provider configuration page be modified to remove the privileged operations and provide a privileged access method to the Microsoft Management Console.
Estimated implementation time: 2 to 3 hours
As of the 1.5.25 release, the AFS Servers essentially work on Microsoft Windows provided that they are manually configured. The AFS Server Configuration Wizard can be used provided that nothing goes wrong during the initial configuration. Unfortunately, the wizard is not very robust and cannot be used to resume an install after an error condition has been corrected. Regardless, the wizard makes a number of assumptions about Microsoft Windows and the AFS client that no longer hold true. In addition, the salvager is known to crash. As a result its use is strongly discouraged.
The long term goal of this project is to develop and distribute AFS Servers that can be deployed on Microsoft Windows Server and that will integrate well into the Active Directory environment. There are several sub-projects that must be achieved:
Estimated implementation time: 640 hours.
Send additional feature requests to openafs@secure-endpoints.com.