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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Erik Faye-Lund venit, vidit, dixit 10.06.2010 11:39:
> On Thu, Jun 10, 2010 at 11:05 AM, Michael J Gruber
> <git@xxxxxxxxxxxxxxxxxxxx> wrote:
>> 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.
>>
> <snip>
>>
>> Also, having git reset --index do the equivalent of "rm .git/index &&
>> git reset" might be good to have.
>>
> 
> Doesn't "git update-index --refresh" do the trick?
> 

No.

And neither does --really-refresh.

I guess we need --I-really-mean-it-refresh.

In fact, not even after recompiling with USE_STDEV=y that
--really-refresh helps which stomps me.But what do I know.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]