<html><body bgcolor="#FFFFFF"><div><div><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">On Dec 28, 2009, at 12:07 PM, Tom Bishop <<a href="mailto:bishoptf@gmail.com">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"><a href="mailto:david@pnyet.web.id">david@pnyet.web.id</a></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 class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); "><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><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, 0.226562); -webkit-composition-frame-color: rgba(77, 128, 180, 0.226562);">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 class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.289062); -webkit-composition-fill-color: rgba(175, 192, 227, 0.222656); -webkit-composition-frame-color: rgba(77, 128, 180, 0.222656);"><br></span></div><div><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.285156); -webkit-composition-fill-color: rgba(175, 192, 227, 0.21875); -webkit-composition-frame-color: rgba(77, 128, 180, 0.21875);">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 class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.28125); -webkit-composition-fill-color: rgba(175, 192, 227, 0.214844); -webkit-composition-frame-color: rgba(77, 128, 180, 0.214844);"><br></span></div><div><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.277344); -webkit-composition-fill-color: rgba(175, 192, 227, 0.210938); -webkit-composition-frame-color: rgba(77, 128, 180, 0.210938);">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 class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.273438); -webkit-composition-fill-color: rgba(175, 192, 227, 0.207031); -webkit-composition-frame-color: rgba(77, 128, 180, 0.207031);"><br></span></div><div><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.265625); -webkit-composition-fill-color: rgba(175, 192, 227, 0.199219); -webkit-composition-frame-color: rgba(77, 128, 180, 0.199219);">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 class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.261719); -webkit-composition-fill-color: rgba(175, 192, 227, 0.195312); -webkit-composition-frame-color: rgba(77, 128, 180, 0.195312);"><br></span></div><div><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.269531); -webkit-composition-fill-color: rgba(175, 192, 227, 0.203125); -webkit-composition-frame-color: rgba(77, 128, 180, 0.203125);">-Ross</span></div></body></html>