[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4BAA5035.1060906@panasas.com>
Date: Wed, 24 Mar 2010 19:47:33 +0200
From: Boaz Harrosh <bharrosh@...asas.com>
To: Al Viro <viro@...IV.linux.org.uk>
CC: linux-fsdevel <linux-fsdevel@...r.kernel.org>,
"J. Bruce Fields" <bfields@...i.umich.edu>,
pNFS Mailing List <pnfs@...ux-nfs.org>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [pnfs] [GIT BISECT] first bad commit: 1f36f774 Switch !O_CREAT
case to use of do_last()
On 03/24/2010 07:32 PM, Boaz Harrosh wrote:
> On 03/24/2010 07:15 PM, Boaz Harrosh wrote:
>> On 03/24/2010 06:39 PM, Al Viro wrote:
>>> On Wed, Mar 24, 2010 at 06:10:52PM +0200, Boaz Harrosh wrote:
>>>> On 03/24/2010 06:07 PM, Al Viro wrote:
>>>>> On Wed, Mar 24, 2010 at 06:04:56PM +0200, Boaz Harrosh wrote:
>>>>>>> Bloody impressive... Does that happen to underlying fs or to what you
>>>>>>> are seeing via NFS?
>>>>>>
>>>>>> Only via NFS. All local access is fine.
>>>>>>
>>>>>> After the corruption above I can cd to the local mount cp a fresh copy
>>>>>> of .git/index file and play around just fine.
>>>>>> Once I return to the NFS mounted directory, a git status will do it.
>>>>>> It does not matter if caches are cold (Takes a long time) or hot it happens
>>>>>> every time.
>>>>>>
>>>>>> Weird I know, I'm playing some more with it as we speak
>>>>>
>>>>> What happens if you export to box running older kernel *or* from box
>>>>> running older kernel? IOW, is that nfsd or nfs client getting unhappy?
>>>>> I'd suspect the latter, but...
>>>>
>>>>
>>>> Good question, I'm just getting to that because currently it's all
>>>> over localhost (same kernel, BTW inside a UML)
>>>>
>>>> I will try what you said. Please through any other tests on me, if needed.
>>>
>>
>> As you suspected old-server+new-client fails. any-thing+old-client is
>> fine. (two separate machines this time)
>>
>>> Very interesting... Just to see which path we are hitting: add
>>> if (IS_ERR(nd->intent.open.file))
>>> printk("foo: %s", pathname);
>>> right after
>>> error = do_lookup(nd, &nd->last, path);
>>> if (error)
>>> goto exit;
>>> in fs/namei.c:do_last() and see whether we are hitting it or not on objects
>>> that get corrupted.
>>
>> Sorry was busy shifting setups, didn't see your mail, will do that next ...
>>
>> Thanks
>> Boaz
>
>
> Below is what I changed. (I hope its what you meant)
> It does not get hit, just that git corruption as before but I don't see the prints.
> I'll try running with nfs dbg-prints on see what it does around the time gits complains
>
> Boaz
>
Attached is an output of when I:
$ echo $((0x7fff)) > /proc/sys/sunrpc/nfs_debug
and then run git status. (On a new client)
We can see the complains after things got broken but what broke it
that's hard for me to see.
(If the file is too big I'll put it on the web somewhere, see if it arrives)
Boaz
> ---
> diff --git a/fs/namei.c b/fs/namei.c
> index 1c0fca6..d1c96f0 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -1650,6 +1650,12 @@ static struct file *do_last(struct nameidata *nd, struct path *path,
> error = do_lookup(nd, &nd->last, path);
> if (error)
> goto exit;
> +
> + if (IS_ERR(nd->intent.open.file)) {
> + printk(KERN_ERR "foo: %s", pathname);
> + WARN_ON(1);
> + }
> +
> error = -ENOENT;
> if (!path->dentry->d_inode)
> goto exit_dput;
>
>
> _______________________________________________
> pNFS mailing list
> pNFS@...ux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/pnfs
View attachment "git-status-bad-run.txt" of type "text/plain" (439491 bytes)
Powered by blists - more mailing lists