linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Morton <chromi@cyberspace.org>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Jeremy Hansen <jeremy@xxedgexx.com>, linux-kernel@vger.kernel.org
Subject: Re: scsi vs ide performance on fsync's
Date: Fri, 9 Mar 2001 11:39:44 +0000	[thread overview]
Message-ID: <l03130321b6ce6fe21a72@[192.168.239.101]> (raw)
In-Reply-To: <Pine.LNX.4.10.10103051957240.778-100000@penguin.transmeta.com>
In-Reply-To: <l03130307b6ca031531fc@[192.168.239.101]>

>> It's pretty clear that the IDE drive(r) is *not* waiting for the physical
>> write to take place before returning control to the user program, whereas
>> the SCSI drive(r) is.
>
>This would not be unexpected.
>
>IDE drives generally always do write buffering. I don't even know if you
>_can_ turn it off. So the drive claims to have written the data as soon as
>it has made the write buffer.
>
>It's definitely not the driver, but the actual drive.

As I suspected.  However, testing shows that many drives, including most
IBMs, do respond to hdparm -W0 which turns write-caching off (some drives
don't, including some Seagates).  There are also drives in existence that
have no cache at all (mostly old sub-1G drives) and some with too little
for this to make a significant difference (the old 1.2G TravelStar in one
of my PowerBooks is an example).

So, is there a way to force (the majority of, rather than all) IDE drives
to wait until it's been truly committed to media?  If so, will this be
integrated into the appropriate parts of the kernel, particularly for
certain members of the sync() family and FS unmounting?

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
big-mail: chromatix@penguinpowered.com
uni-mail: j.d.morton@lancaster.ac.uk

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+
-----END GEEK CODE BLOCK-----



  parent reply	other threads:[~2001-03-09 11:45 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-02 17:42 scsi vs ide performance on fsync's Jeremy Hansen
2001-03-02 18:39 ` Steve Lord
2001-03-02 19:17   ` Chris Mason
2001-03-02 19:25     ` Steve Lord
2001-03-02 19:27       ` Jeremy Hansen
2001-03-02 19:38       ` Chris Mason
2001-03-02 19:41         ` Steve Lord
2001-03-05 13:23         ` Andi Kleen
2001-03-02 19:25     ` Andre Hedrick
2001-03-03  1:55     ` Dan Hollis
2001-03-02 20:56 ` Linus Torvalds
2001-03-06  2:13   ` Jeremy Hansen
2001-03-06  2:25     ` Linus Torvalds
2001-03-06  3:30     ` Jonathan Morton
2001-03-06  4:05       ` Linus Torvalds
2001-03-06  7:03       ` Andre Hedrick
2001-03-06  8:24       ` Jonathan Morton
2001-03-06 12:22         ` Rik van Riel
2001-03-06 14:08         ` Jonathan Morton
2001-03-07 16:50           ` Pavel Machek
2001-03-06 19:41         ` Andre Hedrick
2001-03-07  5:25         ` Jonathan Morton
2001-03-07  6:58           ` Andre Hedrick
2001-03-09 11:39       ` Jonathan Morton [this message]
     [not found] <Pine.LNX.4.33L2.0103021033190.6176-200000@srv2.ecropolis.com>
     [not found] ` <054201c0a33d$55ee5870$e1de11cc@csihq.com>
2001-03-04 20:10   ` Douglas Gilbert
2001-03-04 21:28     ` Ishikawa
2001-03-06  0:11     ` Douglas Gilbert
2001-03-06  5:27 Douglas Gilbert
2001-03-06  5:45 ` Linus Torvalds
2001-03-06  7:12   ` Andre Hedrick
2001-03-06 12:09     ` Alan Cox
2001-03-06 18:44       ` Linus Torvalds
2001-03-07 13:48         ` Stephen C. Tweedie
2001-03-07 14:13           ` Jens Axboe
2001-03-12 18:50           ` Andre Hedrick
2001-03-06 13:50     ` Mike Black
2001-03-06 16:02       ` Jeremy Hansen
2001-03-07 18:27         ` Jeremy Hansen
2001-03-07 18:36           ` Linus Torvalds
2001-03-08 11:06             ` Stephen C. Tweedie
2001-03-06 16:57       ` Jonathan Morton
2001-03-06  6:43 ` Jonathan Morton
2001-03-06 13:03   ` dean gaudet
2001-03-06 13:15     ` dean gaudet
2001-03-06 13:45     ` Jonathan Morton
2001-03-06 17:14 David Balazic
2001-03-06 17:46 ` Gregory Maxwell
2001-03-06 18:23 ` Jonathan Morton
2001-03-06 23:27   ` Mark Hahn
2001-03-06 19:42 David Balazic
2001-03-06 20:37 ` Jens Axboe
2001-03-07 13:51   ` Stephen C. Tweedie
2001-03-07 14:12     ` Jens Axboe
2001-03-07 15:05       ` Stephen C. Tweedie
2001-03-07 18:51         ` Jens Axboe
2001-03-07 19:10           ` Stephen C. Tweedie
2001-03-07 20:15             ` Jens Axboe
2001-03-07 20:56               ` Stephen C. Tweedie
2001-03-07 20:59                 ` Jens Axboe
2001-03-08 15:45                 ` Chris Mason
2001-03-07 12:47 David Balazic
     [not found] <1epyyz1.etswlv1kmicnqM%smurf@noris.de>
2001-03-09  6:59 ` Matthias Urlichs
2001-03-09 11:51   ` Jens Axboe
2001-03-09 14:26     ` Matthias Urlichs

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='l03130321b6ce6fe21a72@[192.168.239.101]' \
    --to=chromi@cyberspace.org \
    --cc=jeremy@xxedgexx.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.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;
as well as URLs for NNTP newsgroup(s).