On Fri, Mar 13, 2009 at 06:06:07PM +0100, ext Jorge Boncompte [DTI2] wrote: > Nick Piggin escribió: > > On Tue, Mar 10, 2009 at 05:49:13PM +0100, Jorge Boncompte [DTI2] wrote: > >> Nick Piggin escribió: > >>> Ah, of course, it would be due to directory-in-pagecache. You need > >>> the following patch if you expect this to work. > >>> > >>> And that confirms the ext3 problem is a different one because it > >>> doesn't use directory in pagecache I think. Well, I'll look at > >>> that one tomorrow. > Hi Nick, no problems noticed in the last days running with the below > patch... > > --- linux-2.6.29-rc8/fs/super.c 2009-03-13 13:46:19 +0100 > +++ kernel/fs/super.c 2009-03-13 13:47:50 +0100 > @@ -647,6 +647,8 @@ int do_remount_sb(struct super_block *sb > acct_auto_close(sb); > shrink_dcache_sb(sb); > fsync_super(sb); > + if (sb->s_bdev && (flags & MS_RDONLY)) > + invalidate_bdev(sb->s_bdev); > > /* If we are remounting RDONLY and current sb is read/write, > make sure there are no rw files opened */ > Hello, first off, sorry if you getting this email twice. I also tried to do ext3/ext4 fs smoketesting and used Adraian's script. I am consistently getting the same results - filesystem get's corrupted. I tested on quad Xeon, with patches posted in this thread. 1. tests with brd: - ext3fs on brd corruption (see attached ext3fs.brd.corruption.txt) - ext4fs on brd corruption (see attached ext4fs.brd.corruption.txt) In both cases I saw some complains from JBD/JBD2: JBD: Detected IO errors while flushing file data on 2. I enabled JBD debugging, re-run the tests. Console was flooded with messages and in the end I got a soft lockup. I cannot consistently reproduce this (see attached brd.ext3fs.softlock.txt). Just to be sure I re-run the tests on real block device (usb stick) 3. tests with real block device (usb stick) - ext3fs no fs currption (overnight run) - ext4fs no fs currption (overnight run) Any ideas what else can be done here? I'd like to find out if this is filesystem or brd related fault. Denis