> > 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.
If both io paths are referencing the same area on disk, and thus
the same page it is conceivable.
One ot the things that doio does to force corruption.
do normal read/write to a certain part of the file making sure
the boundary does not fall on a page and/or fs block boundary
then mmap the file right next the normal io area.
| Page |
^R/W ^ mmap ^
This apparently has exposed a lot of corruption problems, in fact ext2
blows up rather quickly with doio.
> > 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)
It is very possible the problem is in pagebuf itself, and not related to
I've let Chait deal with these thing until this point... guess I need to dig
into the code bit more.
I'm trying to convince one of our linux testers to run the ide patch
through its paces.
Hopefully we'll have some results in a few days.
Thanks for your work in this area.
> > 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