linux-kernel - Re: ext4 is faster with LVM than without, and other filesystem benchmarks

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20100507224630.GC25419@dastard>
Date:	Sat, 8 May 2010 08:46:30 +1000
From:	Dave Chinner <david@...morbit.com>
To:	Sami Liedes <sliedes@...hut.fi>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: ext4 is faster with LVM than without, and other filesystem
 benchmarks

On Fri, May 07, 2010 at 05:23:10PM +0300, Sami Liedes wrote:
> Basically the directory hierarchy consists of
> 
> * directory backuppc/cpool - a pool of compressed backed up files
>   - The individual files are of the form
>     backuppc/cpool/f/1/d/f1d2d2f924e986ac86fdf7b36c94bcdf32beec15
>   - There are some 456000 files in the pool, all hashed by their
>     SHA256 sum
>   - These take the first about 490 gibibytes of the archive
> 
> * directory backuppc/pc with individual backups of a few machines
>   - Essentially contains the root filesystems of quite normal desktop
>     Linux machines.
>   - All backed up files are hardlinks to the pool.
>   - Files with size 0 are not hardlinked but represented as themselves.
>   - Contains some 10.4M hard links to files in the pool, interspersed
>     with some 84300 empty files and very few regular files
> 
> The benchmarks were all I/O-bound on the speed of the target
> filesystem and partition. This was achieved by making a copy of the
> tar that has all the file contents zeroed and using a fast compressor
> (lzop) so the decompression of the .tar.lzop was still easily
> target-disk-bound.

[...]

> On XFS, extracting the archive took more than 16 hours (58548 seconds;
> only one sample), so XFS performs rather poorly in this I assume quite
> pathological case.

Not pathological, but XFS is generally slower at creating and
removing large numbers of files compared to ext and btrfs until you
get to parallel workloads and expensive storage hardware. However,
just adding the "logbsize=262144" mount option should speed it up
significantly for this workload.

FWIW, how big is the compressed tarball you are extracting? If it's
not large, can you make it available somewhere? I've current got a
set of pending modifications to XFS(*) that should help this
workload and this looks like a good load for testing...

Cheers,

Dave.

(*) http://oss.sgi.com/archives/xfs/2010-05/msg00060.html
-- 
Dave Chinner
david@...morbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/