[OpenAFS-announce] OpenAFS 1.7.8 released for Microsoft Windows

[Jeffrey Altman]

OpenAFS 1.7.8 is the latest in a new series of OpenAFS clients for the
Microsoft Windows platform that is implemented as a native file system.

The significant changes since 1.7.6 (1.7.7 was not announced) are:

 * Improved compatibility with anti-virus and other anti-malware
   products.
 * Significant improvements in processor utilization and parallel
   processing.
 * BSOD issues fixed.
   . Avoid race during file control block deallocation.
   . Disable bugcheck in release builds.  Too many out of memory
     conditions were triggering BSODs.
 * Deadlocks avoided
   . VolumeCB->ObjectInfoTree.TreeLock
   . ExtentsResource during CcPurge
 * Directory and file data synchronization errors fixed.
 * Permit rename of a file to itself without error.
 * Permit Explorer Shell to set UNIX mode bits.
 * Ignore AFS File Server file lock counts when deciding whether fail
   a lock request.  File Servers prior to 1.6.1pre5 do not report
   accurate values.

1.7.8 is the recommended release of OpenAFS for Microsoft Windows users.
It supports Microsoft Windows client operating systems from Windows XP
SP3 through Windows 7 SP1 and Windows Server operating systems from 2003
SP2 through 2008 R2 SP1.  The 1.7.8 Windows client is fully compatible
with all AFS server versions.

For UNIX, Linux, and MacOS X the recommended production-ready release of
OpenAFS is 1.6.0.

Source code and binaries can be downloaded from

     http://www.openafs.org/windows.html
     http://www.openafs.org/release/openafs-1.7.8.html

Please visit http://www.openafs.org/windows.html for up to date
information on the status of the OpenAFS for Windows client.

The native Windows file system client is the product of a crack
development team (alphabetical order by company name):

 * Peter Scott    (Kernel Drivers, LLC)
 * Rod Widdowson  (Steading System Software,LLP)
 * Jeffrey Altman (Your File System, Inc.)


What follows is a detailed discussion of the major benefits and new
features of the OpenAFS 1.7 series client.

 * Significantly faster than previous release series
   (up to 800MB/second read throughput from Solid State Disk
   backed cache)
 * Does not require the installation of the Microsoft Windows
   Loopback Adapter
 * Provides support for kernel enforced Process and Thread
   Authentication Groups
 * New Explorer Shell integration including AFS specific property sheets
 * Immediate access to \\AFS namespace after system resume
 * AFS Mount Points and Symlinks are File System Reparse Points

The Microsoft Loopback Adapter is no longer required
----------------------------------------------------

Prior OpenAFS clients for Microsoft Windows were implemented as an SMB
to AFS gateway whereby the OpenAFS service published a local SMB Server
named \\AFS on a private network address and all requests to browse,
read, or write the \\AFS name space were managed by Microsoft's SMB
client.  One of the requirements of this model is the use of a Microsoft
Loopback Adapter statically bound to a private IP address.  This ensured
that under most circumstances there would be a network path for the SMB
client to communicate with the AFS SMB server even if the machine was
disconnected from physical networks.

The loopback adapter approach worked quite well for Windows XP and 2003
but by the time Windows 7 and Server 2008 R2 were released the loopback
adapter had been converted to a plug'n'play device and it is no longer a
stable network path when the machine is disconnected from physical
networks or when the machine is returned from a sleep state.

With the introduction of a native AFS installable file system
driver(afsredir.sys / afsredirlib.sys) there is no requirement to
install the Microsoft Loopback Adapter.  This will be a significant
relief to sites that use software license tracking software that is
confused by the use of a single private network address on all machines.

No Delays After a Resume from Sleep
-----------------------------------

Windows Vista and 7 shutdown the network stack when the machine is
suspended.  This causes problems for applications that are actively
using files in the \\AFS name space when the machine suspended.  With
the IFS driver, open file handles are maintained through the sleep state
and are immediately available when the machine wakes.

No "AFS" server name collisions
-------------------------------

When relying on the Microsoft SMB client to resolve the \\AFS server
name it was critical that no machine in the active DNS domain or sharing
the same WINS server be assigned the name "AFS".  Doing so could result
in requests intended for the local AFS SMB gateway service being sent to
the remote system.

This is no longer an issue with the IFS driver.  The driver registers
ownership with the Multiple UNC Provider (MUP) for all UNC paths
beginning with \\AFS.

Performance Improvements
------------------------

The transaction rate and throughput performance of the SMB client was
limited by the "SMB client <-> loopback <-> SMB server" performance:
54MB/sec maximum on 32-bit systems and 63MB/sec on 64-bit systems.  The
IFS client is capable of throughput rates to/from cache up to 800MB/sec
depending on the system I/O bus and backing store capabilities.  Read
performance of uncached data from file servers on a 1Gbit/second network
link have been observed in excess of 74MB/seconds.

Symlinks to UNC Paths permit a cohesive name space
--------------------------------------------------

It has always been possible to create reparse points in Microsoft's DFS
name space that refer to \\AFS paths.  It is now possible to create
symlinks in AFS that refer to arbitrary UNC paths.  This permits the
construction of a cohesive name space that spans across both AFS and DFS
storage.

Reparse Points
--------------

AFS Mount Points and Symlinks are exported by the file system as Windows
reparse points with a Microsoft assigned tag value. Tools that are
OpenAFS reparse point aware query AFS symlinks and mount points without
requiring knowledge of AFS pioctls.

In a future release, mount points and symlinks will be first class
objects that can be created and removed using the Win32 File API.

AFS Volumes are Windows File Systems
------------------------------------

Each AFS volume is represented in the Windows kernel as a distinct
file system.  This will permit AFS volume quotas to viewed as
Windows file system quotas in a future release.

Authentication Groups
---------------------

AFS Tokens are associated with Windows user names in the SMB client.
With the IFS client, tokens are associated with Authentication Groups.
By default, an authentication group is allocated for each User SID
and Logon Session Id combination.  In addition, it is possible for
processes to create additional Authentication Groups.  Each thread in
a process can select an Authentication Group within the process as the
active Authentication Group.  This will permit AFS aware IIS modules
to associate AFS credentials with a particular incoming request.  An
IIS implementation of File Drawers will be the preferred implementation
once it is developed.

One of the significant benefits of Authentication Groups within the
Windows environment is that Windows services (svchost.exe, csrss.exe,
etc.) which impersonate user processes will seamlessly gain access
to the user's AFS credentials for the lifetime of the impersonation.

The use of Authentication Groups will finally permit a single Windows
user account to logon to a Terminal Server multiple times and maintain
independent credential sets.  This is a critical piece of functionality
for sites that map arbitrary non-AD Kerberos principals to a single
local machine account.

Explorer Shell Integration
--------------------------

The AFS Explorer Shell integration will gain support for symlink
and mount point overlay icons, tool tips, and Property dialog pages
that replace many of the existing AFS Context Menu dialogs.


Known Limitations
-----------------

OpenAFS implements a broad range of file system and RPC service
functionality which will permit it to satisfy the needs of the majority
of Windows applications on the market.  However, there are a number of
features that are presently not implemented.  These include:

 * The Windows File System Volume Query Quota Interface is not
   implemented. As a result, AFS quota information is not available
   to application processes or end users via Windows dialogs.

 * The Windows Volume Shadow Copy Service is not implemented.
   As a result, AFS backup volumes are not accessible via the
   Explorer Shell.

 * There is no support for storing DOS attributes such as
   Hidden, System, or Archive.

 * There is no support for Alternate Data Streams as required
   by Windows User Account Control to store Zone Identity data.

 * There is no support for Extended Attributes.

 * There is no support for Access Based Enumeration.

 * There is no support for Windows Management Instrumentation.

 * There is no support for Distributed Link Tracking and Object
   Identifiers.

 * There is no support for storing Windows Access Control Lists.
   Only the AFS ACLs are enforced.

 * There is no support for offline folders or disconnected
   operations.

Please send reports of successful deployments to
openafs-info@openafs.org and report problems to openafs-bugs@openafs.org.


Jeffrey Altman
for the OpenAFS Gatekeepers