Steve Brown wrote: ... > I'll start with the craziest one: noatime. Everything I have read > says that the noatime option should increase both read and write > performance. My results are finding that write speeds are comparable > with or without this option, but read speeds are significantly faster > *without* the noatime option. For example, a 16GB file reads about > 210MB/s with noatime but reads closer to 250MB/s without the noatime > option. the kernel uses "relatime" now by default, which gives you most of the benefit already. > Next is the write barrier. I'm an in a fully battery-backed > environment, so I'm not worried about disabling it. From my testing, > setting barrier=0 will improve write performance on large files > (>10GB), but hurts performance on smaller files (<10GB). Read > performance is effected similarly. Is this to be expected with files > of this size? not expected by me; barriers == drive write cache flushes, which I would never expect to speed things up... > Next is the data option. I am seeing a significant increase in read > performance when using data=ordered vs data=writeback. Reading is as > much as 20% faster when using data=ordered. The difference in write > performance is almost none with this option. data=writeback is not safe for data integrity; unless you can handle scrambled files post-crash/powerloss, don't use it. > Finally is the commit option. I did my testing mounting with commit=5 > and commit=90. While my read performance increased with commit=90, my > write performance improved by as much as 30% or more with commit=5. not sure offhand what to make of decreased write performance with a longer commit time... -Eric -- 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
