[mythtv-users] Performance issues with ext4

Matthew McClement mythtv at macker.co.uk
Tue Dec 29 11:48:37 UTC 2009

On 12/27/09 19:45, Daniel Kristjansson wrote:
> I sounds like you had performance issues with mysql on ext4.
> I'm not aware of any such problems which are not shared by ext3.
> It may have just been the ext4 file system creation params are
> different in your distro for ext3 and ext4. XFS beats both handily
> for mysql performance. But I'm actually using ext3 her for mysql
> tables because XFS clears all open files on a crash, while I prefer
> to have them in an intermediate state so mysql can attempt recovery.

Just to address the "XFS clears open files" bit, this isn't strictly
true(certainly not since 2.6.22). XFS will never clear an open file that
already has committed data on disk. What it *will* clear are any extents
that were allocated prior to the crash(whether it's a power failure,
kernel panic, FS error), but hadn't actually been written out to disk
yet. This is a side effect of only metadata being journal'd, so a
rollback to create a consistent filesystem means that the extent
allocation needs to be wiped.

In MySQL this would only cover very recent data that was added via an
INSERT or UPDATE prior to the crash. All other row data will remain
intact. Just as with any other filesystem you'll need to run a REPAIR
TABLE to make clean up any invalid row data and fix the index if needed.
In theory with other filesystems *some* of the row data might still be
there by I doubt very much MySQL will be able to make much use of it and
is likely to just discard it anyway.

There is one situation where XFS will likely result in the complete loss
of a file which is software that does a "copy-modify-rename" without an
appropriate call to fsync()(or a open using O_SYNC/O_DIRECT). As the
last part of the operation is a metadata change, the metadata in the
filesystem will be updated before XFS's lazy write out catches up and
writes out the new file to disk. However, MySQL doesn't use this method
for most of its operations(and where it does, it's pretty fsync happy
and won't, AFAIK, do the final rename until the fsync returns for the
modify part).

Having said all that, if you care about the data in your MySQL database
you'll be using InnoDB with all appropriate D(from ACID) settings
enabled, rendering the data write out behaviour of most filesystems moot.


More information about the mythtv-users mailing list