[OpenAFS] simple way to get people to file more bug reports

Jeffrey Altman jaltman@secure-endpoints.com
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
Content-Transfer-Encoding: 7bit


Bug reports when replied to by the gatekeepers send responses
to the reportee.  Are you looking for something different?

Jeffrey Altman

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
> number.
>   - a
> Jeffrey Altman <jaltman@secure-endpoints.com> writes:
>> Danno:
>> 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
>> pleasant:
>>  * 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
>>    refreshed.
>>  * 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
>> from
>>    http://www.openafs.org/windows.html
>> 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
>>       Locks
>>     * 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:
>>   http://www.pmw.org/afsbpw06/talks/jarod.willn/index.html
>> 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
>> finished.
>> 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?
>>>   http://www.sftpdrive.com/
>>> [background] 
>>> 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.
>>> thanks, 
>>> danno
>>> --
>>> Dan Pritts, System Administrator
>>> Internet2
>>> office: +1-734-352-4953 | mobile: +1-734-834-7224
>>> _______________________________________________
>>> OpenAFS-info mailing list
>>> OpenAFS-info@openafs.org
>>> https://lists.openafs.org/mailman/listinfo/openafs-info

Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature