linux-ext4 - Re: [PATCH 0/5 v7] ext4: Speedup orphan file handling

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: <20210825221336.GA27926@quack2.suse.cz>
Date:   Thu, 26 Aug 2021 00:13:36 +0200
From:   Jan Kara <jack@...e.cz>
To:     Theodore Ts'o <tytso@....edu>
Cc:     Jan Kara <jack@...e.cz>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 0/5 v7] ext4: Speedup orphan file handling

On Wed 25-08-21 13:48:18, Theodore Ts'o wrote:
> On Wed, Aug 25, 2021 at 06:13:31PM +0200, Jan Kara wrote:
> > 
> > So I had a look into the other failures... So ext4/044 works for me after
> > fixing e2fsck (both in 1k and 4k cases). ext4/033, ext4/045, generic/273
> > fail for me in the 1k case even without orphan file patches so I don't
> > think they are a regression caused by my changes (specifically ext4/045 is
> > a buggy test - I think the directory h-tree is not able to hold that many
> > directories for 1k block size). Interestingly, I couldn't make generic/476
> > fail for me either with or without my patches so that may be some random
> > failure. I'm now running that test in a loop to see whether the failure
> > will reproduce to investigate.
> 
> Oh, you're right.  I had forgotten I had the following in my
> 1k.exclude file, and I hadn't copied them over when I set up the
> orphan_file_1k config.
> 
> # The test fails due to too many block group descriptors when the
> # block size is 1k
> ext4/033
> 
> # This test uses dioread_nolock which currently isn't supported when
> # block_size != PAGE_SIZE.
> ext4/034
> 
> # This test tries to create 65536 directories, and with 1k blocks,
> # and long names, we run out of htree depth
> ext4/045
> 
> # This test creates too many inodes on when the block size is 1k
> # without using special mkfs.ext4 options to change the inode size.
> # This test is a bit bogus anyway, and uses a bunch of magic calculations
> # where it's not clear what it was originally trying to test in the
> # first place.  So let's just skip it for now.
> generic/273
> 
> # This test creates too many extended attributes to fit in a 1k block
> generic/454
> 
> # Normal configurations don't support dax
> -g dax
> 
> (We can drop ext4/034 from the exclude list since we now *do* support
> dioread_nolock when block_size < page_size.)
> 
> Thanks for the investigating, and apologies for not the reason why I
> hadn't seen the failures in the 1k case was because they had been
> suppressed.

No problem. Glad this is cleared out. I've sent out next version of the
e2fsprogs patches with fixed e2fsck bug you've found.

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