What type of hardware is involved.

David

Olivier wrote:
> Hi all
>
> I have the following error message:
>
> May 04 20:44:37 myclient kernel: nfs: server myserver not responding,
still trying
> May 04 20:44:37 myclient kernel: nfs: server myserver OK
> May 04 20:44:53 myclient kernel: nfs: server myserver not responding,
still trying
> May 04 20:44:54 myclient kernel: nfs: server myserver OK
> May 04 20:47:05 myclient kernel: nfs: server myserver not responding,
still trying
>
> and after the client stay waiting
> and you can ping rlogin ssh ... to the serveur.
>
> the server is: Red Hat 9 with only udp nfs v2 and v3 protocol
> the client is: RHEL 3
>
> there is no firewall on the both machines, it is a local network.
>
> Any help will be deeply appreciated!
> Olivier

In article <1116369647.470325.128940@g14g2000cwa.googlegroups. com>,
davegu1 wrote:
>Olivier wrote:
>>
>> May 04 20:44:37 myclient kernel: nfs: server myserver not responding,
>still trying
>> May 04 20:44:37 myclient kernel: nfs: server myserver OK
>> May 04 20:44:53 myclient kernel: nfs: server myserver not responding,
>still trying
>> May 04 20:44:54 myclient kernel: nfs: server myserver OK
>
>What type of hardware is involved.

Please don't top-post.

Anyway, the type of hardware is irrelevant to a first approximation.
I can't explain why this is, but it is a VERY common phenomon, and
I have seen it on many different transports (and that is counting
all Ethernets as one!) What it means is that there has been a
glitch (maybe on the network, maybe a scheduler delay, maybe a
too-tight timeout setting) and NFS has recovered. My success rate
at tracking down the trigger is poor, and that of tracking down the
cause is nil.

Most people ignore it, which is why it is still so common :-(



Regards,
Nick Maclaren.

**** you.

"Nick Maclaren" wrote in message
news:d6eu75$13v$1@gemini.csx.cam.ac.uk
> In article <1116369647.470325.128940@g14g2000cwa.googlegroups. com>,
> davegu1 wrote:
>> Olivier wrote:
>>>
>>> May 04 20:44:37 myclient kernel: nfs: server myserver not
>>> responding, still trying May 04 20:44:37 myclient kernel: nfs:
>>> server myserver OK
>>> May 04 20:44:53 myclient kernel: nfs: server myserver not
>>> responding, still trying May 04 20:44:54 myclient kernel: nfs:
>>> server myserver OK
>>
>> What type of hardware is involved.
>
> Please don't top-post.

Is there a code somewhere where someone can take a look at what code
could this be causing the message.

David


Nick Maclaren wrote:
> In article <1116369647.470325.128940@g14g2000cwa.googlegroups. com>,
> davegu1 wrote:
> >Olivier wrote:
> >>
> >> May 04 20:44:37 myclient kernel: nfs: server myserver not
responding,
> >still trying
> >> May 04 20:44:37 myclient kernel: nfs: server myserver OK
> >> May 04 20:44:53 myclient kernel: nfs: server myserver not
responding,
> >still trying
> >> May 04 20:44:54 myclient kernel: nfs: server myserver OK
> >
> >What type of hardware is involved.
>
> Please don't top-post.
>
> Anyway, the type of hardware is irrelevant to a first approximation.
> I can't explain why this is, but it is a VERY common phenomon, and
> I have seen it on many different transports (and that is counting
> all Ethernets as one!) What it means is that there has been a
> glitch (maybe on the network, maybe a scheduler delay, maybe a
> too-tight timeout setting) and NFS has recovered. My success rate
> at tracking down the trigger is poor, and that of tracking down the
> cause is nil.
>
> Most people ignore it, which is why it is still so common :-(
>
>
>
> Regards,
> Nick Maclaren.

Hi all,

There are no hardware problem, I have already change the switch and the cable.

The client that fail is a v20z from Sun Microsystems, an I have also 15 clients
on several platforms as solaris 9 on sparc, some PC in Solaris 10 and fedora core 3.

I don't have any log for this problem.

Olivier.

davegu1 a écrit :
> Is there a code somewhere where someone can take a look at what code
> could this be causing the message.
>
> David
>
>
> Nick Maclaren wrote:
>
>>In article <1116369647.470325.128940@g14g2000cwa.googlegroups. com>,
>>davegu1 wrote:
>>
>>>Olivier wrote:
>>>
>>>>May 04 20:44:37 myclient kernel: nfs: server myserver not
>
> responding,
>
>>>still trying
>>>
>>>>May 04 20:44:37 myclient kernel: nfs: server myserver OK
>>>>May 04 20:44:53 myclient kernel: nfs: server myserver not
>
> responding,
>
>>>still trying
>>>
>>>>May 04 20:44:54 myclient kernel: nfs: server myserver OK
>>>
>>>What type of hardware is involved.
>>
>>Please don't top-post.
>>
>>Anyway, the type of hardware is irrelevant to a first approximation.
>>I can't explain why this is, but it is a VERY common phenomon, and
>>I have seen it on many different transports (and that is counting
>>all Ethernets as one!) What it means is that there has been a
>>glitch (maybe on the network, maybe a scheduler delay, maybe a
>>too-tight timeout setting) and NFS has recovered. My success rate
>>at tracking down the trigger is poor, and that of tracking down the
>>cause is nil.
>>
>>Most people ignore it, which is why it is still so common :-(
>>
>>
>>
>>Regards,
>>Nick Maclaren.
>
>

> Hi all,

> There are no hardware problem, I have already change the switch and the cable.

> The client that fail is a v20z from Sun Microsystems, an I have also 15 clients
> on several platforms as solaris 9 on sparc, some PC in Solaris 10 and fedora core 3.

> I don't have any log for this problem.
Hello Olivier,
Sometimes an NFS server can't respond fast enough because it
is temporarily overloaded.

Are there other applications running on the server that might be periodically
depriving NFS of resources?

Do you have a rogue NFS client, stuck in a tight loop, making NFS requests ?

Also look into tuning your server's configuration: things like the
size of the file system buffer cache and, if appropriate, the number
of nfsds.

DavidN -- University of Liverpool Computer Science

Olivier wrote:
> Hi all
>
> I have the following error message:
>
> May 04 20:44:37 myclient kernel: nfs: server myserver not responding,
still trying
> May 04 20:44:37 myclient kernel: nfs: server myserver OK
> May 04 20:44:53 myclient kernel: nfs: server myserver not responding,
still trying
> May 04 20:44:54 myclient kernel: nfs: server myserver OK
> May 04 20:47:05 myclient kernel: nfs: server myserver not responding,
still trying

I find the timestamps to be interesting. A second or less after the
"not responding" is logged, "OK" is then logged.

Might your NFS timeouts be too short? What's the value of
timeo= and retrans=.

You need to look at the packet traces to see if stuff is actually
getting dropped, or if your timeouts are too short.

If you aren't already, use TCP as your transport instead of UDP,
and make sure your timeout is at least 60 seconds.

>
> and after the client stay waiting
> and you can ping rlogin ssh ... to the serveur.
>
> the server is: Red Hat 9 with only udp nfs v2 and v3 protocol
> the client is: RHEL 3
>
> there is no firewall on the both machines, it is a local network.
>
> Any help will be deeply appreciated!
> Olivier