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

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

On Fri, Jun 05, 2009 at 05:02:12PM +0200, Björn Steinbrink wrote:

quoted

On 2009.06.05 10:55:08 -0400, Theodore Tso wrote:

quoted

On Fri, Jun 05, 2009 at 03:21:26PM +0200, Björn Steinbrink wrote:

quoted

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.

quoted

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.

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