Here is an update to my e-mail of 7 November 2006:

I have been working closely with Microsoft for the last several weeks
and I believe that we have developed an acceptable solution that OpenAFS
can deploy now to enable the AFS Client Service to survive a Vista
standby/suspend operation without resulting in a panic.  The new code
only works on Vista and is activated based upon a run time check.

The basis of the code change is that upon receipt of a standby/suspend
power management event, the AFS client service releases all of its
network resources.  Then when the AFS client service is notified to
resume it will strive to re-obtain the necessary network resources.

This results in some behavioral changes:

(1) file handles and CIFS sessions do not survive a system suspension
    as they did on earlier Windows platforms

(2) I have noticed significant delays ranging from 30 seconds to 120
    seconds for the power management events to be delivered and the
    network resources to be acquired after Vista is resumed.  During
    this time period, the AFS client service will not be available.
    Attempts to update the token list or re-establish open file
    handles will fail.

As indicated in the 7 Nov 2006 e-mail, the long term solution to a
stable AFS client on Windows is the replacement of the SMB gateway
with a native file system driver.  In the meantime, it is my hope that
users will find the forthcoming functionality satisfactory.

There are some other issues related to new security model in Vista
that users must be aware of.  Applications such as the AFS System
Tray tool that mix end user and administrator functionality will no
longer successfully be able to perform the administrator functions.
For example, it is no longer going to be possible to start/stop the
AFS client Service from the System Tray tool.  In addition, it will
no longer be possible to alter the service configuration from the
AFS Control Panel without first performing a "Run as: Administrator"
operation.

These applications will have to be re-written to separate the end
user and administrator functions.  The administrator functions will
need to wrapped in code that triggers a separate administrator
process or COM object to perform the operation.  Organizations that
are interested in contributing to see this work completed are encouraged
to contact me off list.

Jeffrey Altman
Secure Endpoints Inc.


Jeffrey Altman wrote:
> I want to provide you with an update on OpenAFS compatibility and
> Windows Vista.  A couple of months ago a bug was discovered in the
> Vista NetBIOS stack that would cause OpenAFS to crash anytime the
> operating system was placed into "Standby" mode.   Microsoft took
> the bug seriously and fixed it.  Unfortunately, the produced instability
> in other areas of the operating system and Microsoft was forced to
> pull the fix.  Therefore, the final Vista release that will be made
> publicly available in January is going to cause existing OpenAFS
> versions to crash.
> 
> As far as I can tell there is no work around to avoid the problem.
> Microsoft has had an engineer working on the problem for a couple of
> weeks without success.
> 
> Microsoft is committed to fixing this bug for Vista SP1.  Once a fix
> is available they will most likely make a QFE available to customers
> that have support contracts.
> 
> This has left OpenAFS in an awkward situation until a fix is available.
>  The best that I believe I can do is cause OpenAFS to gracefully
> shutdown when this error condition is detected.  The benefit of a
> graceful shutdown is that the data stored in the cache will be
> preserved.   However, if there were applications with files open within
> AFS at the time of Vista entering "Standby" mode, these files would not
> be available when the Operating System restarts.
> 
> It is my hope that Microsoft will allow OpenAFS to distribute the QFE
> (when available) as part of the OpenAFS installers.  If so, the majority
> of the damage can be avoided.
> 
> The long term solution is clear.  The OpenAFS community needs to move
> away from the SMB Gateway model and replace it with a native Network
> Provider / File System Filter model.  Completing this work in such a
> way that it is portable across Windows 2000 SP4 through Vista and
> works on both 32-bit and 64-bit operating systems is going to be time
> consuming and expensive.  I hired a Windows file system and kernel
> driver developer to review the work that has already been done and
> help design an architecture that can support all of the required
> platforms for the next ten years.  We believe that this work can be
> accomplished over a period of ten months provided that the necessary
> financial resources ($250,000 - $300,000) can be acquired.
> 
> The long term benefits of getting rid of the SMB gateway are:
> 
> (1) the use of the Microsoft Loopback Adapter will no longer be required
> 
> (2) all of the problems associated with the CIFS client timeout issues
>     will be removed.   this will not only improve performance but will
>     solve all of the "delayed write" and "network path no longer
>     available" errors.
> 
> (3) performance gains.  There is significant time delays and CPU
>     load added to each transaction as a result of the CIFS client and
>     SMB server both involving the SMB/NetBIOS/TCP/IP stack.
> 
> If your organization is in a position to assist us in financing this
> work, please contact me off-list.
> 
> Jeffrey Altman
> OpenAFS Gatekeeper/Elder
> 
> 
> 

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to