From owner-freebsd-fs@FreeBSD.ORG Wed Aug 4 00:33:01 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47DA91065673 for ; Wed, 4 Aug 2010 00:33:01 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 00DF68FC1F for ; Wed, 4 Aug 2010 00:32:58 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAB1SWEyDaFvO/2dsb2JhbACDFZ14shKSDYEmgyBzBIkP X-IronPort-AV: E=Sophos;i="4.55,312,1278302400"; d="scan'208";a="89372274" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 03 Aug 2010 20:32:54 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id BB32DB3F0E; Tue, 3 Aug 2010 20:32:56 -0400 (EDT) Date: Tue, 3 Aug 2010 20:32:56 -0400 (EDT) From: Rick Macklem To: Markus Gebert Message-ID: <1431295206.277532.1280881976627.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [24.65.230.102] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - SAF3 (Mac)/6.0.7_GA_2473.RHEL4_64) Cc: freebsd-fs@freebsd.org Subject: Re: NFS problem: file doesn't appear in file listing, but can be accessed directly X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 00:33:01 -0000 > From: "Markus Gebert" > To: "Attila Nagy" > Cc: freebsd-fs@freebsd.org > Sent: Tuesday, August 3, 2010 4:47:38 PM > Subject: Re: NFS problem: file doesn't appear in file listing, but can be accessed directly > On 03.08.2010, at 16:36, Attila Nagy wrote: > > >> You can try replacing the client and server with the experimental > >> ones and see if that fixes the problem. > >> For the client: mount with "-t newnfs" instead of "-t nfs" > >> For the server: start both mountd and nfsd with the "-e" option > > Sure. It works with the newnfs client, so it must be either a weird > > interaction between the FreeBSD server and client (old), or a client > > bug. > > Have you tried comparing on-the-wire NFS requests and responses > between newnfs and legacy nfs clients for your test case? Maybe you > can rule out the former like this. Or at least prove that the server > actually responds correctly to the READDIR request. > Yep, it would be nice to see what went across the wire, particularly the case that fails (the regular client). I've got a hunch that the clients use different readdir sizes by default which will make comparison tough. Maybe you could try both clients using "readdirsize=32768" as an argument, so that they're at least reading the dir. in chunks of the same size. You can probably tell if the reply on the wire is legit by pulling it into wireshark. If wireshark thinks the readdir replies are ok and the filename exists in an entry on it (when the client fails to find it), that would indicate that the regular client has a bug, I think? If "-t newnfs" breaks when you change the readdirsize, then it suggests the server is busted. If you can capture the failing case with something like: tcpdump -s 0 -w xxx host (if run on the client) and then email me "xxx" as an attachment, that would be appreciated. (basically tcpdump the "ls" command that fails.) rick