Slower performance with ext4

[Christopher Chan]

Rashkae wrote:
>> Journaling only for metadata is not 'as much journaling as any other 
>> canditates.' You cannot say metadata journaling only as equivalent to 
>> the data and metadata journaling that is possible with ext3. XFS's 
>> journaling only provides filesystem metadata consistency which is why 
>> you get files full of NULLs after a crash/power out. MTAs rely on fsync 
>> calls and how a filesystem behaves in regards to fsync requests is the 
>> real determiner of whether there is a data guarantee or not. XFS does 
>> not provide data guarantee. I
>>     
>
>
> This is completely false,, XFS gives as much data guarantee as the other
> filesystems in respects to an fsync.  The reason files can have Null
> bytes appended to them in XFS is because XFS, unlike ext3, will commit
> meta data changes out of order from the data actually being written to
> disk, but this has nothing to do with fsync, which works as intended.
>
>
>   
Wake up call.

http://www.humboldt.co.uk/2009/03/fsync-across-platforms.html

Even the definition of fsync indicates that not every fsync call returns 
after data is safely on disk. fsync returns after metadata has hit disk 
in the case of XFS, JFS, reiserfs and ext3 ordered mode and by 'hit 
disk' I mean the journal of the filesystem and not the actual location 
in the filesystem.

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

'In the middle ground between these extremes, /fsync/() might or might 
not actually cause data to be written where it is safe from a power 
failure.'

For this reason, some people might go to such lengths as installing 
nvram cards for use as external journals for ext3 in full journaling 
mode in conjunction with their software raid or get a hardware raid that 
has bbu cache.