[OpenAFS] simple way to get people to file more bug reports
Thu, 19 Oct 2006 21:05:31 -0500
This is a cryptographically signed message in MIME format.
Content-Type: text/plain; charset=ISO-8859-1
Bug reports when replied to by the gatekeepers send responses
to the reportee. Are you looking for something different?
Adam Megacz wrote:
> 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
> - a
> 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
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature