linux-ext4 - Re: [PATCH 2/3] ext2fs: Implement dir entry creation in htree 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:   Thu, 6 Feb 2020 11:07:53 +0100
From:   Jan Kara <jack@...e.cz>
To:     Andreas Dilger <adilger@...ger.ca>
Cc:     Jan Kara <jack@...e.cz>, Ted Tso <tytso@....edu>,
        linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 2/3] ext2fs: Implement dir entry creation in htree
 directories

On Wed 05-02-20 10:50:16, Andreas Dilger wrote:
> On Feb 5, 2020, at 3:01 AM, Jan Kara <jack@...e.cz> wrote:
> > 
> > Implement proper creation of new directory entries in htree directories
> > in ext2fs_link(). So far we just cleared EXT2_INDEX_FL and treated
> > directory as unindexed however this results in mismatched checksums if
> > metadata checksums are in use because checksums are placed in different
> > places depending on htree node type.
> 
> I'm definitely not agains this, as I believe it will also speed up e2fsck
> for cases where a lot of entries are inserted into lost+found (sometimes
> many millions of files).  Currently e2fsck linearly scans the whole dir
> for each insert, rather than saving the offset of the last entry.  I have
> a patch to fix that, but it needed several API changes and got bogged down
> in performance testing and never made it out to the list.
> 
> One potential risk is that if a directory is corrupted in some way, then
> the htree index cannot always be trusted to do inserts during e2fsck, so
> it might still have to fall back to clearing the flag and doing a linear
> insertion.

Well, but pass 2 checks internal consistency of all directories so if htree
in lost+found is not usable, it will be detected and handled. So in pass 3
we should have usable lost+found (possibly without htree) to use.

Also note that I have not implemented conversion of directory into indexed
one so in the normal case lost+found will be just an ordinary linear
directory.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR