Re: Test results for ext4

[Valerie Clement <valerie.clement@bull.net>]

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html