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.
> The most likely explanation is probably that blk-xx changes the
> I/O generated and thus the pattern of how soon / when corruption
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
io assuming the buffer head controlled data made it to disk but it may not.
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.
I really have no idea if this is what is happening but every story has to
have a begging :-)
> > Currently our doio test can completely starve out log requests,
> > thus by blocking out any new file system activity.
> > Your patch does a good job of clean up the starvation problem so
> > yes we do want to incorporate it.
> We can easily do a small patch that enables log writes to not be
> 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.
> > We do need to figure out were the corruption is coming from
> > first.
> Of course.
> * Jens Axboe <axboe@xxxxxxx>
> * SuSE Labs