Messages in this thread | | | Date | Thu, 9 Sep 2004 10:06:12 +0200 | From | Jens Axboe <> | Subject | Re: bug in md write barrier support? |
| |
On Wed, Sep 08 2004, Alan Cox wrote: > On Mer, 2004-09-08 at 16:46, Jens Axboe wrote: > > That's a worry if it really does that - does it, or are you just > > speculating about possible problems? > > I2O defines cache flush very losely. It flushes the cache and returns > when the cache has been flushed. From playing with the controllers I > have it seems some at least merge further queued writes into the output > stream. Thus if I issue > > write 1, 2, 3, 4 , 40, 41, flush cache, write 5, 6, 100 > > it'll write 1,2,3,4,5,6, 40, 41, report flush cache complete. > > Obviously I can implement full barrier semantics in the driver if need > be but that would cost performance hence the question.
Precisely, it's always possible to just drop queueing depth to zero at that point. If I2O really does reorder around the cache flush (this seems broken...), then you probably should.
-- Jens Axboe
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |