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. _______________________________________________ Ext3-users@redhat.com https://listman.redhat.com/mailman/listinfo/ext3-users
