Slower performance with ext4

[Christopher Chan]

Christopher Chan wrote:
> Mark Kirkwood wrote:
>   
>> Christopher Chan wrote:
>>   
>>     
>>> Mark Kirkwood wrote:
>>>   
>>>     
>>>       
>>>> Christopher Chan 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. It, at best, provides a metadata guarantee. 
>>>>> XFS should not be used for mta queues unless it is in conjunction with 
>>>>> hardware raid that has a bbu cache. XFS is best suited for streaming 
>>>>> applications where the data loss is tolerated.
>>>>>
>>>>>   
>>>>>     
>>>>>       
>>>>>         
>>>>>           
>>>> Sorry, but that is completely incorrect. Applications that use fsync are 
>>>> safe with any filesystem - fsync forces the modified buffers to *disk*, 
>>>> so all discussions about os and filesystem caching are irrelivant[1].
>>>>   
>>>>     
>>>>       
>>>>         
>>> Yes...where *disk* = journal. Which for JFS, XFS and ext3 data=ordered 
>>> means metadata only. Only ext3 data=journal guarantees data and 
>>> metadata. Feel free to get (whoever filesystem developer) to confirm for 
>>> me because you won't get any other answer than what I have just posted.
>>>
>>>   
>>>     
>>>       
>> Not so - disk != journal. At fsync the buffers are written through the 
>> os buffer to the physical disk cache, and the cache is instructed to 
>> write 'em to the rotating media. This is for data, *not* always metadata 
>> (see man for fsync vs fdatasync). In fact it is the metadata that has 
>> historically caused the most problems - hence the need to journal this.
>>   
>>     
>
> Maybe you want to first VERIFY with the various filesystem developers 
> before you start yapping what appears to be the only sensible 
> explanation but is in fact a myth. On Linux, XFS, JFS and ext3 
> data=ordered return fsync as soon as the metadata hits the journal on 
> disk and before the data is commited to its location on the filesystem 
> and metadata is committed to its location. ext3 data=journal returns 
> after both data and metadata is committed to disk on the JOURNAL and 
> before they are written to their locations in the filesystem. I have not 
> yet looked at ext4 so I will not say anything about what it does.
>
>   

It appears that ext4 shares the same journaling modes as ext3 with some 
data-integrity and performance enhancements. Anyway, here is the 
relevant portion of another party's comments on filesystem behaviour 
that you may find more acceptable than mine.

"Ext4 supports multiple modes of journaling, depending upon the needs of 
the user. For example, ext4 supports a mode in which only metadata is 
journaled (Writeback mode), a mode in which metadata is journaled but 
data is written as the metadata is written from the journal (Ordered 
mode), and a mode in which both metadata and data are journaled (Journal 
mode—the most reliable mode). Note that Journal mode, although the best 
way to ensure a consistent file system, is also the slowest, because all 
data flows through the journal."

From: http://www.ibm.com/developerworks/linux/library/l-anatomy-ext4/

In case you have not figured out why ext3 + external journal on uber 
fast and secure bbu nvram card blows everything else, except filesystems 
on hardward raid + bbu cache, out of the water, it is because fsync 
returns as soon as stuff is committed to...the journal.