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

From: Michael J Gruber <[email-masked]>
Date: Thu, 10 Jun 2010 11:05:08 +0200

Andreas Ericsson venit, vidit, dixit 10.06.2010 10:03:
> On 06/09/2010 10:21 PM, Michael J Gruber wrote:
>> 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