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

Adam Megacz megacz@cs.berkeley.edu
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
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

-- 
PGP/GPG: 5C9F F366 C9CF 2145 E770  B1B8 EFB1 462D A146 C380