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
| ||
|
Message-ID: <1292710543.17128.14.camel@nayuki> Date: Sat, 18 Dec 2010 17:15:43 -0500 From: Calvin Walton <calvin.walton@...il.com> To: Ric Wheeler <ricwheeler@...il.com> Cc: Olaf van der Spek <olafvdspek@...il.com>, linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org Subject: Re: Atomic non-durable file write API 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@...il.com> 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@...il.com> -- 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