linux-ext4 - Re: [PATCH 08/49] e2fsck: don't rehash inline directories

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:	Wed, 12 Mar 2014 23:52:48 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	"Darrick J. Wong" <darrick.wong@...cle.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 08/49] e2fsck: don't rehash inline directories

On Mon, Mar 10, 2014 at 11:54:49PM -0700, Darrick J. Wong wrote:
> If a directory's contents are stored entirely inside the inode,
> there's no index to rebuild and no dirblock checksum to recompute.
> As far as I know these are the only two reasons to call dir rehash.

Well, actually, there is a third reason to rehash directories, and
that is to reorganize a directory to optimize out deleted entries that
are scattered in the middle of the directory.

That being said, it's more critical for inline directories, since we
very much want to keep them from spilling over to an external block,
this process of compressing out deleted space is something that should
be done in real time as we operate on the directory, by the kernel,
and not just at fsck time.

The only reason why we don't do this today is because if the directory
is open for scanning using opendir/readdir, if we reorganize a
directory block, it could end up corrupting the readdir --- and for
non-inline directories, it's much less important.

What I think would might make sense is to have the kernel track
whether the directory has been opened for reading, and if it hasn't,
then it would be safe to try compressing all of the directory entries
in the block so that the free space is in a single unused directory
entry at the end of the block.  We could try doing this "dynamic
compression" of directory free space both at unlink(2) time, and also
when we try inserting a directory entry into the block and there is
apparently no space in the directory block.

So I'm fine with skipping the rehashing of inline directories now, but
this is a future, relatively small, kernel project we might want to
think about for ext4.

Cheers,

							- 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