On Friday, December 24, 2010 01:03 AM, Les Mikesell wrote:
> On 12/23/2010 10:28 AM, Christopher Chan 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?
>
> No, if you don't remember history you are doomed to repeat it.
Well, come to think of it, I guess most open source apps are developed
on Linux and so its implementation does colour how devs think about
fsync...nevermind that it is done properly on the BSDs and UNIXes
>
>> 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.
>
> It's one of those 'have you stopped beating your wife things'. Apps
> that correctly used fsync were slow because of the OS implementation, so
> people used other apps. So now you have popular apps that do things
> wrong.
>
Yeah, funny how ext3 managed to become the dominant Linux filesystem
when it was the one with the flush everything quirk and at a time when
fsync did not really honour the 'yes it is safely on the platters'
maxim. Let's thank Redhat for this mess.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
