From mboxrd@z Thu Jan  1 00:00:00 1970
From: Valerie Henson <val_henson@linux.intel.com>
Subject: Re: Fix(es) for ext2 fsync bug
Date: Tue, 20 Feb 2007 21:30:16 +0000
Message-ID: <20070220213014.GC5264@nifty>
References: <20070214195453.GB7521@nifty> <20070215142020.GA9930@thunk.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: linux-fsdevel@vger.kernel.org, Can Sar <csar@stanford.edu>,
	Junfeng Yang <junfeng@gmail.com>,
	Dawson Engler <engler@csl.stanford.edu>
To: Theodore Tso <tytso@mit.edu>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from mga06.intel.com ([134.134.136.21]:10747 "EHLO
	orsmga101.jf.intel.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org
	with ESMTP id S1030433AbXBTVaV (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Tue, 20 Feb 2007 16:30:21 -0500
Content-Disposition: inline
In-Reply-To: <20070215142020.GA9930@thunk.org>
Sender: linux-fsdevel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

On Thu, Feb 15, 2007 at 09:20:21AM -0500, Theodore Tso wrote:
> 
> It's actually not the case that fsck will complete the truncate for
> file A.  The problem is that while e2fsck is processing indirect
> blocks in pass 1, the block which is marked as file A's indirect block
> (but which actually contain's file B's data) gets "fixed" when e2fsck
> sees block numbers which look like illegal block numbers.  So this
> ends up corrupting file B's data.

Ah, that's what happens.  Thanks for the clarification.

> This is actually legal end result, BTW, since it's POSIX states the
> result of fsync() is undefined if the system crashes.  Technically

And POSIX also states that sync() is only required to schedule the
writes, but may return before the actual writing is done.  Looks like
the only way you can guarantee data is on-disk according to POSIX is
to reboot the system after every synchronous write.  Man, we file
systems developers sure have it easy!

-VAL