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@xxxxxxxxxxxxxx > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
