From: Daniel Phillips <phillips@bonn-fries.net>
To: Chris Wedgwood <cw@f00f.org>, "Justin T. Gibbs" <gibbs@scsiguy.com>
Cc: Jonathan Lundell <jlundell@pobox.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Andrew Morton <andrewm@uow.edu.au>,
Andreas Dilger <adilger@turbolinux.com>,
"Albert D. Cahalan" <acahalan@cs.uml.edu>,
Ben LaHaise <bcrl@redhat.com>,
Ragnar Kjxrstad <kernel@ragnark.vestdata.no>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
mike@bigstorage.com, kevin@bigstorage.com, linux-lvm@sistina.com
Subject: [linux-lvm] Re: [PATCH] 64 bit scsi read/write
Date: Mon, 16 Jul 2001 15:19:39 +0200 [thread overview]
Message-ID: <01071615193905.06482@starship> (raw)
In-Reply-To: <20010716205633.G11938@weta.f00f.org>
On Monday 16 July 2001 10:56, Chris Wedgwood wrote:
> On Sun, Jul 15, 2001 at 11:47:10AM -0600, Justin T. Gibbs wrote:
>
> Simply disabling the write cache does not guarantee the order of
> writes. For one, with tagged I/O and the use of the SIMPLE_Q tag
> qualifier, commands may be completed in any order. If you want
> some semblance of order, either disable the write cache or use
> the FUA bit in all writes, and use the ORDERED tag qualifier. Even
> when using these options, it is not clear that the drive cannot
> reorder writes "slightly" to make track writes more efficient (e.g.
> two separate commands to write sequential sectors on the same track
> may be written in reverse order).
>
> ORDERED sounds like the trick... I assume this is some kind of
> write-barrier? If so, then I assume it has some kind of strict
> temporal ordering, even between command issues to the drive.
>
> If so, that would be idea if we can have the fs communicate this all
> the way down to the device layer, making it work for soft-raid and
> LVM be a little harder perhaps.
There was general agreement amongst filesystem developers at San Jose
that we need some kind of internal interface at the filesystem level
for this, independent of the type of underlying block device - IDE,
SCSI or "other". That's as far as it got.
--
Daniel
next prev parent reply other threads:[~2001-07-16 13:19 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20010703065312.J4841@vestdata.no>
[not found] ` <Pine.LNX.4.33.0107032211120.30968-100000@toomuch.toronto.redhat.com>
2001-07-05 6:34 ` [linux-lvm] Re: [PATCH] 64 bit scsi read/write Ragnar Kjørstad
2001-07-05 7:35 ` Ben LaHaise
2001-07-05 16:46 ` AJ Lewis
2001-07-05 17:09 ` Eric M. Hopper
2001-07-10 13:45 ` Heinz J. Mauelshagen
2001-07-13 18:20 ` Albert D. Cahalan
2001-07-13 20:41 ` Andreas Dilger
2001-07-13 21:14 ` Alan Cox
2001-07-14 3:23 ` Andrew Morton
2001-07-14 8:45 ` Alan Cox
2001-07-14 13:54 ` Steven Lembark
2001-07-14 17:33 ` Jonathan Lundell
[not found] ` <20010715160247.I7624@weta.f00f.org>
2001-07-15 5:46 ` Jonathan Lundell
[not found] ` <20010715025001.B6722@weta.f00f.org>
2001-07-14 15:41 ` Jonathan Lundell
2001-07-14 20:11 ` Daniel Phillips
2001-07-15 1:21 ` Andrew Morton
2001-07-15 1:53 ` Daniel Phillips
[not found] ` <20010715153607.A7624@weta.f00f.org>
2001-07-15 6:05 ` John Alvord
[not found] ` <20010715180752.B7993@weta.f00f.org>
2001-07-15 13:16 ` Ken Hirsch
2001-07-15 22:14 ` Daniel Phillips
2001-07-17 0:31 ` Juan Quintela
2001-07-15 13:44 ` Daniel Phillips
[not found] ` <20010716023911.A10576@weta.f00f.org>
2001-07-15 15:06 ` Jonathan Lundell
[not found] ` <20010716032220.B10635@weta.f00f.org>
2001-07-15 17:44 ` Jonathan Lundell
2001-07-15 17:47 ` Justin T. Gibbs
2001-07-15 23:14 ` Rod Van Meter
[not found] ` <20010716205633.G11938@weta.f00f.org>
2001-07-16 13:19 ` Daniel Phillips [this message]
2001-07-16 14:26 ` Heinz J. Mauelshagen
2001-07-15 15:32 ` Alan Cox
[not found] <20010714090703.B5737@weta.f00f.org>
2001-07-13 22:04 ` Andreas Dilger
2001-07-14 0:49 ` Jonathan Lundell
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=01071615193905.06482@starship \
--to=phillips@bonn-fries.net \
--cc=acahalan@cs.uml.edu \
--cc=adilger@turbolinux.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andrewm@uow.edu.au \
--cc=bcrl@redhat.com \
--cc=cw@f00f.org \
--cc=gibbs@scsiguy.com \
--cc=jlundell@pobox.com \
--cc=kernel@ragnark.vestdata.no \
--cc=kevin@bigstorage.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-lvm@sistina.com \
--cc=mike@bigstorage.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