<div class="gmail_quote">On Sat, Oct 8, 2011 at 9:59 PM, Raymond Wagner <span dir="ltr"><<a href="mailto:raymond@wagnerrp.com">raymond@wagnerrp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">The SQLite benchmark is especially telling of the situation.</div>
<br>
<a href="http://www.phoronix.com/scan.php?page=article&item=ext4_btrfs_nilfs2&num=2" target="_blank">http://www.phoronix.com/scan.php?page=article&item=ext4_btrfs_nilfs2&num=2</a><br>
<div><div></div><div class="h5"><br></div></div></blockquote><div><br></div><div>This is getting way above the heads of most people. Mounting ext4 with barrier=0 will make it act the same way as ext3 did (with barriers disabled), however, this is at the cost of massive filesystem damage should the power fail. In ext3, they were off by default, in ext4, they are on by default. Adding a "journal_async_commit" should significantly help (like twice as fast with barriers on as without it). I also use "noatime, nodiratime" on my mysql data mount (which is ext4 with barriers ON). Reducing the pointless metadata spew is useful too.</div>
<div><br></div><div>The problem is not ext4. It is with applications that use fsync() too much, which triggers the barriers (as it should!). When you do fsync(), you are telling the OS to flush the data to disk. This triggers a barrier in the filesystem, causing the data AND the filesystem metadata to be flushed to disk. This is inherently slow. If you don't care that your data actually gets to disk, feel free to let it trash your data fast, or let the power failure brutalize your filesystem :)</div>
<div><br></div><div>Unfortunately, mythtv uses fsync() in the recording path too, but I think we have it spaced out to be less abusive of the I/O subsystem, but not sure how recently it has been looked at in detail.</div>
</div>