linux-ext4 - Re: [PATCH, RFC] ext4: Automatically allocate delay allocated blocks on close

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: <20090224132103.GC1362@mit.edu>
Date:	Tue, 24 Feb 2009 08:21:03 -0500
From:	Theodore Tso <tytso@....edu>
To:	Andreas Dilger <adilger@....com>
Cc:	linux-ext4@...r.kernel.org, aneesh.kumar@...ux.vnet.ibm.com
Subject: Re: [PATCH, RFC] ext4: Automatically allocate delay allocated
	blocks on close

On Tue, Feb 24, 2009 at 03:13:44AM -0700, Andreas Dilger wrote:
> On Feb 24, 2009  00:05 -0500, Theodore Ts'o wrote:
> > When closing a file that had been previously truncated, force any
> > delay allocated blocks that to be allocated so that if the filesystem
> > is mounted with data=ordered, the data blocks will be pushed out to
> > disk along with the journal commit.  Many application programs expect
> > this, so we do this to avoid zero length files if the system crashes
> > unexpectedly.
> 
> Should this only be done with "truncate-to-zero" operations, or any
> truncate?  Some applications may do extending truncates in order to
> trigger file preallocation ala Windows, and we don't necessarily want
> to punish all of the IO for those files.

Agreed, we should only do this on a truncate-to-zero.  I'll fix up the
patch to only set EXT4_STATE_DA_ALLOC_CLOSE on truncate if
inode->i_size is 0.

							- 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