linux-ext4 - Re: Do we need dump for ext4?

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: <20080828223454.GD10082@mit.edu>
Date:	Thu, 28 Aug 2008 18:34:54 -0400
From:	Theodore Tso <tytso@....edu>
To:	Andreas Dilger <adilger@....com>
Cc:	Ric Wheeler <rwheeler@...hat.com>,
	Eric Sandeen <sandeen@...hat.com>,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: Do we need dump for ext4?

On Thu, Aug 28, 2008 at 04:23:48PM -0600, Andreas Dilger wrote:
> > For small directories which could potentially get converted into htree
> > format, we already sucking the entire directory and putting it into an
> > rbtree.  We could just do this for all directories less than or equal
> > to 32k, but have them returned sorted by inode instead of by hash
> > value.  At least on my laptop, this accounts for 99.93% of the
> > directories on my root filesystem.
> 
> What happens if the directory is grown at that point?  I thought the
> reason for keeping it sorted in hash order was to deal with the
> telldir headache?  I guess if the whole thing is in memory then it
> can be attached to the fd and discarded once read or seeked-on
> (and POSIX doesn't require reporting new entries after the start
> of the read).

It's fine, because according to POSIX it's undefined what happens to
files that are created or deleted after the last opendir() or
rewindir().  So basically, the b-tree is attached to the opendir, and
we discard it and re-create it if we ever seek to the beginning of the
directory.  This logic is already in the kernel, since it's exactly
the same situation if the file is grown past the point where it
becomes an HTREE directory.

> Doing this at the VFS level would also benefit _most_ filesystems,
> though maybe not ones like XFS or btrfs that have their own preferred
> order.

Possibly, but it's a lot easier inside ext3/ext4 because we have most
of the machinery in place and in use already.

	              		    	      - 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