From: David Balazic <david.balazic@uni-mb.si>
To: chromi@cyberspace.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: scsi vs ide performance on fsync's
Date: Tue, 06 Mar 2001 18:14:15 +0100 [thread overview]
Message-ID: <3AA51AE7.29FAC080@uni-mb.si> (raw)
(( please CC me , not subscribed , david.balazic@uni-mb.si )
Jonathan Morton (chromi@cyberspace.org) wrote :
> The OS needs to know the physical act of writing data has finished before
> it tells the m/board to cut the power - period. Pathological data sets
> included - they are the worst case which every engineer must take into
> account. Out of interest, does Linux guarantee this, in the light of what
> we've uncovered? If so, perhaps it could use the same technique to fix
> fdatasync() and family...
Linux currently ignores write-cache, AFAICT.
Recently I asked a similar question , about flushing drive caches at shutdown :
Subject : "Flusing caches on shutdown"
message archived at :
http://boudicca.tux.org/hypermail/linux-kernel/2001week08/0157.html
Body attached at end of this message.
The answer ( and only reply ) was :
[ archived at : http://boudicca.tux.org/hypermail/linux-kernel/2001week08/0211.html ]
--- begin quote ---
From: Ingo Oeser (ingo.oeser@informatik.tu-chemnitz.de)
On Mon, Feb 19, 2001 at 01:45:57PM +0100, David Balazic wrote:
> It is a good idea IMO to flush the write cache of storage devices
> at shutdown and other critical moments.
Not needed. All device drivers should disable write caches of
their devices, that need another signal than switching it off by
the power button to flush themselves.
> Loosing data at powerdown due to write caches have been reported,
> so this is no a theoretical problems. Also the journaled filesystems
> are safe only in theory if the journal is not stored on non-volatile
> memory, which is not guarantied in the current kernel.
Fine. If users/admins have write caching enabled, they either
know what they do, or should disable it (which is the default for
all mass storage drivers AFAIK).
Hardware Level caching is only good for OSes which have broken
drivers and broken caching (like plain old DOS).
Linux does a good job in caching and cache control at software
level.
Regards
Ingo Oeser
--- end quote ---
My original mail :
--- begin quote ---
(( CC me the replies, as I'm not subscribed to LKML ))
Hi!
It is a good idea IMO to flush the write cache of storage devices
at shutdown and other critical moments.
I browsed through linux-2.4.1 and see no use of the SYNCHRONIZE CACHE
SCSI command ( curiously it is defined in several other files
besides include/scsi/scsi.h , grep returns :
drivers/scsi/pci2000.h:#define SCSIOP_SYNCHRONIZE_CACHE 0x35
drivers/scsi/psi_dale.h:#define SCSIOP_SYNCHRONIZE_CACHE 0x35
drivers/scsi/psi240i.h:#define SCSIOP_SYNCHRONIZE_CACHE 0x35
)
I couldn't find evidence to the use of the equivalent ATA command either
( FLUSH CACHE , command code E7h ).
Also add ATAPI to the list. ( and all other interfaces. I checked just SCSI
and ATA )
Loosing data at powerdown due to write caches have been reported,
so this is no a theoretical problems. Also the journaled filesystems
are safe only in theory if the journal is not stored on non-volatile
memory, which is not guarantied in the current kernel.
What is the official word on this issue ?
I think this is important to the "enterprise" guys, at the least.
Sincerely,
david
PS: CC me , as I'm not subscribed to LKML
--- end quote ---
--
David Balazic
--------------
"Be excellent to each other." - Bill & Ted
- - - - - - - - - - - - - - - - - - - - - -
--
David Balazic
--------------
"Be excellent to each other." - Bill & Ted
- - - - - - - - - - - - - - - - - - - - - -
next reply other threads:[~2001-03-06 17:14 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-06 17:14 David Balazic [this message]
2001-03-06 17:46 ` scsi vs ide performance on fsync's Gregory Maxwell
2001-03-06 18:23 ` Jonathan Morton
2001-03-06 23:27 ` Mark Hahn
[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
-- strict thread matches above, loose matches on Subject: below --
2001-03-07 12:47 David Balazic
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-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
[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-02 17:42 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
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=3AA51AE7.29FAC080@uni-mb.si \
--to=david.balazic@uni-mb.si \
--cc=chromi@cyberspace.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox