On Tue, 2007-02-20 at 10:40 -0800, Zach Brown wrote:
> >> There are some strange O_DIRECT corner cases in here such that the
> >> 'last
> >> writer' may actually be a 'last reader' and winning can mean have
> >> a copy
> >> of the page in page cache older than the copy on disk.
> >
> > As long
There are some strange O_DIRECT corner cases in here such that the
'last
writer' may actually be a 'last reader' and winning can mean have
a copy
of the page in page cache older than the copy on disk.
As long as it is marked dirty so that it eventually gets synced to
disk,
it shouldn't ma
On Tue, 2007-02-20 at 11:30 -0500, Trond Myklebust wrote:
> > One option is to have invalidate_inode_pages2_range continue if it can't
> > toss a page but still return something that O_DIRECT ignores (living
> > with the race), but it looks like I can make a launder_page op that does
> > the right
On Tue, 2007-02-20 at 11:08 -0500, Chris Mason wrote:
> On Tue, Feb 20, 2007 at 11:01:50AM -0500, Trond Myklebust wrote:
> > On Mon, 2007-02-19 at 19:21 -0500, Benjamin LaHaise wrote:
> > > On Mon, Feb 19, 2007 at 04:50:48PM -0500, Chris Mason wrote:
> > > > aio is not responsible for this particul
On Tue, Feb 20, 2007 at 05:06:47PM +0100, Arjan van de Ven wrote:
> > We don't try to resolve "conflicting" writes between ordinary mmap() and
> > write(), so why should we be doing it for mmap and O_DIRECT?
> >
> > mmap() is designed to violate the ordinary mutex locks for write(), so
> > if a co
On Tue, Feb 20, 2007 at 11:01:50AM -0500, Trond Myklebust wrote:
> On Mon, 2007-02-19 at 19:21 -0500, Benjamin LaHaise wrote:
> > On Mon, Feb 19, 2007 at 04:50:48PM -0500, Chris Mason wrote:
> > > aio is not responsible for this particular synchronization. Those fixes
> > > (if we make them) shoul
> We don't try to resolve "conflicting" writes between ordinary mmap() and
> write(), so why should we be doing it for mmap and O_DIRECT?
>
> mmap() is designed to violate the ordinary mutex locks for write(), so
> if a conflict arises, whether it be with O_DIRECT or ordinary writes
> then it is
On Tue, Feb 20, 2007 at 11:01:50AM -0500, Trond Myklebust wrote:
> We don't try to resolve "conflicting" writes between ordinary mmap() and
> write(), so why should we be doing it for mmap and O_DIRECT?
Yes we do -- both writes will succeed. More importantly, if one modifies
the first 512 bytes
On Mon, 2007-02-19 at 19:21 -0500, Benjamin LaHaise wrote:
> On Mon, Feb 19, 2007 at 04:50:48PM -0500, Chris Mason wrote:
> > aio is not responsible for this particular synchronization. Those fixes
> > (if we make them) should come from other places. The patch is important
> > to get aio error ha
I have applied the Brown's patch
and run aio-stress O_DIRECT random write 100 times
There is 4% throughput degradation.
47 of 100 aio-stress runs reported an EIO.
1 aio-stress error output example:
adding stage random write
starting with random write
file size 1200MB, record size 16KB, depth 64,
On Mon, Feb 19, 2007 at 07:21:09PM -0500, Benjamin LaHaise wrote:
> On Mon, Feb 19, 2007 at 04:50:48PM -0500, Chris Mason wrote:
> > aio is not responsible for this particular synchronization. Those fixes
> > (if we make them) should come from other places. The patch is important
> > to get aio e
I would argue that one common cause of the EIO is userland
error (mmap concurrent with O_DIRECT), and EIO is the correct answer.
I disagree. That means that using the pagecache to synchronize
things like
the proposed online defragmentation will occasionally make O_DIRECT
users
fail.
Well
On Mon, Feb 19, 2007 at 04:50:48PM -0500, Chris Mason wrote:
> aio is not responsible for this particular synchronization. Those fixes
> (if we make them) should come from other places. The patch is important
> to get aio error handling right.
>
> I would argue that one common cause of the EIO i
On Mon, Feb 19, 2007 at 11:58:16PM +0300, Ananiev, Leonid I wrote:
> > while triggering EIO in invalidate_inode_pages2_range()
> ...
> > With this patch aio-stress sees -EIO.
>
> Actually if invalidate_inode_pages2_range() returns EIO it means
> that internal kernel synchronization conflict was h
I
*think* the patch is right, but picking the changes to the code and
watching
its movement at the same time is making my head spin.
Really? The only things that changed are the assignment from iocb-
>res (after testing pending_err) instead of the 'res' argument and
the dprintk.
But
> while triggering EIO in invalidate_inode_pages2_range()
...
> With this patch aio-stress sees -EIO.
Actually if invalidate_inode_pages2_range() returns EIO it means
that internal kernel synchronization conflict was happen.
It is reported to user as hardware IO error.
Iteration in synchronizatio
On Mon, Feb 19, 2007 at 12:35:27PM -0800, Zach Brown wrote:
> aio: propogate post-EIOCBQUEUED errors to completion event
This patch has to be split in 2 to make it easier to review -- the change
moving the event insertion code for the completion queue should stand
separately, as it is completely
17 matches
Mail list logo
