From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Jens Axboe <axboe@suse.de>
Cc: Neil Brown <neilb@cse.unsw.edu.au>,
Christoph Hellwig <hch@lst.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: bug in md write barrier support?
Date: Wed, 08 Sep 2004 14:35:01 +0100 [thread overview]
Message-ID: <1094650500.11723.32.camel@localhost.localdomain> (raw)
In-Reply-To: <20040908092309.GD2258@suse.de>
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.
Secondly what are the intended semantics for a flush error ?
next prev parent reply other threads:[~2004-09-08 14:38 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-03 17:24 bug in md write barrier support? Christoph Hellwig
2004-09-04 0:56 ` Neil Brown
2004-09-04 8:21 ` Jens Axboe
2004-09-06 1:36 ` Neil Brown
2004-09-08 9:23 ` Jens Axboe
2004-09-08 13:35 ` Alan Cox [this message]
2004-09-08 15:46 ` Jens Axboe
2004-09-08 22:21 ` Alan Cox
2004-09-09 8:06 ` Jens Axboe
2004-09-09 8:22 ` Arjan van de Ven
2004-09-09 8:29 ` Jens Axboe
2004-09-09 12:51 ` Alan Cox
2004-09-09 14:34 ` Jens Axboe
2004-09-12 17:13 ` Rogier Wolff
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1094650500.11723.32.camel@localhost.localdomain \
--to=alan@lxorguk.ukuu.org.uk \
--cc=axboe@suse.de \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@cse.unsw.edu.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.