Comments on: Beware: ext3 and sync-binlog do not play well together

By: Steve Katz

Steve Katz — Thu, 12 Nov 2009 21:34:18 +0000

Does this same problem exist on CentOS 5.4?

By: Stewart Smith

Stewart Smith — Wed, 08 Apr 2009 00:47:33 +0000

It can depend on the performance characteristics of the device. with battery backed RAID cache, barriers should be the best performing setup as you will want to be using the write cache.

By: David Nguyen

David Nguyen — Tue, 07 Apr 2009 19:56:52 +0000

Thanks for your quick replies. I am running MySQL on a Dell PowerEdge 2950 with PERC6 (with BBU) 6 x 15K drives configured with Raid 10.

Is the recommendation to:

1) mount XFS with -onobarrier
2) write cache disabled for the drive
3) write-back enabled for the controller

By: Stewart Smith

Stewart Smith — Tue, 07 Apr 2009 00:20:44 +0000

with -onobarrier, be sure that you have write cache disabled for the drive – otherwise you *will* get filesystem corruption on crash.

Note that ext3, by default, does *NOT* use write barriers – so it’s actually dangerous if write cache is enabled.

By: Vadim

Vadim — Mon, 06 Apr 2009 19:16:02 +0000

David,

You may mount XFS partition with -o nobarrier option.

By: David Nguyen

David Nguyen — Mon, 06 Apr 2009 18:46:11 +0000

I’ve ran several sysbench tests with ext3, ext2, and XFS. I noticed a huge performance hit with ext3 and sync_binlog=1 and only a ~10% hit with ext2 (just as you have posted above). However, I was not able to get good numbers with XFS on Debian. What are some of the recommended XFS tuning parameters?

By: peter

peter — Sat, 24 Jan 2009 00:48:50 +0000

Steward,

Are you sure about fsync()==/bin/sync ? I know it does flushes the log but I think I commonly see “dirty” pages in the cache on server running Innodb on ext3 while running tens of durable commits per seconds which would keep this number very low if it would be full syncs.

Speaking about Pre-Allocation I think it is different story. This helps with fragmentation by reserving the space. But if files change their size with each write you get important meta data updates all the time. Though I guess it would be interesting to just see how it affects performance – growing file vs fallocate preallocated vs physically preallocated.

By: Stewart Smith

Stewart Smith — Fri, 23 Jan 2009 21:24:43 +0000

well… fsync()==/bin/sync

innodb does “preallocate” but just by writing out the files. NDB (on XFS… or recent glibc and kernel) call the filesystem’s fallocate function (xfsctl or if posix_fallocate is implemented correctly in libc and kernel) to ask it to preallocate the disk space (which usually results in much less fragmented files on any remotely aged file system)

By: peter

peter — Fri, 23 Jan 2009 16:31:26 +0000

Steward,

You’re saying FSYNC == O_SYNC for opening files ?

Speaking about NDB I assume you mean besides Innodb which has fixed sized logs…. BTW even for tablespaces Innodb uses background pre-allocation.

By: Stewart Smith

Stewart Smith — Fri, 23 Jan 2009 07:15:00 +0000

on ext3, think of fsync==sync.

The only engine inside MySQL that does pre-allocation correctly is NDB.