Slower performance with ext4

[Christopher Chan]

Mark Kirkwood wrote:
> Mark Kirkwood wrote:
>   
>> Christopher Chan wrote:
>>   
>>     
>>> Heh, what do you know? I have been burned by XFS after a powerloss and 
>>> got over 4000 zero length files in a postfix queue. No filesystem 
>>> corruption, just zero data files. You want to tell me that postfix does 
>>> not use fsync? You can guess what I did to the XFS filesystem mounted 
>>> for the queue directory. I destroyed it and got ext3 instead in full 
>>> data journal mode. Which I repeated on all the other mtas that had a XFS 
>>> filesystem for their mail queue.
>>>
>>>   
>>>     
>>>       
>> Hmm - not gonna get into trading personal insults , as nothing is to be 
>> gained that way.
>>
>> You were running this on server grade hardware? or - let me guess - a 
>> workstation with cheap sata drives? I have run many instances of mysql, 
>> postgres and oracle on *server* grade hardware [1] with xfs for probably 
>> the last 7 years and never have *any* data corruption issue in spite of 
>> many power outages...
>>
>> regards
>>
>> Mark
>>
>> [1] meaning a designated server mobo with eec ram and scsi (or sas) hard 
>> drives.
>>
>>
>>   
>>     
>
> Interesting data point for both of us:
>
> http://blogs.gnome.org/alexl/2009/03/16/ext4-vs-fsync-my-take/
>
> He claims ext4 is safe with sensible usage of fsync but reckons xfs is 
> not. Without wading through the code for the various fs it is tricky to 
> be 100% sure if he is correct or mistaken, as it is clearly *possible* 
> for the respective fs drivers to intercept the f(data)sync etc calls and 
> do undeserved violence to 'em....
>
>   

No, it is more a problem of the myth of fsync guaranteeing data is 
committed to the filesystem every time.

http://www.opengroup.org/onlinepubs/009695399/functions/fsync.html


Not even the specification explicitly spells that out.


ext4 fsync is only safe if data=journal is used and write-caches are 
either disabled or have a bbu.