Messages in this thread | | | Date | Wed, 8 Sep 2004 17:46:08 +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 10:23, Jens Axboe wrote: > > That is correct. The current definition is to ensure that previously > > sent writes are on disk. I hope to tie a range to it in the future, for > > devices that can optimize the flush in that case. So for ide with write > > back caching, it's currently a FLUSH_CACHE command. Ditto for SCSI. SCSI > > with write through cache can make it a noop as well. > > Some semantics questions I have thinking about it from the I2O and > aacraid side: You talk about it as a barrier. Can other I/O cross the > cache flush ? In other words if I issue a flush_cache and continue doing > I/O the flush will finish when the I/O outstanding at that time has > completed but other I/O may get scheduled to disk first.
That's a worry if it really does that - does it, or are you just speculating about possible problems?
> Secondly what are the intended semantics for a flush error ?
It's up to the issue. For IDE it would ideally be issuing FLUSH_CACHE repeatedly until it doesn't error anymore, but keeping track of the error location. Come to think of it, we should pass down the range right now to flag which range we are actually interested in being errored on.
-- 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/
| |