[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]