linux-ext4 - Re: Enabling h-trees too early?

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 20 Sep 2007 18:19:04 +0200
From:	Jan Kara <jack@...e.cz>
To:	Theodore Tso <tytso@....edu>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: Enabling h-trees too early?

On Thu 20-09-07 11:14:40, Theodore Tso wrote:
> On Thu, Sep 20, 2007 at 04:58:39PM +0200, Jan Kara wrote:
> >   Hmm, strange - I've just looked at my computer and dir_index is set
> > just for 5 directories in my tree.
> 
> I looked at a tree that had object files, which is probably why I had
> 8 directories; I'm guessing you probably just had kernel sources and
> no build files.
> 
> > If I try deleting just them, I also
> > see some performance decrease but it's less than if I try deleting the
> > whole tree (and that result seems to be quite consistent)... There's something
> > fishy there. Maybe I could try seekwatcher or something similar to see
> > what's really happening.
> 
> That is very strange.....
  Just a guess: Can't the culprit be the following test in ext3/4_readdir()?
if (EXT4_HAS_COMPAT_FEATURE(inode->i_sb, EXT4_FEATURE_COMPAT_DIR_INDEX) &&
    ((EXT4_I(inode)->i_flags & EXT4_INDEX_FL) ||
     ((inode->i_size >> sb->s_blocksize_bits) == 1))) {
        error = ext4_dx_readdir(filp, dirent, filldir);
        if (error != ERR_BAD_DX_DIR) {
                ret = error;
                goto out;
        }
        /*
         * We don't set the inode dirty flag since it's not
         * critical that it get flushed back to the disk.
         */
        EXT4_I(filp->f_path.dentry->d_inode)->i_flags &= ~EXT4_INDEX_FL;
}
  It calls ext4_dx_readdir() for *every* directory with 1 block (we have
1326 of them in the kernel tree). Now ext4_dx_readdir() calls
ext4_htree_fill_tree() which finds out the directory is not h-tree and
and calls htree_dirblock_to_tree(). So even for 4KB directories we end up
deleting inodes in hash order! And as a bonus we burn some cycles building
trees etc. What is the point of this?

									Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
-
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