Petter, I was never able to resolve the problems I had with data=journal with the 2.4 kernel. I did *not* try the 2.6 kernel though, so I can't give you any data points there. In the end, I settled for data=ordered, and have never seen the problems I described in my original posts. Also, to give you some background, I had been using ReiserFS before switching to ext3, and I experienced a lot of corruption with Reiser (my company makes linux based appliances which sometimes get turned off while under heavy IO). Since ReiserFS doesn't do data journalling (metadata only), we consistently ended up with corrupt files. After this, I decided to try ext3 with data=journal, and I never even got far enough with load testing to try the 'hard reset' test. It would consistently crash in the fs code under heavy load. We have since had no problems with data=ordered, and since it writes data blocks before writing metadata to the journal, we don't see corrupt files anymore (even on hard resets). If data integrity (within the file) is important to you in the face of a crash or power loss, do NOT use ReiserFS or ext3 data=writeback. If your application never overwrites data in files, you will be just fine using data=ordered (appending to files or creating new files is pretty much guaranteed to never cause corruption). If you need to overwrite data in files, you need to use data=journal (and probably beg people to fix it) or rewrite your application to use some other method (i.e. copy the file, delete the old one) and just use data=ordered. --Phil > > > Petter Larsen wrote: > >> >> Data integrity is much more important for us than speed. >> > > > You might want to consider ReiserFS or one of the others which were > designed with journaling in mind. And I hope you're using RAID1 or RAID5. > > _______________________________________________ Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
