The `truncated' page in block_write_full_page()/nobh_writepage() may
stick for a long time. For example, ext2_rmdir() will set i_size to
0, and then the dir inode and its pages may hang around because of
being referenced by some process.
To produce this situation:
In terminal 1:
mballoc.c is a whole lot of static functions, which gcc seems to
really like to inline.
With the changes below, on x86, I can at least get from:
432 ext4_mb_new_blocks
240 ext4_mb_free_blocks
208 ext4_mb_discard_group_preallocations
188 ext4_mb_seq_groups_show
164 ext4_mb_init_cache
152
On Thu, 2008-01-31 at 15:01 +0100, Eric Sesterhenn wrote:
hi,
while running a modified version of fsfuzzer i triggered the BUG() in
ext4_mb_release_inode_pa(). Sadly I am not able to reproduce this using
the generated image, but running the fuzzer will usually trigger this in
less than 40
mballoc history is likely a great debugging tool, but it seems a
bit heavyweight. If I make it a config option and turn it off,
things lighten up considerably, from:
220 ext4_mb_free_blocks
188 ext4_mb_seq_groups_show
176 ext4_mb_regular_allocator
164 ext4_mb_init_cache
156 ext4_mb_new_blocks
Hi,
On Thu, 2008-01-24 at 13:24 -0800, Mingming Cao wrote:
-static int journal_write_commit_record(journal_t *journal,
- transaction_t *commit_transaction)
+static int journal_submit_commit_record(journal_t *journal,
+
Eric Sandeen wrote:
It's a bit shocking how much this matters to the size of
ext4_mb_release_inode_pa etc; I've not yet found the
reason why.
Oh, well, duh - its' the big 108 byte allocation context on the
stack and if it's not used it gets optimized away.
I think it's worth looking at
The patch titled
BKL-removal: remove incorrect comment refering to lock_kernel() from
jbd/jbd2
has been removed from the -mm tree. Its filename was
bkl-removal-remove-incorrect-comment-refering-to-lock_kernel-from-jbd-jbd2.patch
This patch was dropped because it was merged into
The patch titled
disable-ext4
has been added to the -mm tree. Its filename is
disable-ext4.patch
Before you just go and hit reply, please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing
The following series of emails will contain the large part of the
e2fsprogs patch series that is used for Lustre. It will not contain
the regression tests for EXTENTS nor the DIR_NLINK features, as those
are very large and were previously submitted.
A full tarball that includes the patches,
