[Top] [All Lists]

Re: patch: double freereq freeing

To: Russell Cattelan <cattelan@xxxxxxxxxxx>
Subject: Re: patch: double freereq freeing
From: Jens Axboe <axboe@xxxxxxx>
Date: Mon, 11 Dec 2000 15:04:32 +0100
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <3A34478B.BCCFB089@xxxxxxxxxxx>; from cattelan@xxxxxxxxxxx on Sun, Dec 10, 2000 at 09:18:36PM -0600
References: <20001210215635.E294@xxxxxxx> <3A33F25C.5E9FAB1C@xxxxxxxxxxx> <20001210222057.F294@xxxxxxx> <3A33F9C8.CD56A6CC@xxxxxxxxxxx> <20001211003152.O294@xxxxxxx> <3A34478B.BCCFB089@xxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
On Sun, Dec 10 2000, Russell Cattelan wrote:
> Jens Axboe wrote:
> > On Sun, Dec 10 2000, Russell Cattelan wrote:
> > > > In any way, I can merge it into the xfs tree if there's an interest.
> > >
> > > I have discovered a corruption problem when using kiobuf io.
> > > I occurs both in the XFS-test11 tree and with your elevator patch.
> > > So it does appear to be the fault of the patch,
> > > although it does occur sooner with the elevator patch in.
> As I sure the above statement doesn't make much sense,
> I meant to say "it does NOT appear" to be the fault of the patch.

Ah, this is indeed how I read it too. Or I would have corrected
you :-)

> > The most likely explanation is probably that blk-xx changes the
> > I/O generated and thus the pattern of how soon / when corruption
> > happens.
> Just to expand on the problem a bit;
> The corruption shows up under heavy load.
> 4 doio files each with 4 processes a piece doing
> different types of io read/write readv/writev and mmap.
> The  corruption always due to  mmap'ed io.
> My best guess at this: Since IO path through uses
> both bufer_head and kio bufs.
> There is a sequence discrepancy, kio buf io may be initiated after a
> buffer_head
> io assuming the buffer head controlled data made it to disk but it may not.

You mean lack of ordering with bh vs kio? Assuming they all make it to
disk eventually, I don't see a specific problem that would cause
corruption there.

> Pagebuf issues a kio buf io write to the disk bypassing all the queues and
> the disk elevator
> etc. etc.. thus "sneaking" a write in before the buffer head io has a
> chance to hit disk.

The kiobuf request will be sequenced just like any other request, unless
it manipulates the queue directly itself (which, without having looked,
I'm assuming it does not. this would be ugly)

> I really have no idea if this is what is happening but every story has to
> have a begging :-)

Right, we'll track it down eventually.

> > rearranged by the elevator. That should completely fix such log
> > starvation issues.
> If you patch proves to be stable enough, we can just pull it into the
> tree.  I appears to clean up some other inefficiencies.

It's stable.

* Jens Axboe <axboe@xxxxxxx>
* SuSE Labs

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