From: "Björn Steinbrink" <B.Steinbrink@gmx.de>
To: Theodore Tso <tytso@mit.edu>
Cc: Junio C Hamano <gitster@pobox.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
git@vger.kernel.org
Subject: Re: [BUG ext4?] Working tree getting out of date "spontaneously"
Date: Fri, 5 Jun 2009 20:35:38 +0200 [thread overview]
Message-ID: <20090605183538.GE764@atjola.homenet> (raw)
In-Reply-To: <20090605180630.GC6442@mit.edu>
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
next prev parent reply other threads:[~2009-06-05 18:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-05 12:24 [BUG?] Working tree getting out of date "spontaneously" Björn Steinbrink
2009-06-05 13:14 ` Robin Rosenberg
2009-06-05 13:23 ` Björn Steinbrink
2009-06-05 13:21 ` [BUG ext4?] " Björn Steinbrink
2009-06-05 14:12 ` Björn Steinbrink
2009-06-05 14:47 ` [BUG? ext4] git working " Björn Steinbrink
2009-06-05 14:55 ` [BUG ext4?] Working " Theodore Tso
2009-06-05 15:02 ` Björn Steinbrink
2009-06-05 18:06 ` Theodore Tso
2009-06-05 18:35 ` Björn Steinbrink [this message]
2009-06-05 21:38 ` Theodore Tso
2009-06-05 15:39 ` Linus Torvalds
2009-06-05 16:14 ` Björn Steinbrink
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090605183538.GE764@atjola.homenet \
--to=b.steinbrink@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).