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

[Björn Steinbrink]

On 2009.06.05 16:12:09 +0200, Björn Steinbrink wrote:
> On 2009.06.05 15:21:26 +0200, Björn Steinbrink wrote:
> > On 2009.06.05 14:24:44 +0200, Björn Steinbrink wrote:
> > > Hi,
> > > 
> > > can't make any sense out of this at all:
> > > 
> > > doener@atjola:git (master) $ git reset --hard HEAD@{1}
> > > HEAD is now at b11cf09 Merge branch 'da/pretty-tempname'
> > > doener@atjola:git (master) $ git update-ref refs/remotes/origin/master HEAD
> > > 
> > > doener@atjola:git (master) $ git pull
> > > >From git://git.kernel.org/pub/scm/git/git
> > >    b11cf09..6096d75  master     -> origin/master
> > > Updating b11cf09..6096d75
> > > Fast forward
> > >  Documentation/RelNotes-1.6.3.2.txt     |   12 +++++-------
> > >  Documentation/git.txt                  |    7 ++++++-
> > >  contrib/completion/git-completion.bash |   12 ++++++++++--
> > >  grep.c                                 |    6 +++++-
> > >  4 files changed, 26 insertions(+), 11 deletions(-)
> > > 
> > > doener@atjola:git (master) $ git diff-index --name-only HEAD
> > > doener@atjola:git (master) $ git diff-index --name-only --cached HEAD
> > > 
> > > *wait a minute, doing nothing*
> > > 
> > > doener@atjola:git (master) $ git diff-index --name-only HEAD
> > > Documentation/RelNotes-1.6.3.2.txt
> > > Documentation/git.txt
> > > contrib/completion/git-completion.bash
> > > grep.c
> > 
> > Hm, looks like this is not a git bug. Went back to 1.5.4, and even that
> > shows the error. So I actually looked at the files, and indeed, the file
> > in the working tree gets modified. stat(1) shows:
> > 
> > Right after the merge:
> >   File: `grep.c'
> >   Size: 16274           Blocks: 32         IO Block: 4096   regular file
> > Device: fd03h/64771d    Inode: 5933481     Links: 1
> > Access: (0644/-rw-r--r--)  Uid: ( 1000/  doener)   Gid: ( 1000/  doener)
> > Access: 2009-06-05 15:02:14.000000000 +0200
> > Modify: 2009-06-05 15:02:14.000000000 +0200
> > Change: 2009-06-05 15:02:14.000000000 +0200
> > 
> > 60 seconds later:
> >   File: `grep.c'
> >   Size: 16274           Blocks: 32         IO Block: 4096   regular file
> > Device: fd03h/64771d    Inode: 5933481     Links: 1
> > Access: (0644/-rw-r--r--)  Uid: ( 1000/  doener)   Gid: ( 1000/  doener)
> > Access: 2009-06-05 15:02:14.000000000 +0200
> > Modify: 2009-06-05 15:02:14.000000000 +0200
> > Change: 2009-06-05 15:02:48.000000000 +0200
> > 
> > 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)
> 
> Hm, yup, seems to be ext4 related, doesn't happen on tmpfs.

OK, so I tested a bit more. And my /home is really just ext3 mounted
with the ext4 driver:

Filesystem features:      has_journal resize_inode dir_index filetype
needs_recovery sparse_super large_file

While my /tmp actually got the ext4 features:
Filesystem features:      has_journal ext_attr resize_inode dir_index
filetype needs_recovery extent sparse_super large_file uninit_bg

And on /tmp, ctime doesn't change.

Playing around a bit more, the ctime change is easily reproducable for
me, without waiting 30-60 seconds. Just running sync will do:

rm foo # We need a new file to be created
echo 123 > foo
stat foo
sleep 2
sync
stat foo


On /home, that sequence shows ctime having changed after the sync, while
on /tmp, no such change happens.

Is this a fault on my side? I thought I had read that you could just
mount ext3 filesystems without any changes and benefit from delayed
allocation and such. Hm?

Björn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/