headers
Wei Yongjun | 1 Jul 2008 12:07
Favicon

NFSv4 client's BUG?

I have the following test program, but when it run, fopen may return 
EIO, is this a bug of NFSv4 client?
NFSv4 client is 2.6.26-rc6.

-------------------------tstfopen.c-------------------------------------

#include <stdio.h>
#include <error.h>
#include <stdlib.h>
#include <string.h>

char * fname;
#define TEMPLATE "HighInodeXXXXXX"
int main(int argc, char *argv[]) {
        FILE *fp;
        char filename[4096];
        int filedes[4096];
        int i;

        if (argc != 2) {
                printf("Usage: %s filename\n", argv[0]);
                exit(1);
        }

        fname = argv[1];

        for (i = 0; i < 4096; i++) {
                if (i % 100 == 0)
                        printf("i = %d\n", i);
(Continue reading)

Permalink | Reply | 18 comments |
headers
Ellard, Daniel | 1 Jul 2008 15:08
Picon

RE: NFSv4 client's BUG?


You're never closing filedes[i], and eventually you're running out of
file descriptors.

Add 

	close(filedes[i]);

After

	write(filedes[i], "...

-Dan 

-----Original Message-----
From: Wei Yongjun [mailto:yjwei <at> cn.fujitsu.com] 
Sent: Tuesday, July 01, 2008 6:08 AM
To: nfsv4 <at> linux-nfs.org
Subject: NFSv4 client's BUG?

I have the following test program, but when it run, fopen may return
EIO, is this a bug of NFSv4 client?
NFSv4 client is 2.6.26-rc6.

-------------------------tstfopen.c-------------------------------------

#include <stdio.h>
#include <error.h>
#include <stdlib.h>
#include <string.h>
(Continue reading)

Permalink | Reply | 17 comments |
headers
Wei Yongjun | 2 Jul 2008 02:39
Favicon

Re: NFSv4 client's BUG?

Ellard, Daniel wrote:
> You're never closing filedes[i], and eventually you're running out of
> file descriptors.
>
> Add 
>
> 	close(filedes[i]);
>
> After
>
> 	write(filedes[i], "...
>   

This is not the problem. Because I used ulimit -n 5000 to let program 
can open 5000 files.
The "fopen: Input/output error" may happend when I just open 40 files, 
it is random.

> -----Original Message-----
> From: Wei Yongjun [mailto:yjwei <at> cn.fujitsu.com] 
> Sent: Tuesday, July 01, 2008 6:08 AM
> To: nfsv4 <at> linux-nfs.org
> Subject: NFSv4 client's BUG?
>
> I have the following test program, but when it run, fopen may return
> EIO, is this a bug of NFSv4 client?
> NFSv4 client is 2.6.26-rc6.
>
> -------------------------tstfopen.c-------------------------------------
>
(Continue reading)

Permalink | Reply | 16 comments |
headers
J. Bruce Fields | 2 Jul 2008 02:49

Re: NFSv4 client's BUG?

On Wed, Jul 02, 2008 at 08:39:16AM +0800, Wei Yongjun wrote:
> Ellard, Daniel wrote:
> > You're never closing filedes[i], and eventually you're running out of
> > file descriptors.
> >
> > Add 
> >
> > 	close(filedes[i]);
> >
> > After
> >
> > 	write(filedes[i], "...
> >   
> 
> This is not the problem. Because I used ulimit -n 5000 to let program 
> can open 5000 files.
> The "fopen: Input/output error" may happend when I just open 40 files, 
> it is random.

What's the server?  Could you watch the traffic in wireshark and see
whether the server is returning an error on the failing open?

--b.

> 
> 
> > -----Original Message-----
> > From: Wei Yongjun [mailto:yjwei <at> cn.fujitsu.com] 
> > Sent: Tuesday, July 01, 2008 6:08 AM
> > To: nfsv4 <at> linux-nfs.org
(Continue reading)

Permalink | Reply | 13 comments |
headers
Daniel Ellard | 2 Jul 2008 02:52
Picon

Re: NFSv4 client's BUG?

Wei Yongjun wrote:
> Ellard, Daniel wrote:
>> You're never closing filedes[i], and eventually you're running out of
>> file descriptors.
>>
>> Add
>>     close(filedes[i]);
>>
>> After
>>
>>     write(filedes[i], "...
>>   
> 
> This is not the problem. Because I used ulimit -n 5000 to let program 
> can open 5000 files.

Well, it's *a* problem, even if it's not *the* problem.

Another candidate: writing 23 bytes when there are only 11 bytes in the 
string.  Probably wouldn't cause this, but who knows.

Randomness is worrisome.  Let's see if we can narrow things down at all:

- What happens when you run this on a local file system?  Same thing?

- Are you cleaning out the directory every time, or are you beginning 
each run with an arbitrary number of temp files left over from before? 
(maybe mkstemp is confused by large numbers of files in its space)  Does 
cleaning out the directory make the program break in a predictable manner?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Wei Yongjun | 2 Jul 2008 03:55
Favicon

Re: NFSv4 client's BUG?

J. Bruce Fields wrote:
> On Wed, Jul 02, 2008 at 08:39:16AM +0800, Wei Yongjun wrote:
>   
>> Ellard, Daniel wrote:
>>     
>>> You're never closing filedes[i], and eventually you're running out of
>>> file descriptors.
>>>
>>> Add 
>>>
>>> 	close(filedes[i]);
>>>
>>> After
>>>
>>> 	write(filedes[i], "...
>>>   
>>>       
>> This is not the problem. Because I used ulimit -n 5000 to let program 
>> can open 5000 files.
>> The "fopen: Input/output error" may happend when I just open 40 files, 
>> it is random.
>>     
>
> What's the server?  Could you watch the traffic in wireshark and see
> whether the server is returning an error on the failing open?
>   

I have tcpdump the packets, there is no error return by the server.

> --b.
(Continue reading)

Permalink | Reply | 12 comments |
headers
Wei Yongjun | 2 Jul 2008 04:30
Favicon

Re: NFSv4 client's BUG?

Daniel Ellard wrote:
> Wei Yongjun wrote:
>> Ellard, Daniel wrote:
>>> You're never closing filedes[i], and eventually you're running out of
>>> file descriptors.
>>>
>>> Add
>>>     close(filedes[i]);
>>>
>>> After
>>>
>>>     write(filedes[i], "...
>>>   
>>
>> This is not the problem. Because I used ulimit -n 5000 to let program 
>> can open 5000 files.
>
> Well, it's *a* problem, even if it's not *the* problem.
>
> Another candidate: writing 23 bytes when there are only 11 bytes in 
> the string.  Probably wouldn't cause this, but who knows.
>
> Randomness is worrisome.  Let's see if we can narrow things down at all:
>
> - What happens when you run this on a local file system?  Same thing?

local file system has no problem.

>
> - Are you cleaning out the directory every time, or are you beginning
(Continue reading)

Permalink | Reply | 0 comments |
headers
Guillaume Rousse | 2 Jul 2008 14:00
Picon
Picon
Favicon

Re: nfs client hanging

Guillaume Rousse a écrit :
> Guillaume Rousse a écrit :
>> And I keep getting those "RPC: failed to contact local rpcbind server 
>> (errno 5)" error messages in the logs. I'm switching to regular 
>> portmap instead of rpcbind to see if it helps.
> Replacing rpcbind with portmap doesn't help, the problem still happens.
> 
> Here is a summary of the situation:
> - the server is a netapp NAS 270 running DAT 7.2.5
> 
> - the client is a linux x86_64 host running kernel 2.6.24.5, with 
> following patches applied
>  * 46f8a64bae11f5c9b15b4401f6e9863281999b66
>  * 4e99a1ff3410c627a428d5ddb6cd2e7bc908a486
>  * 63c86716ea34ad94d52e5b0abbda152574dc42b5
>  * 8e60029f403781b8a63b7ffdb7dc1faff6ca651e
>  * c37dcd334c0b0a46a90cfa13b9f69e2aaa89bc09
> 
> - the client doesn't have CONFIG_SUNRPC_BIND34 enabled
> 
> - there is no filtering between the client and the server
> 
> - delegation is disabled
> 
> - the file system is mounted with the following options: 
> rw,nosuid,nodev,hard,intr
> 
> - when the hang occurs, the server is disconnected (no connection found 
> in netstat -t output)
[..]
(Continue reading)

Permalink | Reply | 12 comments |
headers
Guillaume Rousse | 2 Jul 2008 15:44
Picon
Picon
Favicon

Re: nfs client hanging

Guillaume Rousse a écrit :
> Given this problem only occurs for home directories for a host with a 
> very specific usage (transient ssh logins for svn commits, or web home 
> page access), I'm more and more considering an autofs issue with 
> repeated mount/umount events, rather than a pure nfs issue. With a 
> similar setup, we have no problem for long-lived mount points, such as 
> homedirs on workstations. And I just found report on autofs ML of such 
> kind of issues:
> http://linux.kernel.org/pipermail/autofs/2008-June/004814.html

With a static NFS mount, the problem still appears, but a bit 
differently, as the filer is still connected
tcp        0      0 node3.cluster.msr-inria:755 
msr-nas1.msr-inria.inri:nfs ESTABLISHED

And this time the log output is a bit different:
Jul  2 15:43:35 localhost kernel: RPC:       new task initialized, 
procpid 22288
Jul  2 15:43:35 localhost kernel: RPC:       allocated task ffff81042bc77900
Jul  2 15:43:35 localhost kernel: RPC:     0 looking up UNIX cred
Jul  2 15:43:35 localhost kernel: RPC:   491 __rpc_execute flags=0x80
Jul  2 15:43:35 localhost kernel: RPC:   491 call_start nfs4 proc 1 (sync)
Jul  2 15:43:35 localhost kernel: RPC:   491 call_reserve (status 0)
Jul  2 15:43:35 localhost kernel: RPC:   491 reserved req 
ffff810429d60e70 xid c2586af8
Jul  2 15:43:35 localhost kernel: RPC:   491 call_reserveresult (status 0)
Jul  2 15:43:35 localhost kernel: RPC:   491 call_allocate (status 0)
Jul  2 15:43:35 localhost kernel: RPC:   491 allocated buffer of size 
972 at ffff81042509d000
Jul  2 15:43:35 localhost kernel: RPC:   491 call_bind (status 0)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kevin Coffman | 2 Jul 2008 17:53
Picon
Favicon

Re: [Patch] enable preferred realms for ccache searching

Hello Lukas,
I'm fixing some things up in this patch (see comments below) and I
have a question as well:  Is "score" ever anything besides zero or
one?  I can see how it might be used in the future for including more
preferences, but today it is only zero or one?

Thanks,
K.C.

On Tue, Jun 24, 2008 at 11:35 AM, Lukas Hejtmanek <xhejtman <at> ics.muni.cz> wrote:
>
> The rpc.gssd scans for any suitable kerberos ticket. In cross-realm
> environment this would not have to be the desired behaviour. Therefore a new
> option is presented -R preferred realm so that the rpc.gssd preferrs tickets
> from this realm. By default, no realm is preferred so we follow the original
> behavior.
>
> Signed-off-by: Lukas Hejtmanek <xhejtman <at> ics.muni.cz>
>
> diff --git a/utils/gssd/gssd.c b/utils/gssd/gssd.c
> index ff5a454..c7f9bdd 100644
> --- a/utils/gssd/gssd.c
> +++ b/utils/gssd/gssd.c
>  <at>  <at>  -61,6 +61,7  <at>  <at>  char *ccachesearch[GSSD_MAX_CCACHE_SEARCH + 1];
>  int  use_memcache = 0;
>  int  root_uses_machine_creds = 1;
>  int  ccache_timeout = 0;
> +char *preferred_realm = NULL;
>
>  void
(Continue reading)

Permalink | Reply | 0 comments |

Gmane