From: Graham Murray <graham@gmurray.org.uk>
To: linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Zero length files - an alternative approach?
Date: Sun, 29 Mar 2009 11:43:59 +0100
Message-ID: <87bprka9sg.fsf@newton.gmurray.org.uk>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1382
Lines: 31

Just a thought on the ongoing discussion of dataloss with ext4 vs ext3.

Taking the common scenario:
Read oldfile
create newfile file
write newfile data
close newfile
rename newfile to oldfile

When using this scenario, the application writer wants to ensure that
either the old or new content are present. With delayed allocation, this
can lead to zero length files. Most of the suggestions on how to address
this have involved syncing the data either before the rename or making
the rename sync the data.

What about, instead of 'bringing forward' the allocation and flushing of
the data, would it be possible to instead delay the rename until after
the blocks for newfile have been allocated and the data buffers flushed?
This would keep the performance benefits of delayed allocation etc and
also satisfy the applications developers' apparent dislike of using
fsync(). It would give better performance that syncing the data at
rename time (either using fsync() or automatically) and satisfy the
requirements that either the old or new content is present.

I am not a filesystem developer, so do not know how feasible this would
be. 
--
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/