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:
> > 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.
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html