linux-ext4 - Re: [PATCH v3]Ext4: journal credits reservation fixes for DIO, fallocate and delalloc writepages

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: <20080801191015.GH8654@mit.edu>
Date:	Fri, 1 Aug 2008 15:10:15 -0400
From:	Theodore Tso <tytso@....edu>
To:	Mingming Cao <cmm@...ibm.com>
Cc:	Frédéric Bohé <frederic.bohe@...l.net>,
	Shehjar Tikoo <shehjart@....unsw.edu.au>,
	linux-ext4@...r.kernel.org,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	Andreas Dilger <adilger@....com>
Subject: Re: [PATCH v3]Ext4: journal credits reservation fixes for DIO,
	fallocate and delalloc writepages

On Fri, Aug 01, 2008 at 11:03:15AM -0700, Mingming Cao wrote:
> 
> 在 2008-08-01五的 01:49 -0400，Theodore Tso写道：

Playing with the Chinese I18N support, I see?  :-)

Hmm....

> 在 2008-08-01五的 01:49 -0400，曹子德  写道：

> But, ext4_delete_inode()'s transaction and ext4_truncate()'s transaction
> are different,  ext4_truncate() transaction is nested inside
> ext4_delete_inode.

Yes, the way transaction nesting works is that the amount of credits
requested in the nested transactions is completely ignored.  The only
thing that matters is the amount of credits requested in the top-level
transaction handl, which in the case of ext4_delete_inode(), is in the
start_transaction(inode) call of ext4_delete_inode.  This amount is
blocks_for_truncate(inode).

> Currently ext4_delete_inode() uses blocks_for_truncate(inode) to
> calculate credits, by the time ext4_delete_inode() is called, i_blocks
> seems to 0 (I need to double check this). 

No, i_blocks will not be 0, because the inode will not have been
truncated yet.  That happens later; ext4_delete_inode() calls
ext4_truncate().  The problem is that blocks_for_truncate() caps the
number of credits at EXT4_MAX_TRANS_DATA, which is 64 credits.  So for
a very big, fragmented file, the number of credits will be
EXT4_DATA_TRANS_BLOCK + EXT4_DATA_TRANS_BLOCKS(sb).

If more credits are needed the truncate code is supposed to request
more.  This is true both for the extents and non-extents case.  The
difference is that in the non-extents case, the amount which is
requested to extend the transaction is determined by another call to
blocks_for_truncate(), which will be smaller because i_blocks will
decrease as part of the truncate operation.  In the extents case, the
amount needed is calculated precisely each time a leaf is removed.

That is I think the problem.  In practice it doesn't happen because
most of the time, the massive over-estimation of blocks_for_truncate()
of 64 credits is more than enough.  But bonnie++ creates some very
highly fragmented files, apparently.  (We later may want to see if we
can improve on its block layout).  At least, that's what I think is
happening...

							- 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