From: "Stephen C. Tweedie" <sct@redhat.com>
To: Andre Hedrick <andre@linux-ide.org>
Cc: "Stephen C. Tweedie" <sct@redhat.com>,
David Woodhouse <dwmw2@infradead.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Anders Eriksson <aer-list@mailandnews.com>,
linux-kernel@vger.kernel.org
Subject: Re: sync & asyck i/o
Date: Tue, 6 Feb 2001 23:21:19 +0000 [thread overview]
Message-ID: <20010206232119.K1167@redhat.com> (raw)
In-Reply-To: <20010206181808.I1167@redhat.com> <Pine.LNX.4.10.10102061122530.2273-100000@master.linux-ide.org>
In-Reply-To: <Pine.LNX.4.10.10102061122530.2273-100000@master.linux-ide.org>; from andre@linux-ide.org on Tue, Feb 06, 2001 at 11:25:00AM -0800
Hi,
On Tue, Feb 06, 2001 at 11:25:00AM -0800, Andre Hedrick wrote:
> On Tue, 6 Feb 2001, Stephen C. Tweedie wrote:
> > No, we simply omit to instruct them to enable write-back caching.
> > Linux assumes that the WCE (write cache enable) bit in a disk's
> > caching mode page is zero.
>
> You can not be so blind to omit the command.
Linux has traditionally ignored the issue. Don't ask me to defend it
--- the last advice I got from anybody who knew SCSI well was that
SCSI disks were defaulting to WCE-disabled.
Note that disabling SCSI WCE doesn't disable the cache, it just
enforces synchronous completion. With tagged command queuing,
writeback caching doesn't necessarily mean a huge performance
increase. But if WCE is being enabled by default on modern SCSI
drives, then that's something which the scsi stack really does need to
fix --- the upper block layers will most definitely break if we have
WCE enabled and we don't set force-unit-access on the scsi commands.
The ll_rw_block interface is perfectly clear: it expects the data to
be written to persistent storage once the buffer_head end_io is
called. If that's not the case, somebody needs to fix the lower
layers.
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2001-02-06 23:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-06 14:24 sync & asyck i/o Anders Eriksson
2001-02-06 14:52 ` Alan Cox
2001-02-06 17:34 ` Stephen C. Tweedie
2001-02-06 18:00 ` Ben LaHaise
2001-02-06 18:21 ` Daniel Phillips
2001-02-06 17:51 ` Josh Myer
2001-02-06 17:56 ` Alan Cox
2001-02-06 17:54 ` David Woodhouse
2001-02-06 18:18 ` Stephen C. Tweedie
2001-02-06 19:25 ` Andre Hedrick
2001-02-06 23:21 ` Stephen C. Tweedie [this message]
2001-02-07 0:42 ` Andre Hedrick
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=20010206232119.K1167@redhat.com \
--to=sct@redhat.com \
--cc=aer-list@mailandnews.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andre@linux-ide.org \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
/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.