xfs
[Top] [All Lists]

Re: [PATCH 5/8] xfs: split direct IO write path from xfs_file_aio_write

To: Alex Elder <aelder@xxxxxxx>
Subject: Re: [PATCH 5/8] xfs: split direct IO write path from xfs_file_aio_write
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 5 Jan 2011 18:36:25 +1100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <1294192495.2485.726.camel@doink>
References: <1294116518-14908-1-git-send-email-david@xxxxxxxxxxxxx> <1294116518-14908-6-git-send-email-david@xxxxxxxxxxxxx> <1294192495.2485.726.camel@doink>
User-agent: Mutt/1.5.20 (2009-06-14)
On Tue, Jan 04, 2011 at 07:54:55PM -0600, Alex Elder wrote:
> On Tue, 2011-01-04 at 15:48 +1100, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@xxxxxxxxxx>
> > 
> > The current xfs_file_aio_write code is a mess of locking shenanigans
> > to handle the different locking requirements of buffered and direct
> > IO. Start to clean this up by disentangling the direct IO path from
> > the mess.
> 
> All good, very good.  But I'm not sure why you cut
> out the code that backed off to buffered I/O if
> generic_file_direct_write() returns an error.
> (You gave no explanation.)

Oh, I thought I put one in there. It's simple, though - XFS handles
all allocation cases in the direct IO code and never returns a
result that will require falling back to the buffered IO path.  It
is basically a code path that has been unused for years and all it
does is make the logic much more complex to understand.

I'll add that to the commit message....

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>