On Thu, 2010-12-16 at 15:11 -0500, Ric Wheeler wrote:
> On 12/16/2010 07:22 AM, Olaf van der Spek wrote:
> > On Thu, Dec 9, 2010 at 1:03 PM, Olaf van der Spek<olafvdspek@xxxxxxxxx> wrote:
> >> Hi,
> >>
> >> Since the introduction of ext4, some apps/users have had issues with
> >> file corruption after a system crash. It's not a bug in the FS AFAIK
> >> and it's not exclusive to ext4.
> >> Writing a temp file, fsync, rename is often proposed. However, the
> >> durable aspect of fsync isn't always required and this way has other
> >> issues.
> >> What is the recommended way for atomic non-durable (complete) file writes?
> >>
> >> I'm also wondering why FSs commit after open/truncate but before
> >> write/close. AFAIK this isn't necessary and thus suboptimal.
> > Somebody?
> >
> > Olaf
>
> Getting an atomic IO from user space down to storage is not really trivial.
>
> What I think you would have to do is:
>
> (1) understand the alignment and minimum IO size of your target storage device
> which you can get from /sys/block (or libblkid)
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
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.
--
Calvin Walton <calvin.walton@xxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
