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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20070920133350.GH2689@duck.suse.cz>
Date:	Thu, 20 Sep 2007 15:33:50 +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 Wed 19-09-07 14:24:50, Theodore Tso wrote:
> On Wed, Sep 19, 2007 at 05:07:15PM +0200, Jan Kara wrote:
> > 
> >   I was just wondering: Currently we start to build h-tree in a directory
> > already when the size of directory exceeds one block. But honestly, it does
> > not seem to make much sence to use this feature until the directory is much
> > larger (I'd say at least 16 or 32 KB). It actually slows down some
> > operations like deleting the whole directory, etc. So what is the reason
> > for starting building the tree so early? Just the simplicity of building it
> > when the directory is just one block large?
> 
> How much is it slowing down operations such as rm -rf?  For a small
> directory (< 32k), I would assume that the difference would be
> relatively small.  What sort of differences have you measured, and is
> this a common case problem?
  So for example deleting kernel tree on my computer takes ~14 seconds with
h-trees and less than 9 without them. Also doing 'cp -lr' of the kernel
tree takes 8 seconds with h-trees and 6.3s without them... So I think the
performance difference is quite measurable.

> Certainly one of the things that we could consider is for small
> directories to do an in-memory sort of all of the directory entries at
> opendir() time, and keeping that list until it is closed.  We can't do
> this for really big directories, but we could easily do it for
> directories under 32k or 64k.
  Umm, yes. That would be probably feasible. But converting to htrees only
when directories grow larger would avoid the problem also. It also does not
seem *that* hard but maybe I miss some nasty details...

								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