Message-ID: <49356EF2.7060806@nortel.com>
Date: Tue, 02 Dec 2008 11:22:58 -0600
From: "Chris Friesen" <cfriesen@nortel.com>
User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513)
MIME-Version: 1.0
To: Theodore Tso <tytso@mit.edu>
CC: Pavel Machek <pavel@suse.cz>, mikulas@artax.karlin.mff.cuni.cz,
       clock@atrey.karlin.mff.cuni.cz,
       kernel list <linux-kernel@vger.kernel.org>, aviro@redhat.com
Subject: Re: writing file to disk: not as easy as it looks
References: <20081202094059.GA2585@elf.ucw.cz> <20081202140439.GF16172@mit.edu> <20081202152618.GA1646@ucw.cz> <20081202163720.GB18162@mit.edu>
In-Reply-To: <20081202163720.GB18162@mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 961
Lines: 22

Theodore Tso wrote:

> Even for ext3/ext4 which is doing physical journalling, it's still the
> case that the journal commits first, and it's only later when the
> write happens that we write out the change.  If the disk fails some of
> the writes, it's possible to lose data, especially if the two blocks
> involved in the node split are far apart, and the write to the
> existing old btree block fails.

Yikes.  I was under the impression that once the journal hit the platter 
then the data were safe (barring media corruption).

It seems like the more I learn about filesystems, the more failure modes 
there are and the fewer guarantees can be made.  It's amazing that 
things work as well as they do...

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/