linux-kernel - Re: Proposal for "proper" durable fsync() and fdatasync()

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: <47C3C33F.1070908@garzik.org>
Date:	Tue, 26 Feb 2008 02:43:59 -0500
From:	Jeff Garzik <jeff@...zik.org>
To:	Jamie Lokier <jamie@...reable.org>
CC:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	Chris Wedgwood <cw@...f.org>
Subject: Re: Proposal for "proper" durable fsync() and fdatasync()

Jamie Lokier wrote:
> By durable, I mean that fsync() should actually commit writes to
> physical stable storage,

Yes, it should.

> I was surprised that fsync() doesn't do this already.  There was a lot
> of effort put into block I/O write barriers during 2.5, so that
> journalling filesystems can force correct write ordering, using disk
> flush cache commands.
> 
> After all that effort, I was very surprised to notice that Linux 2.6.x
> doesn't use that capability to ensure fsync() flushes the disk cache
> onto stable storage.

It's surprising you are surprised, given that this [lame] fsync behavior 
has remaining consistently lame throughout Linux's history.

[snip huge long proposal]

Rather than invent new APIs, we should fix the existing ones to _really_ 
flush data to physical media.

Linux should default to SAFE data storage, and permit users to retain 
the older unsafe behavior via an option.  It's completely ridiculous 
that we default to an unsafe fsync.

And [anticipating a common response from others] it is completely 
irrelevant that POSIX fsync(2) permits Linux's current behavior.  The 
current behavior is unsafe.

Safety before performance -- ESPECIALLY when it comes to storing user data.

Regards,

	Jeff (Linux ATA driver dude)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/