From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f171.google.com ([209.85.192.171]:32921 "EHLO mail-pf0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2993087AbcBSWu1 (ORCPT ); Fri, 19 Feb 2016 17:50:27 -0500 Received: by mail-pf0-f171.google.com with SMTP id q63so58295226pfb.0 for ; Fri, 19 Feb 2016 14:50:17 -0800 (PST) Date: Fri, 19 Feb 2016 17:50:15 -0500 (EST) From: Martin Brandenburg To: Al Viro cc: Mike Marshall , Linus Torvalds , linux-fsdevel , Stephen Rothwell Subject: Re: Orangefs ABI documentation In-Reply-To: <20160219223226.GD17997@ZenIV.linux.org.uk> Message-ID: References: <20160218111122.GS17997@ZenIV.linux.org.uk> <20160218205206.GW17997@ZenIV.linux.org.uk> <20160219002539.GX17997@ZenIV.linux.org.uk> <20160219223226.GD17997@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, 19 Feb 2016, Al Viro wrote: > On Fri, Feb 19, 2016 at 05:11:29PM -0500, Mike Marshall wrote: > > > Boo! Now a new problem is uncovered, I don't have a handle on it yet. > > Now it is possible to create a broken file on the orangefs server > > across a restart of the client-core. > > I suspect that it's your "getattr after create and leave dentry negative if > that getattr fails". Might make sense to d_drop() the sucker in case of > such late failure - or mark it so that subsequent d_revalidate() would > *not* skip getattr, despite NULL ->d_inode. > > Incidentally, why does your ->d_revalidate() bother with d_drop()? Just > have it return 0 and let the caller DTRT... > However I'm not so sure the kernel is at fault here. We see with a userspace tool which just opens a socket to the server that orangefs-readdir lists the file and orangefs-stat says ENOENT. Looks like the server's database is corrupt. -- Martin