Re: [PATCH, RFC] ext4: New inode/block allocation algorithms for flex_bg filesystems

[Theodore Tso <tytso@mit.edu>]

On Tue, Feb 24, 2009 at 10:27:34AM -0500, Theodore Tso wrote:
> > > +	/*
> > > +	 * If we are doing flex_bg style allocation, try to put
> > > +	 * special inodes in the first block group; start files and
> > > +	 * directories at the 2nd block group in the flex_bg.
> > > +	 */
> > 
> > Why ? Can you explain whether this placing helps any specific work load
> > ? or something where you have observed that this placement helps ?  
> 
> This was left over from when I was using the inode number to influence
> block allocation.  We're not doing this any more, so this should go
> away.   Thanks for asking the question.

Hm, I just tried taking it out, and it costs a 17% increase in e2fsck
time on my test filesystem.  The reason is pass 2, we need to check to
make sure the filetype information in the directory blocks is correct.
If the inode in question is a regular file or a directory, we can
determine that by looking at an inode bitmap.  However, if it is a
named pipe, device file, or symlink, we can only determine what it is
by reading the inode.  In the filesystem in question, which is an
Ubuntu Intrepid image, there are 5 charater device files, 1 block
device file, 5 named pipes --- and 20,613 symbolic links.  If we group
all of these inodes togehter, it saves about 3 seconds in pass 2 (13
seconds versus 17 seconds).

We can also solve this problem by caching the file type information.
For example, I could store a list of all symlink inodes, and if there
are only 20k symlinks, it will end up costing us 80k of memory.  So
this might be a problem which is better solved with some e2fsck
hacking (which has the advantage that it will speed up ext3 fsck runs
as well).

						- Ted