[CentOS] Ext4 on CentOS 5.5 64bit

[Christopher Chan]

On Friday, December 24, 2010 12:02 AM, Les Mikesell wrote:
> On 12/23/2010 9:08 AM, Ross Walker wrote:
>> On Dec 23, 2010, at 2:12 AM, cpolish at surewest.net wrote:
>>
>>> Matt wrote:
>>>> Is ext4 stable on CentOS 5.5 64bit?  I have an email server with a
>>>> great deal of disk i/o and was wandering if ext4 would be better then
>>>> ext3 for it?
>>>
>>> Before committing to ext4 on a production server, it
>>> would be good to consider the comments made in
>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/45
>>> which presumably still apply to current CentOS 5.5 64-bit kernels.
>>> As I read it, Ts'o argues that the apparent loss of stability
>>> compared to ext3 is a design issue in the realm of applications
>>> that run atop it. I hope this is not a misreading.
>>
>> Waiting for applications to be properly written, ie use fsync(), is no way to pick a file system. You'd have the same problems on xfs or any other file system that does delayed writes.
>
> But note that the reason applications don't use fsync() when they should
> is probably due to linux historically not implementing it in a
> reasonable way (i.e. it would flush the entire filesystem buffer and
> wait for completion instead of just the requested file's outstanding
> blocks).  Not sure when/if that was fixed - but it is also probably
> behind the old impressions that mysql is faster than postgresql.
>

Can we drop the fsync nonsense? Apps that are data sensitive should be 
using fsync/fsyncdata (fsync is a posix specification so the history of 
how linux implemented fsync has nothing to do with whether applications 
used it or not) otherwise it should not be even consider for the task. 
The lying fsync/fsyncdata was fixed when write barrier support was 
introduced and filesystems updated to use write barriers. As for the 
flush entire buffer...IIRC, that is specific to ext3 and even that 
should be now gone with the update to write barrier support.