[OpenAFS] status of samba serving AFS file space? other non-native
Mon, 16 Oct 2006 17:05:20 -0400
This is a cryptographically signed message in MIME format.
Content-Type: text/plain; charset=ISO-8859-1
I suspect that if people filed more bug reports when problems were
experienced that things would get fixed faster. I understand that folks
are reluctant to file reports when they can't reproduce the problems or
when there are no resources available to assist in debugging or
identifying the issues. Folks want a product that works and we want
to provide it. Unfortunately, unless reports are received we have no
idea that there is a problem. Each organization uses a different subset
of the functionality and therefore has the potential to identify
problems that others are not experiencing.
This is particularly frustrating for me because I am often hearing
rumors that organizations are having problems but when I ask for details
no one can provide them and bug reports are never submitted.
As it turns out about three weeks ago an organization brought to my
attention a serious problem in the Windows client that might have
impacted your users as it occurs when multiple clients are actively
creating/deleting files from the same directory. To reproduce the
problem I wrote some test code which creates, writes, reads, closes,
deletes temporary files and executed it from multiple times and from
multiple machines in the same directory. What I discovered was not
* if the client has dirty buffers and the file has been deleted
the buffers will remain dirty forever (or until the persistent
AFS Cache is destroyed).
* dirty buffers were not being written to the file server in a
timely manner. It could take more than 23 minutes for all of
the buffers in a 80MB cache to be checked and written to the
file server. Dirty buffers are not flushed when a file is
closed because if writing the dirty buffers takes longer than
the CIFS timeout period, the CIFS client will tear down the
SMB virtual circuit which in turn would invalidate all existing
file handles and outstanding locks.
* there were race conditions which could result in stat cache entry
reference leaks. A stat cache entry with a reference cannot be
recycled. If all stat cache entries are in use, then the OpenAFS
client will panic when a new file is accessed. If the reference
counts wraps back to zero, the AFS client will panic when freeing a
reference. (stat cache entries are persistent so reference leaks
accumulate over time.)
* All pioctl operations would leak reference counts on the stat
cache entries for the directory. The Explorer Shell extension
performs many pioctl calls on the directory each time it is
* If the client panics, all dirty buffers will be lost and Windows
may restart the AFS Client Service so that the end user doesn't
even realize that there was a crash.
Although they are not announced yet, OpenAFS 1.4.2 (205) and 1.5.9 (902)
builds address these issues. There are links to the Windows installers
With regards to the distinctions between 1.4.2 and 1.5.9. The rate
of new development on the Windows client far exceeds that of development
on any other platform. This is primarily due to the fact that there has
been so much more that has been required for the Windows client to play
catchup with the rest of the platforms and because Microsoft has
released several new platform variants (XP SP2, 2003 SP1, 64-bit
XP/2003, and Vista). I do not believe that the 1.5.9 client is any
less stable than the 1.4.2 client. In fact, the reverse is problem true.
One performance problem that we have seen reported many times is that
the Windows clients performance gets really really slow after a
directory is listed multiple times in Explorer (or a File Open/Save
dialog.) We narrowed the problem down to access control issues and
the lack of support in the Windows AFS client for the Inline Bulk Status
RPC. Instead of performing a single RPC to obtain the status
information for the contents of an entire directory, the Windows client
performs a separate FetchStatus RPC for each entry. If the user does
not have permission to obtain the status info for an entry, the file
server would send an error (rx abort EACCESS) to the client. If the
file servers sends too many errors in a row, the rx library will attempt
to pace the client to prevent a denial of service against the file
server. Support for Inline Bulk Status calls were added to 1.5.9 but
the changes are considered too large to pull into the 1.4 series.
The 1.5.9 release also contains support for a number of other "features":
* Support for 64-bit Large Files
* Support for 64-bit Windows XP/2003/R2/Vista
* Implements Windows Byte Range Locking backed by AFS File Server
* Uses GetCapabilities RPCs to probe the server status
* Logs fs crypt state to the Windows Event Log
* Supports DebugOutputString debugging of the RX Library
* New command: fs uuid [-generate]
* Improved CIFS protocol capatibility
* Hard Dead and Connection Timeout values restricted to the CIFS
Session Timeout value.
Note that the 1.4.x and earlier clients would not reject attempts
to read/write data beyond 2GB. The data would simply be corrupted.
In answer to your question regarding Samba. There are several sites
that I work with who have used Samba as a gateway for users on MacOS X
and Windows that do not have AFS clients installed. The number one
issue that they complain about is the fact that in order to use the
--fake-kaserver functionality in conjunction with either a Kerberos
KDC authentication or an LDAP authentication, the clients have to be
configured to send username/password in the clear. Sending the user's
Kerberos password in the clear is not a desirable solution. This may be
improved with Vista clients since Vista will negotiate TLS first and
then perform the SMB authentication on top of that. Even if you are
willing to require that your users first VPN (or otherwise tunnel) to
the Samba server, you still have the problem that the most recent
MacOS X and Windows client OSs won't send username/password in the clear
out of the box.
Locking via the Samba server is not going to be improved.
WebDAV is a work in progress. UMich has demonstrated CoSign, mod_dav
and mod_waklog working together but I believe there are still issues
to resolve. Here is a link to the mod_waklog presentation from this
year's best practice workshop:
Regarding SFTPdrive, I have not used it. I suspect if you can setup the
SSH server to access your files via AFS then the product will work.
I would guess that similar to the FTP shell extensions it works by
copying the file locally and then copying it back when the user is
Secure Endpoints Inc.
Dan Pritts wrote:
> Hi folks -
> what's the current status of using samba to serve files from an
> AFS backend to windows clients? I could easily use Linux or Solaris
> as the samba server. Other platforms would be possible.
> how does handle file locking? How does it handle authentication?
> can you successfully use MS office documents from the share?
> We're having some issues with deploying the windows AFS client to some
> of our staff, and I'm considering my alternatives.
> Other alternatives folks are using would be interesting too (webdav?).
> Anyone have any experience with this?
> since i know folks will be interested, here's the scoop with our issues
> with the windows client. I am not interested in starting any flame wars,
> and really i'm not interested in discussing the problems we've had with
> the windows client. I personally am interested in making AFS work,
> but it has the potential to become a huge political issue within our
> organization and i'd like to avoid that.
> Bottom line, our accounting staff has had a lot of bad experience with
> testing afs on the windows desktop. Some of it has been in the form
> of long delays accessing files (which I think was related to recent
> bug fixes in the server code, and I think this problem is gone).
> some of it has been mysterious issues with changes not being saved.
> I think this is really because they are simultaneously editing AFS
> files with MS office, because they refuse to drag files to their desktop
> before opening and the 1.4 client we're using doesn't try to create any
> AFS locks. Yes i know that 1.5 should solve this problem but i've been
> worried what else will happen with the unstable branch.
> The situation is a lot better with the 1.4.2 rc client, but they're
> at the point that they have lost patience with problems and I need to
> give them something that just works. I'm hoping to avoid that solution
> being a windows file server, since we will continue to use afs within
> the organization, but it's not out of the question.
> Dan Pritts, System Administrator
> office: +1-734-352-4953 | mobile: +1-734-834-7224
> OpenAFS-info mailing list
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature