The SMB-to-AFS gateway interface has serious architectural issues which
can
lead to kernel deadlocks in the SMB redirector on Vista and above which
cannot
be fixed in the AFS code. It also has this problem with SMB timeouts
and
AFS timeouts being out of sync which can lead to application failures
and
data loss ("delayed write failures"). Third, it forces SMB protocol
semantics
on the AFS cache manager. For all of these reasons, more than five
years and
$1.4M was spent on the development of the AFS redirector.If you tell me that you are suffering from a problem that the community has been suffering from for a decade and which the AFS redirector was developed to solve, I'm going to tell you to use the AFS redirector. If you tell me that you are having problems with the AFS redirector, I'm going to tell you to support the development of the AFS redirector so that the problems can be fixed. Of your list: 1. Printing issues: were fixed in 1.7.15 2. Adobe issues: bug in Acrobat Reader -- file bug report with Adobe 3. Various hangs; deadlocks with Sophos and other AV products fixed as they are reported You are of course free to pick your poison but the SMB interface is no longer under development because the problems with timeouts and the deadlocks in the SMB redirector simply cannot be fixed. Jeffrey Altman On Wednesday, September 05, 2012 2:28:05 AM, Michael Richter wrote: > We tried several versions of 1.7 till 1.7.8 and had some issues > (printing of smilie pages, Acrobat crashes, hang on shutdown/logout). > So we went back to 1.6.1 for our XP machines. Actually we use 1.7.15 > on our Vista/7 machines only (less than 20 PCs and notebooks). > > So you mean we should try again? > > schrieb Jeffrey Altman: >> An rx peer such as an AFS file service will return a RX_PACKET_TYPE_BUSY >> response to an RPC if the RPC was issued on a call channel which the >> file server believes is still in use. The most frequent cause of this >> condition is when the client's idle dead timeout processing triggers >> because the file service accepted an RPC request and has replied with >> nothing but keep alive messages for the configured period of time. It >> specific time depends on whether the volume the request was sent to is >> replicated or not. In all cases, the idle dead timeout period will be >> longer than 60 seconds. >> >> As the event log message indicates, the client will automatically retry >> the request when this situation occurs. However, the 1.6.1 client on >> Windows relies upon the SMB redirector and the SMB protocol has an RPC >> request timeout period of a bit more than 45 seconds. If the SMB >> timeout period is reached without a response from the SMB server, (aka >> the AFS cache manager \\AFS), then the SMB client will terminate the >> connection and it too will begin its own process of attempting retries >> and finally reporting errors to the application. >> >> If client side idle dead timeouts are being triggered, it means that the >> file service is not responding to clients in a timely fashion and an >> effort should be expended to determine why. >> >> The OpenAFS 1.7.17 client does not rely on the SMB redirector. It >> should be used on all Windows platforms as the AFS redirector does not >> impose an arbitrary 45 timeout period on file operations. >> >> Jeffrey Altman >> >> >> >> On 9/4/2012 2:45 AM, Michael Richter wrote: >>> Hi, >>> >>> since a month we have infrequent problem on our workstations. The PCs >>> are getting unresponsive, programs are crashing, it's not usable. While >>> this happens OpenAFS posts messages like this in 5s-interval: >>> >>> Type: Warning >>> Source: AFS Client >>> Event-ID: 4145 >>> Eventtime: 03.09.2012 16:06:24 >>> User: n/z >>> Computer: UBWSTMAPC185 >>> Description: >>> Busy call channel when communicating with server 130.149.204.70, >>> retrying ... >>> >>> This does not happen on all PCs. But all PCs use the same software: >>> Windows XP Prof SP3, OpenAFS 1.6.1 >>> >>> I asked our AFS server administrators but it seems that they don't know >>> what's wrong. >>> Does someone know what I can do to fix it? >>> >>> Michael >>> _______________________________________________ >>> OpenAFS-info mailing list >>> [email protected] >>> https://lists.openafs.org/mailman/listinfo/openafs-info >> > > _______________________________________________ > OpenAFS-info mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-info
signature.asc
Description: OpenPGP digital signature
