lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101224085126.2a7ff187@notabene.brown>
Date:	Fri, 24 Dec 2010 08:51:26 +1100
From:	Neil Brown <neilb@...e.de>
To:	Olaf van der Spek <olafvdspek@...il.com>
Cc:	linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org
Subject: Re: Atomic non-durable file write API

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

> On Sun, Dec 19, 2010 at 5:39 PM, Olaf van der Spek <olafvdspek@...il.com> wrote:
> > On Sat, Dec 18, 2010 at 11:15 PM, Calvin Walton <calvin.walton@...il.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ