Our QA reported an oops in the ext4_mb_release_group_pa tracing, and Josef Bacik pointed out that it was because we may have a non-null but uninitialized ac_inode in the allocation context. I can reproduce it when running xfstests with ext4 tracepoints on, on a CONFIG_SLAB_DEBUG kernel. We call trace_ext4_mb_release_group_pa from 2 places, ext4_mb_discard_group_preallocations and ext4_mb_discard_lg_preallocations In both cases we allocate an ac as a container just for tracing (!) and ...

Maybe. I'd need to do some testing to see what percentage of the "takes hours longer" is caused by needing to fix truly vast numbers of inodes, versus the fact that writing the e2fsck log file was taking a huge amount of time. I'm not sure, asking the user, "I've tried fixing 100 of these inodes, and it looks like there are runs more, want to skip checking for the rest" is all that great (i.e., a "go into automatic 'no' mode for this question"). The other possibility is that I'd make it ...

It looks like how we handle the EOFBLOCKS_FL flag is buggy. This means that when we fallocate a file to have 128k using the KEEP_SIZE flag, and then write exactly 128k, the EOFBLOCKS_FL isn't getting cleared correctly. This is bad, because e2fsck will then complain about that inode. If you have a large number of inodes that are written with fallocate using KEEP_SIZE, and then fill them up to their expected size, e2fsck will potentially complain about a _huge_ number of inodes. A proposed ...

To me this falls into the class of "silently fix our mistake" kind of problem, similar to what we did in the Lustre e2fsprogs with the extent "_hi" field not being initialized in early versions of the extent patch. If the slowdown is due to actually updating thousands of such inodes (vs. just printing the error on the screen) you could cap the number of inodes fixed for this problem at some limit, and then every time a full e2fsck is run it would fix a bunch more. Presumably an updated kernel ...

Oh it can get fixed during rhel6's lifetime, certainly. :) Regarding a conf file setting, I'd really rather not have another knob that is non-obvious to the user. Maybe e2fsck could tally these and after I dunno, 10 or 20 or so, ask whether it should keep flagging them or just go into "yes" mode for the rest of the inodes with that problem? -Eric --

As I recall, you're on a 32-bit machine, right? If so, a limitation you may run into is simply running out of address space. If it's not an address space issue, we don't need to mmap anything; you could just try enabling swap, and use the existing e2fsck code. (I had assumed you had tried that before suggesting you use the scratch_files tdb approach....) - Ted --

But e2fsck runs entirely in user space, so all memory should be I'm not sure I can follow. Are you saying we currently allocate two struct ext2_icount for a directory inode even if . and .. are the only two references? So we could just omit this allocation in the common icount == 2 case because we know it is a directory inode I'm interested in having a look at the icount structure and see what can be done to reduce memory usage. Here's a first question: There is ext2fs_create_icount() ...