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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 25 Aug 2021 18:13:31 +0200
From:   Jan Kara <>
To:     Theodore Ts'o <>
Cc:     Jan Kara <>,
Subject: Re: [PATCH 0/5 v7] ext4: Speedup orphan file handling

On Wed 25-08-21 13:30:16, Jan Kara wrote:
> On Tue 24-08-21 13:14:09, Theodore Ts'o wrote:
> > I've been running some tests exercising the orphan_file code, and
> > there are a number of failures:
> > 
> > ext4/orphan_file: 512 tests, 3 failures, 25 skipped, 7325 seconds
> >   Failures: ext4/044 generic/475 generic/643
> > ext4/orphan_file_1k: 524 tests, 6 failures, 37 skipped, 8361 seconds
> >   Failures: ext4/033 ext4/044 ext4/045 generic/273 generic/476 generic/643

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.

So overall I don't see any other regressions with my patches (besides that
e2fsck bug). Or did I miss something?

Jan Kara <>

Powered by blists - more mailing lists