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, 19 Nov 2008 16:18:40 -0500
From:	Theodore Tso <>
To:	Andreas Dilger <>
Subject: Re: ext4 unlink performance

On Wed, Nov 19, 2008 at 12:10:01PM -0600, Andreas Dilger wrote:
> That may be a side-effect of the mballoc per-CPU cache again, where
> files being written in the same subdirectory are spread apart because
> of the write thread being rescheduled to different cores.

It would be good for us to get confirmation one way or another about
this theory.  Bruce, if you have multiple CPU's (or cores on your
system --- i.e., cat /proc/cpuinfo reports multiple processors), can
you try unpacking your tarball on a test ext4 filesystem using
something like:

    taskset 1 tar xjf /path/to/my/tarball.tar.bz2

The "taskset 1" will bind the tar process to only run on a single
processors.  If that significantly changes the time to do run rm -rf,
can you save a raw e2image using that workload?  That would be very
useful indeed.

Alternatively, if you don't have the taskset command handy, you can
also add maxcpus=1 to the kernel boot command-line, which will force
the system to only use one cpu.  Using taskset is much more
convenient, though.


						- Ted
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists