Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932728AbWCPUmE (ORCPT ); Thu, 16 Mar 2006 15:42:04 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932729AbWCPUmD (ORCPT ); Thu, 16 Mar 2006 15:42:03 -0500 Received: from linux01.gwdg.de ([134.76.13.21]:17547 "EHLO linux01.gwdg.de") by vger.kernel.org with ESMTP id S932728AbWCPUmB (ORCPT ); Thu, 16 Mar 2006 15:42:01 -0500 Date: Thu, 16 Mar 2006 21:41:57 +0100 (MET) From: Jan Engelhardt To: Bret Towe cc: linux-kernel Subject: Re: nfs udp 1000/100baseT issue In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1200 Lines: 30 > >a while ago i noticed a issue when one has a nfs server that has >gigabit connection >to a network and a client that connects to that network instead via 100baseT >that udp connection from client to server fails the client gets a >server not responding >message when trying to access a file, interesting bit is you can get a directory >listing without issue >work around i found for this is adding proto=tcp to the client side >and all works >without error UDP has its implications, like silently dropping packets when the link is full, by design. Try tcpdump on both systems and compare what packets are sent and which do arrive. The error message is then probably because the client is confused of not receiving some packets. >error message i see client side are as follows: >nfs: server vox.net not responding, still trying >nfs: server vox.net not responding, still trying >nfs: server vox.net not responding, still trying Jan Engelhardt -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/