http://www.gluster.com/community/documentation/index.php/Translators/performance/stat-prefetch http://www.gluster.com/community/documentation/index.php/Translators/performance/quick-read http://www.gluster.com/community/documentation/index.php/Translators/performance/io-cache http://www.gluster.com/community/documentation/index.php/Translators/performance/quick-read http://www.gluster.com/community/documentation/index.php/Translators/performance/writebehind http://www.gluster.com/community/documentation/index.php/Translators/performance/readahead http://www.gluster.com/community/documentation/index.php/Translators/performance/io-threads Some of these translators will aggregate smaller I/Os into larger blocks to improve read/write performance. The links above explain what each one does. My advice is to take the defaults created by glusterfs-volgen and increment the values slowly on the relevant translators (note that bigger doesn''t always equal better - you''ll find a sweet spot where performance maxes out, and then most likely reduces again once values get too big). And then continue testing. Repeat for 4K, 16K, 32K files if you like (or a mix of them) to match what sort of data you''d expect on your file system (or better yet, use real world data if you have it lying around already). Also, if you don''t need atime (last access time) information on your files, consider mounting the ext4 file system on the storage bricks with the "noatime" option. This can save unnecessary I/O on regularly accessed files (I use this a lot on both clustered file systems as well as virtual machine disk images and database files that get touched all the time by multiple systems to reduce I/O). Hope that helps. -Dan