It has never been safe to run ext3 on top of a loop device, because the loop device does not preserve ordering, and I'm not sure whether it properly passes barriers either. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. --

I've looked at your script. The problem is that "echo s >/proc/sysrq_trigger" isn't really a data integrity operation. In particular it does not wait on IO to finish (with the new writeback code it does not even wait for IO to be submitted) so you sometimes take the image checksum before the sync actually happens. If you used sync(1) instead, everything should work as expected... Honza -- Jan Kara <jack@suse.cz> SuSE CR Labs --

Hi Ted, sorry for my late response. tytso@mit.edu wrote: > On Wed, Feb 17, 2010 at 05:36:00PM +0900, Toshiyuki Okajima wrote: > > > > > > The reason that I wanted to change the journaling interface into jbd2 were: > > > - the most of my customers use linux for Mission Critical (M.C.). > > > - M.C. users want the filesystems which have more integrity for their data. > > > - I think we should not recommend ext4 to M.C. users because > > > for M.C. users, ext4 is still unstable ...

Stability is relative thing. I's quite depends on usecase. For example after triggering bug on not empty orphan list on ext3_umount i've started full orphan-list management code revision. And both ext3/ext4 appears to be almost broken in case of errors. But nobody seems never catch it in real life. But still at that time i have triggered: 1) non empty orphan list on umount for both (ext3 and ext4) 2) on_disk linked list corruption for both 3) data blocks beyond i_size 4) bit-difference on ...