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