From: "Stephen C. Tweedie" <sct@redhat.com>
To: Pascal Schmidt <pleasure.and.pain@web.de>
Cc: "Stephen C. Tweedie" <sct@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: ReiserFS data corruption in very simple configuration
Date: Thu, 4 Oct 2001 12:02:00 +0100 [thread overview]
Message-ID: <20011004120200.B2226@redhat.com> (raw)
In-Reply-To: <20011003171703.B5209@redhat.com> <Pine.LNX.4.33.0110032202560.26021-100000@neptune.sol.net>
In-Reply-To: <Pine.LNX.4.33.0110032202560.26021-100000@neptune.sol.net>; from pleasure.and.pain@web.de on Wed, Oct 03, 2001 at 10:06:58PM +0200
Hi,
On Wed, Oct 03, 2001 at 10:06:58PM +0200, Pascal Schmidt wrote:
> On Wed, 3 Oct 2001, Stephen C. Tweedie wrote:
>
> > ext3 with ordered data writes has performance nearly up to the level
> > of the fast-and-loose writeback mode for most workloads, and still
> > avoids ever exposing stale disk blocks after a crash.
> What if the machine crashes with parts of the data blocks written to
> disk, before the commit block gets submitted to the drive?
In most cases, users write data by extending off the end of a file.
Only in a few cases (such as databases) do you ever write into the
middle of an existing file. Even overwriting an existing file is done
by first truncating the file and then extending it again.
If you crash during such an extend, then the data blocks may have been
partially written, but the extend will not have been, so the
incompletely-written data blocks will not be part of any file.
The *only* way to get mis-ordered data blocks in ordered mode after a
crash is if you are overwriting in the middle of an existing file. In
such a case there is no absolute guarantee about write ordering unless
you use fsync() or O_SYNC to force writes in a particular order.
In journaled data mode, even mid-file overwrites will be strictly
ordered after a crash.
Cheers,
Stephen
prev parent reply other threads:[~2001-10-04 11:01 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-22 10:00 ReiserFS data corruption in very simple configuration foner-reiserfs
2001-09-22 12:47 ` Nikita Danilov
2001-09-22 20:44 ` foner-reiserfs
2001-09-25 13:28 ` Stephen C. Tweedie
2001-09-29 4:44 ` Lenny Foner
2001-09-29 12:52 ` [reiserfs-list] " Lehmann
2001-10-01 1:00 ` foner-reiserfs
2001-10-01 1:26 ` Lehmann
2001-10-01 2:32 ` foner-reiserfs
2001-10-03 16:28 ` Toby Dickenson
2001-10-01 11:30 ` Stephen C. Tweedie
2001-09-24 9:25 ` [reiserfs-list] " Jens Benecke
2001-10-14 14:52 ` Chris Mason
2001-10-14 18:19 ` Jens Benecke
2001-10-14 20:04 ` Hans Reiser
2001-10-14 23:32 ` Bernd Eckenfels
2001-09-25 20:13 ` Mike Fedyk
2001-09-26 14:43 ` Stephen C. Tweedie
2001-10-01 3:38 ` Mike Fedyk
2001-10-03 16:14 ` Stephen C. Tweedie
2001-10-01 15:27 ` Hans Reiser
2001-10-03 16:17 ` Stephen C. Tweedie
2001-10-03 20:06 ` Pascal Schmidt
2001-10-04 11:02 ` Stephen C. Tweedie [this message]
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=20011004120200.B2226@redhat.com \
--to=sct@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pleasure.and.pain@web.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