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

Re: ext3 and data=journal bug



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.





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