On Fri, Jan 21, 2011 at 09:31:45AM -0500, Josef Bacik wrote: > > 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, Note that if you don't use -o barrier on ext3, or use -o nobarrier on ext4, the chance of significant file system damage if you have a power failure, since without the barrier, the file system doesn't wait for disk to acknowledge that the data has hit the barrier. The problem is that if you are using a barrier operation, you're not going to be able to get more than about 30-50 non-trivial[1] fsync's per second on a standard HDD; barriers are inherently slow. [1] Where there was some kind of data write between the two fsync's. You may be able to get faster back-to-back fsync() with no intervening data writes, but that's not terribly interesting. :-) A UPS should protect you against most of the dangers of not using barriers. The other choice is to be more intelligent with your coding (and/or with your database choice) to avoid needing a huge number of fsync's, as they are going to be costly. If you can batch multiple database operations under a single commit, for example, you should be able to eliminate the need for so many fsync's. - Ted -- 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
