Ext3 users - Apr 2003 - ext3 and data=journal bug

Greetings all,

I have a question regarding the fsync data corruption bug that was introduced 
in 2.4.20 when using data=journal.  I have patched the 2.4.20 kernel with the 
3 sync patches available from zip.com.au, and I am wondering if with these 
patches the "bug" still exists:

sync_fs.patch 
sync_fs-fix.patch 
sync_fs-fix-2.patch 

In addition the following two patches have also been applied:

ext3-use-after-free.patch 
ext3-scheduling-storm.patch

Also, from what I understand 'data=journal' would be beneficial in cases
where
data is being written to and read from disks constantly.  Would it be advised 
to use this data mode in a webserver environment in which there are many 
virtual hosts(provided the above bug was fixed with the patches)?

One last thing is that I have come up with the below bdflush settings based on 
the filesystem/proc.txt kernel documentation.  Combined with data=journal or 
data=ordered would these settings have any adverse effects on the system?

----                                                    
 nfract     Percentage of buffer cache dirty to  activate bdflush              
 ndirty     Maximum number of dirty blocks to  write out per wake-cycle        
 nrefill    Number of clean buffers to try to obtain  each time we call refill 
 nref_dirt  buffer threshold for activating bdflush when trying to refill 
buffers. 
 dummy      Unused                                                             
 age_buffer Time for normal buffer to age before we flush it                   
 age_super  Time for superblock to age before we flush it                      
 dummy      Unused                                                             
 dummy      Unused                                                             
-----


Default bdflush settings:
30 500 0 0 500 3000 60 20 0

Settings offered on this list
90 500 0 0 600000 600000 95 20 0

Would the above settings not crush the server?  Those settings are flushing fs 
metadata about once per second, and data blocks every 600 seconds.

This is what I have come up with:

20 300 0 0 0 500 60 0 0

I'm doing some testing of these values, both with journal and ordered data 
modes.  If anyone has any real-world performance gains/losses with any 
elevator/bdflush settings, I would greatly appreciate hearing about them.  
Any other advice is welcome.

TIA,

-Mark

Mark A Basil <mbasil@alabanza.com> wrote:
>
> Greetings all,
> 
> I have a question regarding the fsync data corruption bug that was
introduced
> in 2.4.20 when using data=journal.  I have patched the 2.4.20 kernel with
the
> 3 sync patches available from zip.com.au, and I am wondering if with these 
> patches the "bug" still exists:
> 
> sync_fs.patch 
> sync_fs-fix.patch 
> sync_fs-fix-2.patch 
> 
> In addition the following two patches have also been applied:
> 
> ext3-use-after-free.patch 
> ext3-scheduling-storm.patch
That sounds right - it gets you up to 2.4.21-rc1's ext3.
> Also, from what I understand 'data=journal' would be beneficial in
cases where
> data is being written to and read from disks constantly.  Would it be
advised
> to use this data mode in a webserver environment in which there are many 
> virtual hosts(provided the above bug was fixed with the patches)?
Probably not.  data=journal can help in certain specialised workloads where
there is a lot of O_SYNC/fsync activity.  Mail servers, NFS servers, etc.
> Would the above settings not crush the server?  Those settings are flushing
fs
> metadata about once per second, and data blocks every 600 seconds.
Those settings were to address a specific problem wherein an NFS server with
synchronous exports would keep on filling the ext3 journal and forcing lots
of blocking writeout.

I'd expect you'll be OK with default journalling mode and default
bdflush
settings.  web servers are almost read-only aren't they?

You should seriously consider mounting with `noatime' - that will
significantly reduce the filesystem's writeout volume.