git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Michael J Gruber <git@drmicha.warpmail.net>
To: Andreas Ericsson <ae@op5.se>
Cc: Git Mailing List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: Misterious warning about file system boundaries [It's a bug, not a mystery.]
Date: Thu, 10 Jun 2010 11:05:08 +0200	[thread overview]
Message-ID: <4C10AAC4.90405@drmicha.warpmail.net> (raw)
In-Reply-To: <4C109C4F.1030809@op5.se>

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

  reply	other threads:[~2010-06-10  9:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-09 20:21 Misterious warning about file system boundaries Michael J Gruber
2010-06-10  8:03 ` Andreas Ericsson
2010-06-10  9:05   ` Michael J Gruber [this message]
2010-06-10  9:39     ` Misterious warning about file system boundaries [It's a bug, not a mystery.] Erik Faye-Lund
2010-06-10 10:36       ` Michael J Gruber
2010-06-10 10:52         ` Ævar Arnfjörð Bjarmason
2010-06-10 11:02           ` Jeff King
2010-06-10 14:53             ` Junio C Hamano
2010-06-12  4:24               ` Jeff King

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=4C10AAC4.90405@drmicha.warpmail.net \
    --to=git@drmicha.warpmail.net \
    --cc=ae@op5.se \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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).