Thanks for the explanation, looks like I need to go read some more about barriers to truly understand what is going on.....<br><br><div class="gmail_quote">On Mon, Dec 28, 2009 at 12:22 PM, Ross Walker <span dir="ltr"><<a href="mailto:rswwalker@gmail.com">rswwalker@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div bgcolor="#FFFFFF"><div class="im"><div><div><span>On Dec 28, 2009, at 12:07 PM, Tom Bishop <<a href="mailto:bishoptf@gmail.com" target="_blank">bishoptf@gmail.com</a>> wrote:</span><br>
</div></div><div><br></div><div></div><blockquote type="cite"><div><br><div class="gmail_quote">On Mon, Dec 28, 2009 at 11:03 AM,  <span dir="ltr"><<a href="mailto:david@pnyet.web.id" target="_blank"></a><a href="mailto:david@pnyet.web.id" target="_blank">david@pnyet.web.id</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm using ext3 on my CentOS box, so far so good, I don't get any problem. Sometimes my server shutdown when power is cut, but CentOS still running well and nothing corruption files or anything after start again.</blockquote>
</div></div></blockquote><span><blockquote type="cite"><div>Thanks guys for the responses, can anyone explain what the hoopla is then about ext4 and performance issues and barriers being enabled, there was also some talk about that being an potential issue with ext3?  I've tried to google and look but have not found a good explanation on what the issue is....<br>
</div></blockquote><br></span></div><div><span>Barriers expose the poor performance of cheap hard drives. They provide assurance that all the data leading up to the barrier and the barrier IO itself are committed to media. This means that the barrier does a disk flush first and if the drive supports FUA (forced unit access, ie bypass cache), then issues the IO request FUA, if the drive doesn't support FUA then it issues another cache flush. It's the double flush that causes the most impact to performance.</span></div>
<div><span><br></span></div><div><span>The typical fsync() call only assures data is flushed from memory, but makes no assurance the drive itself has flushed it to disk which is where the concern lies.</span></div><div><span><br>
</span></div><div><span>Currently in RHEL/CentOS the LVM (device mapper) layer doesn't know how to propogate barriers to the underlying devices so it filters them out, so barriers are only currently supported on whole drives or raw partitions. This is fixed in the current kernels, but has yet to be backported to RHEL kernels.</span></div>
<div><span><br></span></div><div><span>There are a couple of ways to avoid the barrier penalty. One is to have nvram backed write-cache either on the contoller or as a separate pass-through device. The other is to use a separate log device on a SSD which has nvram cache, newer ones have capacitor backed cache or a standalone nvram drive.</span></div>
<div><span><br></span></div><font color="#888888"><div><span>-Ross</span></div></font></div><br>_______________________________________________<br>
CentOS mailing list<br>
<a href="mailto:CentOS@centos.org">CentOS@centos.org</a><br>
<a href="http://lists.centos.org/mailman/listinfo/centos" target="_blank">http://lists.centos.org/mailman/listinfo/centos</a><br>
<br></blockquote></div><br>