From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 9 22:48:37 2008 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDDD91065673 for ; Tue, 9 Dec 2008 22:48:37 +0000 (UTC) (envelope-from prvs=julian=2224d921f@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id A76008FC17 for ; Tue, 9 Dec 2008 22:48:37 +0000 (UTC) (envelope-from prvs=julian=2224d921f@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.75]) by smtp-outbound.ironport.com with ESMTP; 09 Dec 2008 14:20:04 -0800 Message-ID: <493EEF15.4050600@elischer.org> Date: Tue, 09 Dec 2008 14:20:05 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Kostik Belousov References: <20081203001538.GC96383@bunrab.catwhisker.org> <20081209190110.GW60731@albert.catwhisker.org> <20081209200431.GL2038@deviant.kiev.zoral.com.ua> In-Reply-To: <20081209200431.GL2038@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org, David Wolfskill Subject: Re: NFS (& amd?) dysfunction descending a hierarchy X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 22:48:37 -0000 Kostik Belousov wrote: > On Tue, Dec 09, 2008 at 11:01:10AM -0800, David Wolfskill wrote: >> On Tue, Dec 02, 2008 at 04:15:38PM -0800, David Wolfskill wrote: >>> I seem to have a fairly- (though not deterministly so) reproducible >>> mode of failure with an NFS-mounted directory hierarchy: An attempt to >>> traverse a "sufficiently large" hierarchy (e.g., via "tar zcpf" or "rm >>> -fr") will fail to "visit" some subdirectories, typically apparently >>> acting as if the subdirectories in question do not actually exist >>> (despite the names having been returned in the output of a previous >>> readdir()). >>> ... > > Did you saw me previous answer ? Supposed patch for your problem was > committed to head as r185557, and MFCed to 7 in r185796, and to > 7.1 in r185801. > > Please test with latest sources. did you notice that he tested with latest -current and releng 7?