From: Greg Stark <gsstark@mit.edu>
To: Matthias Andree <matthias.andree@gmx.de>
Cc: Greg Stark <gsstark@mit.edu>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
Arjan van de Ven <arjan@infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux does not care for data integrity (was: Disk write cache)
Date: 30 May 2005 02:04:46 -0400 [thread overview]
Message-ID: <87is11xn9d.fsf@stark.xeocode.com> (raw)
In-Reply-To: <20050529211610.GA2105@merlin.emma.line.org>
Matthias Andree <matthias.andree@gmx.de> writes:
> On Sun, 29 May 2005, Greg Stark wrote:
>
> > They meet this requirement just fine on SCSI drives (where write caching
> > generally ships disabled) and on any OS where fsync issues a cache flush. If
>
> I don't know what facts "generally ships disabled" is based on, all of
> the more recent SCSI drives (non SCA type though) I acquired came with
> write cache enabled and some also with queue algorithm modifier set to 1.
People routinely post "Why does this cheap IDE drive outperform my shiny new
high end SCSI drive?" questions to the postgres mailing list. To which people
point out the IDE numbers they've presented are physically impossible for a
7200 RPM drive and the SCSI numbers agree appropriately with an average
rotational latency calculated from whatever speed their SCSI drives are.
> > Worse, if the disk flushes the data to disk out of order it's quite
> > likely the entire database will be corrupted on any simple power
> > outage. I'm not clear whether that's the case for any common drives.
>
> It's a matter of enforcing write order. In how far such ordering
> constraints are propagated by file systems, VFS layer, down to the
> hardware, is the grand question.
Well guaranteeing write order will at least mean the database isn't complete
garbage after a power event.
It still means lost transactions, something that isn't going to be acceptable
for any real-life business where those transactions are actual dollars.
--
greg
next prev parent reply other threads:[~2005-05-30 6:05 UTC|newest]
Thread overview: 142+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-13 5:51 Hyper-Threading Vulnerability Gabor MICSKO
2005-05-13 12:47 ` Barry K. Nathan
2005-05-13 14:10 ` Jeff Garzik
2005-05-13 14:23 ` Daniel Jacobowitz
2005-05-13 14:32 ` Jeff Garzik
2005-05-13 17:13 ` Andy Isaacson
2005-05-13 18:30 ` Vadim Lobanov
2005-05-13 19:02 ` Andy Isaacson
2005-05-15 9:31 ` Adrian Bunk
2005-05-13 17:14 ` Gabor MICSKO
2005-05-13 20:23 ` Barry K. Nathan
2005-05-13 18:03 ` Andi Kleen
2005-05-13 18:34 ` Eric Rannaud
2005-05-13 18:35 ` Alan Cox
2005-05-13 18:49 ` Scott Robert Ladd
2005-05-13 19:08 ` Andi Kleen
2005-05-13 19:36 ` Grant Coady
2005-05-16 17:00 ` Linus Torvalds
2005-05-16 12:37 ` Tommy Reynolds
2005-05-18 19:07 ` Bill Davidsen
2005-05-13 18:38 ` Richard F. Rebel
2005-05-13 19:05 ` Andi Kleen
2005-05-13 21:26 ` Andy Isaacson
2005-05-13 21:59 ` Matt Mackall
2005-05-13 22:47 ` Alan Cox
2005-05-13 23:00 ` Lee Revell
2005-05-13 23:27 ` Dave Jones
2005-05-13 23:38 ` Lee Revell
2005-05-13 23:44 ` Dave Jones
2005-05-14 7:37 ` Lee Revell
2005-05-14 15:33 ` Andrea Arcangeli
2005-05-15 1:07 ` Christer Weinigel
2005-05-15 9:48 ` Andi Kleen
2005-05-14 15:23 ` Alan Cox
2005-05-14 15:45 ` andrea
2005-05-15 13:38 ` Mikulas Patocka
2005-05-16 7:06 ` andrea
2005-05-14 16:30 ` Lee Revell
2005-05-14 16:44 ` Arjan van de Ven
2005-05-14 17:56 ` Lee Revell
2005-05-14 18:01 ` Arjan van de Ven
2005-05-14 19:21 ` Lee Revell
2005-05-14 19:48 ` Arjan van de Ven
2005-05-14 23:40 ` Lee Revell
2005-05-15 7:30 ` Arjan van de Ven
2005-05-15 20:41 ` Alan Cox
2005-05-15 20:48 ` Arjan van de Ven
2005-05-15 21:10 ` Lee Revell
2005-05-15 22:55 ` Dave Jones
2005-05-15 23:10 ` Lee Revell
2005-05-16 7:25 ` Arjan van de Ven
2005-05-15 9:37 ` Andi Kleen
2005-05-15 3:19 ` dean gaudet
2005-05-15 10:01 ` Andi Kleen
2005-05-15 10:23 ` 2.6.4 timer and helper functions kernel
2005-05-19 0:38 ` George Anzinger
2005-05-15 9:33 ` Hyper-Threading Vulnerability Adrian Bunk
2005-05-14 17:04 ` Jindrich Makovicka
2005-05-14 18:27 ` Lee Revell
2005-05-15 9:58 ` Andi Kleen
2005-05-14 0:39 ` dean gaudet
2005-05-16 13:41 ` Andrea Arcangeli
2005-05-15 9:43 ` Andi Kleen
2005-05-15 18:42 ` David Schwartz
2005-05-15 18:56 ` Dr. David Alan Gilbert
2005-05-16 7:10 ` Eric W. Biederman
2005-05-16 11:04 ` Andi Kleen
2005-05-16 19:14 ` Eric W. Biederman
2005-05-16 20:05 ` Valdis.Kletnieks
2005-05-15 14:00 ` Mikulas Patocka
2005-05-15 14:26 ` Andi Kleen
2005-05-13 23:32 ` Paul Jakma
2005-05-14 16:29 ` Paul Jakma
2005-05-13 19:14 ` Jim Crilly
2005-05-13 20:18 ` Barry K. Nathan
2005-05-13 23:14 ` Jim Crilly
2005-05-13 19:16 ` Diego Calleja
2005-05-13 19:42 ` Frank Denis (Jedi/Sector One)
2005-05-15 9:54 ` Andi Kleen
2005-05-15 13:51 ` Mikulas Patocka
2005-05-15 14:12 ` Andi Kleen
2005-05-15 14:21 ` Mikulas Patocka
2005-05-15 14:52 ` Tomasz Torcz
2005-05-15 15:00 ` Disk write cache (Was: Hyper-Threading Vulnerability) Mikulas Patocka
2005-05-15 15:21 ` Gene Heskett
2005-05-15 15:29 ` Jeff Garzik
2005-05-15 16:27 ` Disk write cache Kenichi Okuyama
2005-05-15 16:43 ` Jeff Garzik
2005-05-15 16:50 ` Kyle Moffett
2005-05-15 16:56 ` Andi Kleen
2005-05-15 20:44 ` Andrew Morton
2005-05-15 23:31 ` Cache based insecurity/CPU cache/Disk Cache Tradeoffs Brian O'Mahoney
2005-05-15 16:58 ` Disk write cache Mikulas Patocka
2005-05-15 17:20 ` Kenichi Okuyama
2005-05-16 11:02 ` Linux does not care for data integrity (was: Disk write cache) Matthias Andree
2005-05-16 11:12 ` Arjan van de Ven
2005-05-16 11:29 ` Matthias Andree
2005-05-16 14:02 ` Arjan van de Ven
2005-05-16 14:48 ` Matthias Andree
2005-05-16 15:06 ` Alan Cox
2005-05-16 15:40 ` Matthias Andree
2005-05-16 18:04 ` Alan Cox
2005-05-16 19:11 ` Linux does not care for data integrity Florian Weimer
2005-05-29 21:02 ` Linux does not care for data integrity (was: Disk write cache) Greg Stark
2005-05-29 21:16 ` Matthias Andree
2005-05-30 6:04 ` Greg Stark [this message]
2005-05-30 8:21 ` Matthias Andree
2005-06-01 19:02 ` Linux does not care for data integrity Bill Davidsen
2005-06-01 22:02 ` Matthias Andree
2005-06-02 0:12 ` Bill Davidsen
2005-06-02 0:36 ` Jeff Garzik
2005-06-02 1:37 ` Bill Davidsen
2005-06-02 1:54 ` Jeff Garzik
2005-06-02 8:53 ` Helge Hafting
2005-06-02 12:00 ` Bill Davidsen
2005-06-02 13:33 ` Lennart Sorensen
2005-06-04 13:37 ` Bill Davidsen
2005-06-04 15:31 ` Bernd Eckenfels
2005-05-16 14:57 ` Linux does not care for data integrity (was: Disk write cache) Alan Cox
2005-05-16 13:48 ` Linux does not care for data integrity Mark Lord
2005-05-16 14:59 ` Matthias Andree
2005-05-16 1:56 ` Disk write cache (Was: Hyper-Threading Vulnerability) Gene Heskett
2005-05-16 2:11 ` Jeff Garzik
2005-05-16 2:24 ` Mikulas Patocka
2005-05-16 3:05 ` Gene Heskett
2005-05-16 2:32 ` Mark Lord
2005-05-16 3:08 ` Gene Heskett
2005-05-16 13:44 ` Mark Lord
2005-05-18 4:03 ` Eric D. Mudama
2005-05-15 16:24 ` Mikulas Patocka
2005-05-16 11:18 ` Matthias Andree
2005-05-16 14:33 ` Jeff Garzik
2005-05-16 15:26 ` Richard B. Johnson
2005-05-16 16:00 ` [OT] drive behavior on power-off (was: Disk write cache) Matthias Andree
2005-05-16 18:11 ` Disk write cache (Was: Hyper-Threading Vulnerability) Valdis.Kletnieks
2005-05-16 14:54 ` Alan Cox
2005-05-17 13:15 ` Bill Davidsen
2005-05-17 21:41 ` Kyle Moffett
2005-05-18 4:06 ` Eric D. Mudama
2005-05-15 21:38 ` Tomasz Torcz
2005-05-16 14:50 ` Alan Cox
2005-05-15 15:00 ` Hyper-Threading Vulnerability Arjan van de Ven
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=87is11xn9d.fsf@stark.xeocode.com \
--to=gsstark@mit.edu \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthias.andree@gmx.de \
/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