[OpenAFS] simple way to get people to file more bug reports
Thu, 19 Oct 2006 17:00:21 -0700
I think people would be more likely to file bug reports if they could
monitor the status of the bugs they've reported -- ie via email
notification. This requires being able to create an account rather
than sharing the "guest" account.
Is there any chance of this changing?
Right now when I write a bug report I feel like it just vanishes into
the void. Sure I could come back and check on it, but I might not
remember for a few months and by that time I've forgotten the bug
Jeffrey Altman <firstname.lastname@example.org> writes:
> 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
> Jeffrey Altman
> 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
PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380