From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from zeniv.linux.org.uk ([195.92.253.2]:38882 "EHLO
	ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S932948AbcBIWQ1 (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Tue, 9 Feb 2016 17:16:27 -0500
Date: Tue, 9 Feb 2016 22:16:23 +0000
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Mike Marshall <hubcap@omnibond.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>
Subject: Re: Orangefs ABI documentation
Message-ID: <20160209221623.GI17997@ZenIV.linux.org.uk>
References: <CAOg9mSQOZP155TnuoJG_YFb19oU35cj8fHTxn8BfJCw+asP-CQ@mail.gmail.com>
 <20160206194210.GX17997@ZenIV.linux.org.uk>
 <20160207013835.GY17997@ZenIV.linux.org.uk>
 <20160207035331.GZ17997@ZenIV.linux.org.uk>
 <CAOg9mSR1-7xOZCC=8dbx+zfHDep4NyUZm0e5XBDQzpCFaCNH7Q@mail.gmail.com>
 <20160208233535.GC17997@ZenIV.linux.org.uk>
 <20160209033203.GE17997@ZenIV.linux.org.uk>
 <CAOg9mSTFivsJDL-Ppruivd8gp_iThdq6N6+bWg0TfLXpV=rs8g@mail.gmail.com>
 <20160209174049.GG17997@ZenIV.linux.org.uk>
 <CAOg9mSTzE7KmrVC1zWSgC+vo20HfKLrsM3VPkxnYLN9roi+ZOw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAOg9mSTzE7KmrVC1zWSgC+vo20HfKLrsM3VPkxnYLN9roi+ZOw@mail.gmail.com>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Tue, Feb 09, 2016 at 05:02:59PM -0500, Mike Marshall wrote:
> Yes... I remember... I think you are referring to my reply in
> Message-ID: CAOg9mSSH=LuKyGiVthVajZFc6d=hGWGeLE8G9Y9d5B+g1-2sEg@mail.gmail.com
> in this thread...
> 
> I just commented those lines out again, and ran tests...
> both with and without signaling the client-core to restart.
> 
> dbench never complained and completed normally across
> restarts every time except the last, where it failed and the
> "Failed to allocate orangefs file inode" error was emitted from
> orangefs_create.
> 
> Until recently I ran everything, including the server, on the same
> VM. Currently I am mounting my Orangefs filesystem from a
> four-server setup from other VMs... it is can be pretty bad
> news for a userspace filesystem when the kernel crashes on
> the machine it is running on <g>...

OK...  Then the plan is
	* sort out the cancel semantics
	* replace op->waitq with completion and kill the loops in
wait_for_..._reply()
	* deal with slot allocations vs. bufmap removals
	* kill op->done (along with waiting in devreq write_iter and
complete(&op->done) in file.c)
	* sort out the treatment of signal interrupting file IO
	* test the living hell out of it, including the data corruption
checks, etc.

If that works out, we'll be in sane shape wrt wait-related stuff.  It still
leaves input validation and related fun, but those are at least synchronous
and single-threaded issues.