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: <20130621210556.GB10582@thunk.org>
Date:	Fri, 21 Jun 2013 17:05:56 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	"Joseph D. Wagner" <joe@...ephdwagner.info>
Cc:	linux-ext4@...r.kernel.org, Ryan Lortie <desrt@...rt.ca>
Subject: Re: ext4 file replace guarantees

On Fri, Jun 21, 2013 at 09:25:13AM -0700, Joseph D. Wagner wrote:
> 
> Please forgive me for the stupid question.  Would Ryan's concerns be
> addressed by configuring ext4 to run in data=journal mode?

It would, but for most workloads, data=journal is much, much slower.

Another option is to use the nodelalloc mount option.  The nodelalloc
option plus the default data=ordered mode will cause an implicit data
integrity writeback of all files that were written at every commit.
This is basically what ext3 did, but it makes fsync()'s painfully slow
since *all* files are getting flushed out, which is what trained so
many application programmers to think fsync() calls needed to be
avoided at all costs.  In addition, it decreases performance both for
writes, and since without delalloc, block allocation tends not to be
as good, for future read operations as well.

We are keeping nodelalloc mode for now, basically so that when the
ext4 code is used to mount filesystems explicitly marked as ext3 in
/etc/fstab (via CONFIG_EXT4_USE_AS_EXT23) we are bug-for-bug
compatible with ext3 at least with respect to delayed allocation and
implied writeback on file system commits.

> I realize that as a programmer he cannot guarantee that his application
> will run on a file system in a particular configuration.  I'm just
> curious as to how this all fits together.

Agreed, and in addition, this is not something we would want to
recommend to users, since they come with significant downsides.

	     	    	       	    	 - Ted
--
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