On Fri, Jan 21, 2011 at 09:31:45AM -0500, Josef Bacik wrote: > On Fri, Jan 21, 2011 at 02:28:29PM +0000, Jon Leighton wrote: > > Hi there, > > > > On Fri, 2011-01-21 at 09:03 -0500, Josef Bacik wrote: > > > Heh so now that I've had a moment to wake up, how about running your test on > > > ext3, but mount the partition with > > > > > > mount -o barrier > > > > > > and see if it's still faster than ext4. Thanks, > > > > You're right, that slows it down significantly on the ext3 partition. Is > > this expected behaviour with ext4 then? > > > > Yup, whatever you are doing in your webapp is making your database do lots of > fsyncs, which is going to suck. If you are on a battery backed system or just > don't care if you lose your database and rather it be faster you can mount your > ext4 fs with -o nobarrier. Thanks, If for some reason you can't change the database to be less fsync-happy and there are a lot of threads issuing fsync in parallel, you might try building a kernel with the patch set that Tejun Heo has put together (https://lkml.org/lkml/2011/1/21/251) to merge flush requests coming from multiple threads. It might speed things up for you. (I don't know how much that patch set will change between now and the time it goes upstream...) --D -- 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
