linux-ext4 - Re: [PATCH, RFC] ext4: New inode/block allocation algorithms for flex

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]

Date:	Tue, 24 Feb 2009 14:04:29 -0500
From:	Theodore Tso <tytso@....edu>
To:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH, RFC] ext4: New inode/block allocation algorithms for
	flex_bg filesystems

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
--
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