linux-ext4 - Re: Test results for ext4

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: <48440901.2050809@bull.net>
Date:	Mon, 02 Jun 2008 16:51:45 +0200
From:	Valerie Clement <valerie.clement@...l.net>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: Test results for ext4

Eric Sandeen wrote:
> Valerie, would you be interested in any xfs tuning?  :)
Yes, if you give me inputs.

> 
> I don't know how much tuning is "fair" for the comparison... but I think
> in real usage xfs would/should get tuned a bit for a workload like this.
> 
> At the 5T range xfs gets into a funny allocation mode...

Look at the tests I'd done one year ago:
  http://www.bullopensource.org/ext4/20070404/ffsb-write.html
Large sequential writes were done on a smaller device. With 4 threads,
xfs is better than ext3 and ext4. But when the thread number is increased,
xfs becomes less good.

To run my tests with 128 threads, maybe I have to tune something in xfs.

> 
> If you mount with "-o inode64" I bet you see a lot better performance.
> 
> Or, you could do sysctl -w fs.xfs.rotorstep=256
> 
> which would probably help too.
> 
> with a large fs like this, the allocator gets into a funny mode to keep
> inodes in the lower part of the fs to keep them under 32 bits, and
> scatters the data allocations around the higher portions of the fs.
> 
> Either -o inode64 will completely avoid this, or the rotorstep should
> stop it from scattering each file, but instead switching AGs only every
> 256 files.
> 
> Could you also include the xfsprogs version on your summary pages, and
> maybe even the output of xfs_info /mount/point so we can see the full fs
> geometry?  (I'd suggest maybe tune2fs output for the ext[34] filesystems
> too, for the same reason)
> 
> When future generations look at the results it'll be nice to have as
> much specificity about the setup as possible, I think.
Yes, I agree. Thank you very much for yours comments. They help me much.
    Valérie

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html