Re: [BUG ext4?] Working tree getting out of date "spontaneously"

From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: Jun 5, 2009, 18:35 UTC
Message-ID: <20090605183538.GE764@atjola.homenet>
In-Reply-To: <20090605180630.GC6442@mit.edu>

On 2009.06.05 14:06:30 -0400, Theodore Tso wrote:

Show 31 quoted lines

> On Fri, Jun 05, 2009 at 05:02:12PM +0200, Björn Steinbrink wrote:
> > On 2009.06.05 10:55:08 -0400, Theodore Tso wrote:
> > > On Fri, Jun 05, 2009 at 03:21:26PM +0200, Björn Steinbrink wrote:
> > > > So the ctime got modified. I don't have any fancy indexing stuff
> > > > running, and inotify doesn't see any events either while the ctime is
> > > > changed.
> > > > 
> > > > The only thing I changed lately was upgrading to 2.6.30-rc8 and going
> > > > from ext3 to ext4. As the ctime change always seems to happen around 30
> > > > seconds after the real change, I kind of suspect ext4 to be guilty.
> > > > Ted, is that possible?
> > > > 
> > > > FS is mounted as:
> > > > /dev/mapper/vg0-home on /home type ext4 (rw,noatime,nodiratime,barrier=0)
> > > > 
> > > 
> > > I agree it sounds like it's ext4 related, but I'm not able to
> > > reproduce it (using 2.6.30-rc8 with the patches planned for the 2.6.31
> > > merge window).  This should show the problem, you were seeing, do you
> > > agree?
> > 
> > Yeah, that should do I guess. See my other mail for a simpler, less
> > time consuming way to test. And as noted in there, it seems to happen
> > only on ext3 filesystems mounted using ext4.
> 
> > Filesystem features:      has_journal resize_inode dir_index filetype
> >                           needs_recovery sparse_super large_file
> 
> Yeah, so you haven't turned on any of the ext4 filesystem features, I
> assume because you wanted to be easily go back to ext3 if you ran into
> problems?  OK, that's a good starting point.

Right.

Show 9 quoted lines

> I'm guessing it's the presence or absence of one of the ext4-specific
> filesystem features, most probably the extents feature (which is why I
> had asked you to to send me your dumpe2fs -h output).  
> 
> So the next step is to create an ext3 filesystem with a git repository
> on it, and then to gradually turn on various ext4 specific features
> and see when the bug ends up getting replicated.  If I had to guess
> it's the lack (or absense) of the extents feature, but I'll have to
> run the test and find out for sure.

Yep, seems to be extents. Test script:

#!bin/bash

do_test ()
{
	mke2fs -j -m 1 /dev/loop0 -O $1 2>&1
	mount -t ext4 /dev/loop0 foo
	cd foo
	git init 
	echo 123 > foo
	git add foo
	git commit -m test
	sleep 2
	sync
	git diff-index --exit-code HEAD && echo "Good: $1" >&2 ||
		echo "Bad: $1" >&2
	cd ..
	umount foo
}

for opt in extent dir_index uninit_bg extent,dir_index extent,uninit_bg\
	dir_index,uninit_bg extent,dir_index,uninit_bg
do
	do_test "$opt" > /dev/null
done

Results:
$ sudo bash e3t.sh 
Good: extent
Bad: dir_index
Bad: uninit_bg
Good: extent,dir_index
Good: extent,uninit_bg
Bad: dir_index,uninit_bg
Good: extent,dir_index,uninit_bg

Björn