linux-kernel - Re: [PATCH] ext2: avoid needless discard of preallocated blocks

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-next>] [day] [month] [year] [list]

Date:	Sat, 19 Aug 2006 22:46:03 -0700
From:	Andrew Morton <akpm@...l.org>
To:	Ron Yorston <rmy@...ress.co.uk>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ext2: avoid needless discard of preallocated blocks

On Thu, 17 Aug 2006 20:45:36 +0100
Ron Yorston <rmy@...ress.co.uk> wrote:

> Currently preallocated blocks in ext2 are discarded on every call
> to iput() (by ext2_put_inode() calling ext2_discard_prealloc()).
> 
> An earlier attempt to fix this ("discard ext2 preallocation in last
> iput") moved the ext2_discard_prealloc() call to ext2_clear_inode(),
> but was found to cause filesystem corruption in a test using fsx.
> The problem was that ext2_clear_inode() was writing the inode data
> to disk before calling ext2_discard_prealloc(), so the value of
> i_blocks on disk included the preallocated blocks.
> 
> This patch moves the call to ext2_discard_prealloc() to the new
> function ext2_drop_inode().  This should be both efficient (discard
> happens on only the last call to iput()) and correct (fixes i_blocks
> before writing to disk).  Also, as there is now possibly a longer
> window during which an open file may have an incorrrect block count
> in its on-disk inode, ext2_update_inode adjusts the block count to
> account for preallocated blocks.

Been there, done that.  The problem was that hanging onto the preallocation
will cause separate files to have up-to-seven-block gaps between them.  So
if you put a large number of small files in the same directory, the time to
read them all back is quite significantly impacted: they cover a lot more
disk.
-
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/