Re: Misterious warning about file system boundaries [It's a bug, not a mystery.]

Andreas Ericsson venit, vidit, dixit 10.06.2010 10:03:

On 06/09/2010 10:21 PM, Michael J Gruber wrote:

quoted

Heya,

now what is going on here? After upgrading to current next I get

warning: working tree spans across filesystems but
GIT_DISCOVERY_ACROSS_FILESYSTEM is not set.

in several repos, such as my local git.git repo. That is certainly on a
single file system only (ext4 over lvm over luks, all on one partition,
Fedora 13). I also get this for another repo, but not for every repo. It
goes away when I set the var and comes back when I don't set it, of course.

Although I haven't bisected this should be due to
52b98a7 (write-index: check and warn when worktree crosses a filesystem
boundary, 2010-04-04).

How does the code detect a file system boundary, and where could it go
wrong?

According to the patch, it checks if the device id recorded from stat(2)
is the same for all files and, if not, warns about it.

It seems that your interpretation of "one partition" differs from that
reported by the kernel. Why that is so, I have no idea.

I'm sorry, but "my interpretation"? WTF? This is all on
/home/mjg/src/git which has no bind mounts whatsoever.

I actually mixed up my / and /home situation above, /home is even
simpler: single ext3 over luks dm device over single "real" partition.
All of this (except for single ext3 part.) should not matter, of course.

I bisected it just be sure, and it boils down to 9780e62 which is the
commit merging 52b98a7 to next.

git ls-files|xargs stat -c "%d %D" |sort|uniq

gives

64772 fd04

which is, in particular, 1 device only. Now, here comes funny. After
changing write_index() to print the two ce_dev's which differ, i.e.
printf("%d %d\n", ce->ce_dev, cache[first_valid_ent]->ce_dev);
 I have:

./git-status -s|sort|uniq -c
warning: working tree spans across filesystems but
GIT_DISCOVERY_ACROSS_FILESYSTEM is not set.
    150 64770 64772
    662 64771 64772
      1  M read-cache.c

WTF???

git reset --hard doesn't help this.

rm .git/index && git reset does help.

So, it seems that nowadays not even "reset --hard" refreshes the index
completely. After a reboot your device IDs may change, of course, and
files on the same file system will have different ce_dev values in the
index depending on when their index entry was refreshed last.

I really don't know how to fix this (other than by refreshing stat info
in write_index() before warning). Debugging it was quite an exercise
already.

Also, having git reset --index do the equivalent of "rm .git/index &&
git reset" might be good to have.

I'm keeping the bad index, btw, so that I can test a possible future fix.

Michael