mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jeremy Higdon <jeremy@classic.engr.sgi.com>
To: Daniel Phillips <phillips@bonn-fries.net>,
	James Bottomley <James.Bottomley@SteelEye.com>,
	Chris Mason <mason@suse.com>,
	"Stephen C. Tweedie" <sct@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH] 2.4.x write barriers (updated for ext3)
Date: Mon, 4 Mar 2002 23:09:27 -0800 (PST)	[thread overview]
Message-ID: <10203042309.ZM444102@classic.engr.sgi.com> (raw)
In-Reply-To: Daniel Phillips <phillips@bonn-fries.net> "Re: [PATCH] 2.4.x write barriers (updated for ext3)" (Mar  4,  8:57am)
In-Reply-To: <200202281536.g1SFaqF02079@localhost.localdomain>  <E16hl4R-0000Zx-00@starship.berlin>  <10203032209.ZM424559@classic.engr.sgi.com>  <E16hnLN-0000aV-00@starship.berlin>

On Mar 4,  8:57am, Daniel Phillips wrote:
> 
> On March 4, 2002 07:09 am, Jeremy Higdon wrote:
> > On Mar 4,  6:31am, Daniel Phillips wrote:
> > > On March 4, 2002 05:21 am, Jeremy Higdon wrote:
> > > > I have never heard of
> > > > any implied requirement to flush to media when a drive receives an
> > > > ordered tag and WCE is set.  It does seem like a useful feature to have
> > > > in the standard, but I don't think it's there.
> > > 
> > > It seems to be pretty strongly implied that things should work that way.
> > > What is the use of being sure the write with the ordered tag is on media
> > > if you're not sure about the writes that were supposedly supposed to
> > > precede it?  Spelling this out would indeed be helpful.
> > 
> > WCE==1 and ordered tag means that the data for previous commands is in
> > the drive buffer before the data for the ordered tag is in the drive
> > buffer.
> 
> Right, and what we're talking about is going further and requiring that WCE=0
> and ordered tag means the data for previous commands is *not* in the buffer,
> i.e., on the platter, which is the only interpretation that makes sense.


Sorry to be slow here, but if WCE=0, then commands aren't complete until
data is on the media, so since previous commands don't complete until
data is on the media, and they must complete before the ordered tag
command does, what you say would have to be the case.  I thought the idea
was to buffer commands to drive memory (so that the drive could increase
performance by writing back to back commands without losing a rev) and
then issue a command with a "flush" side effect.

Here is an interesting question.  If you use WCE=1 and then send an
ordered tag with FUA=1, does that imply that data from previous
write commands is flushed to media?  I don't think so, though it
would be a useful feature if it did.

jeremy

  reply	other threads:[~2002-03-05  7:11 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-22 15:57 James Bottomley
2002-02-22 16:10 ` Chris Mason
2002-02-22 16:13 ` Stephen C. Tweedie
2002-02-22 17:36   ` James Bottomley
2002-02-22 18:14     ` Chris Mason
2002-02-28 15:36       ` James Bottomley
2002-02-28 15:55         ` Chris Mason
2002-02-28 17:58           ` Mike Anderson
2002-02-28 18:12         ` Chris Mason
2002-03-01  2:08           ` James Bottomley
2002-03-03 22:11         ` Daniel Phillips
2002-03-04  4:21           ` Jeremy Higdon
2002-03-04  5:31             ` Daniel Phillips
2002-03-04  6:09               ` Jeremy Higdon
2002-03-04  7:57                 ` Daniel Phillips
2002-03-05  7:09                   ` Jeremy Higdon [this message]
2002-03-05 22:56                     ` Daniel Phillips
2002-03-04 16:52                 ` Stephen C. Tweedie
2002-03-04 18:15                   ` Daniel Phillips
2002-03-05  7:40                     ` Jens Axboe
2002-03-05 22:29                       ` Daniel Phillips
2002-03-12  7:01                         ` Jens Axboe
2002-03-10  5:24                   ` Douglas Gilbert
2002-03-11 11:13                     ` Kurt Garloff
2002-03-12  6:58                       ` Jens Axboe
2002-03-13 22:37                         ` Peter Osterlund
2002-03-11 11:34                     ` Stephen C. Tweedie
2002-03-11 17:15                       ` James Bottomley
2002-03-12  1:17                     ` GOTO Masanori
2002-03-04 14:48           ` James Bottomley
2002-03-06 13:59             ` Daniel Phillips
2002-03-06 14:34               ` James Bottomley
2002-03-04  3:34         ` Chris Mason
2002-03-04  5:05           ` Daniel Phillips
2002-03-04 15:03             ` James Bottomley
2002-03-04 17:04               ` Stephen C. Tweedie
2002-03-04 17:35                 ` James Bottomley
2002-03-04 17:48                   ` Chris Mason
2002-03-04 18:11                     ` James Bottomley
2002-03-04 18:41                       ` Chris Mason
2002-03-04 21:34                       ` Stephen C. Tweedie
2002-03-04 18:09                   ` Stephen C. Tweedie
2002-03-04 17:16               ` Chris Mason
2002-03-04 18:05                 ` Stephen C. Tweedie
2002-03-04 18:28                   ` James Bottomley
2002-03-04 19:55                     ` Stephen C. Tweedie
2002-03-04 19:48                   ` Daniel Phillips
2002-03-04 19:57                     ` Stephen C. Tweedie
2002-03-04 21:06                       ` Daniel Phillips
2002-03-05 14:58                         ` Stephen C. Tweedie
2002-03-05  7:48                     ` Jens Axboe
2002-03-04 19:51                 ` Daniel Phillips
2002-03-05  7:42                   ` Jens Axboe
2002-03-04  8:19           ` Helge Hafting
2002-03-04 14:57           ` James Bottomley
2002-03-04 17:24             ` Chris Mason
2002-03-04 19:02               ` Daniel Phillips
2002-03-05  7:22             ` Jeremy Higdon
2002-03-05 23:01               ` Daniel Phillips
2002-02-25 10:57 ` Helge Hafting
2002-02-25 15:04   ` James Bottomley
  -- strict thread matches above, loose matches on Subject: below --
2002-03-01 15:26 Dieter Nützel
2002-03-01 16:00 ` James Bottomley
2002-02-21 23:30 Chris Mason
2002-02-22 14:19 ` Stephen C. Tweedie
2002-02-22 15:26 ` Chris Mason
2002-01-10  9:55 [ANNOUNCE] FUSE: Filesystem in Userspace 0.95 Miklos Szeredi
2002-01-13  3:10 ` Pavel Machek
2002-01-21 10:18 ` Miklos Szeredi
2002-01-23 10:47   ` Pavel Machek
2002-01-22 19:07 ` Daniel Phillips
2002-01-23  2:33   ` [Avfs] " Justin Mason
2002-01-23  5:26     ` Daniel Phillips

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=10203042309.ZM444102@classic.engr.sgi.com \
    --to=jeremy@classic.engr.sgi.com \
    --cc=James.Bottomley@SteelEye.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mason@suse.com \
    --cc=phillips@bonn-fries.net \
    --cc=sct@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®