Re: Atomic non-durable file write API

[Neil Brown <neilb@suse.de>]

On Thu, 23 Dec 2010 16:49:53 +0100 Olaf van der Spek <olafvdspek@gmail.com>
wrote:

> On Sun, Dec 19, 2010 at 5:39 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> > On Sat, Dec 18, 2010 at 11:15 PM, Calvin Walton <calvin.walton@gmail.com> wrote:
> >> Hmm. I’m doing a little interpretation of what Olaf said here; but I
> >> think you may have misunderstood the question?
> >>
> >> He doesn’t care about whether or not the file is securely written to
> >> disk (durable); however he doesn’t want to see any partially written
> >> files. In other words, something like
> >>
> >>     1. Write to temp file
> >>     2. Rename temp file over original file
> >
> > Meta data, including file owner, should be preserved.
> > Ideally, no temp files should be visible either.
> >
> >> Where the rename is only committed to disk once the entire contents of
> >> the file have been written securely – whenever that may eventually
> >> happen.
> >>
> >> He doesn’t want to synchronously wait for the file to be written,
> >> because the new data isn’t particularly important. The only important
> >> thing is that the file either contains the old or new data after a
> >> filesystem crash; not incomplete data. So, it’s more of an ordering
> >> problem, I think? (Analogous to putting some sort of barrier between the
> >> file write/close and the file rename to maintain ordering.)
> >>
> >> Hopefully I’ve interpreted the original question correctly, because this
> >> is something I would find interesting as well.
> >
> > Yes, you did.
> 
> Somebody?
> 

You are asking for something that doesn't exist, which is why no-one can tell
you want the answer is.

The only mechanism for synchronising different filesystem operations is
fsync.  You should use that.

If it is too slow, use data journalling, and place your journal on a
small low-latency device (NVRAM??)

NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html