Slower performance with ext4

[Rashkae]

Christopher Chan wrote:
> Rashkae wrote:
>> Chan Chung Hang Christopher wrote:
>>   
>>> fyrbrds at netscape.net wrote:
>>>     
>>>>  
>>>>   >Data loss anyone?<
>>>> What evidence do you have that there would be data loss? ext2 and ext3 were used almost immediately after their release as well. The distro maintainers usually do some basic reliability tests or at least have access to such tests. So I would be happy to read any tests you've seen that suggest ext4 is unreliable. To start scaring people with talk of data loss based on random speculation would not be good. 
>>>>
>>>>   
>>>>       
>>> Dude, I used to work with clusters of mta boxes. The last thing I needed 
>>> then was a filesystem that loses data or corrupts its metadata easily. I 
>>> wait before using any new fangled filesystem regardless of how uber fast 
>>> it is or I play the pull the plug game with them with whatever 
>>> journaling mode they have available.
>>>
>>>
>>> ext4 data loss reports started with Ubuntu Jaunty I think too?
>>>
>>>     
>> The early data loss in Jaunty was really applications clobbering their
>> own files combined with EXT4's delayed allocation.  Basically, EXT4 was
>> behaving, for all intents and purposes, like XFS, without the null
>> bytes.  (I still question the sanity of whoever thought this would be a
>> good idea.. after all, wouldn't be all be using XFS years ago if this
>> behaviour was so superior?)  Following patches back ported to change
>> that introduced kernel soft lock bug in the ubuntu kernel (that was
>> never confirmed in the mainline kernel.).  And now we have uncomfired
>> sightings of data corruption, but the one person who claims to reproduce
>> that looks like he has memory corruption issues.  (He gets a different
>> md5sum every time he checks the same file... not really a filesystem
>> issue there.)
>>
>> None of this is really applicable to your point.  for a mission critical
>> production system, you want to use what's known and proven (I do find
>> the choice of jfs odd however.  I like EXT3 for reliable and
>> predictable, and XFS for performance, so long as I know my particular
>> workload won't be affected by XFS's null bytes on unclean shutdown.)
>>   
> 
> XFS blooming aggressive caching and lack of full journaling is a 
> disaster waiting to happen for mta queues. If you are running Centos, 
> you only get ext3...
> 

XFS has as much journaling as any other candidates.  Journal for
metadata.  And all MTA's, reportedly, write files in a sane manner and
never assume a file is written to disk until the fsync completes, and
therefore, are not at all affected by XFS aggressive caching.  Mail
server is therefore one of the workloads XFS is best suited for.



> JFS seems to have the second best performance overall according to Bruce 
> Guenter's maildir simulated local mail delivery benchmark. and it is 
> stable too.

JFS performs great in benchmarks, but back when I used to use it, I've
consistently been able to bend it out of shape under real world
conditions.. No data loss mind you, but damaged  meta data (fixed with
jfs repair, but that should never be needed in a modern file system) and
bizarre corner cases that caused performance to sink through the floor.
 (in one instance, I was able to reproduce an issue where reading a file
while writing new files to disk would perform poorly depending on
whether the filename had one . or two.  Ie, if the filename was
something.tar.gz, or renamed to something.tgz.)  At one time in the
distant past, someone completely broke quota support in JFS, and no one
even noticed for 4 kernel releases.  JFS just doesn't seem to have
enough people using it to maintain a well tested status.