linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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	[thread overview]
Message-ID: <87bprka9sg.fsf@newton.gmurray.org.uk> (raw)

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. 

             reply	other threads:[~2009-03-29 10:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-29 10:43 Graham Murray [this message]
2009-03-29 11:22 ` Zero length files - an alternative approach? Måns Rullgård
2009-03-29 12:02   ` Andreas T.Auer
2009-03-29 12:10     ` Måns Rullgård
2009-03-29 13:49       ` Pavel Machek
2009-03-29 20:16         ` David Newall
2009-03-30 12:41   ` Chris Mason
2009-03-30 14:06     ` Theodore Tso
2009-03-29 16:49 ` Avi Kivity
     [not found] <cl0KI-3zZ-3@gated-at.bofh.it>
     [not found] ` <cl1oA-4El-9@gated-at.bofh.it>
     [not found]   ` <clp6o-91-17@gated-at.bofh.it>
2009-03-30 21:10     ` Bodo Eggert

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=87bprka9sg.fsf@newton.gmurray.org.uk \
    --to=graham@gmurray.org.uk \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).