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]
Date:	Sat, 16 May 2015 20:18:45 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	"Darrick J. Wong" <darrick.wong@...cle.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 02/14] undo-io: write out index block after every write

On Wed, May 13, 2015 at 05:21:21PM -0700, Darrick J. Wong wrote:
> Write out the undo file's index block after writing a block to the
> undo file.  This ensures that we always have a consistent undo file
> in the page cache, even if the program crashes.  When we fill up a
> key block in the undo file, we'll call fsync to force the whole
> thing to storage; this should happen about every 256 blocks given
> the usual 4K block size.
> 
> Signed-off-by: Darrick J. Wong <darrick.wong@...cle.com>

Applied, but I'm not sure calling fsync every 256 blocks is worth it
at all; when mke2fs is writing a 128M journal, it's going to be
writing 32,768 blocks.  If we call fsync every 256 blocks, then we'll
be calling it 128 times during the course of the mke2fs, and this
doesn't count any of the other blocks overwritten by mke2fs.

The fsync() is only going to help in case of power failure --- and if
we only calling it every 256 blocks, we're going to lose data in
anyway.

This patch doesn't appear to change how often we call fsync(2), so
I'll take this, but I think we should seriously think about only
calling fync() if we're closing the undo file.

	       	    		    - 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