All of lore.kernel.org
 help / color / mirror / Atom feed
From: Olivier Croquette <ocroquette@free.fr>
To: nfs@lists.sourceforge.net
Subject: NFS client hangsNFS client hangs
Date: Sun, 26 Feb 2006 13:12:52 +0100	[thread overview]
Message-ID: <44019B44.7050001@free.fr> (raw)

I have a strange problem since a few months on some Linux clients.

I have a file server accessed through:
   - NFS from Linux clients (autofs, but direct mount causes same effect)
   - Samba from Windows clients

This works since several years like a charm, but as I said there is a
strange problem that appeared recently:

I have a directory, to which I generate code from Windows (\\server\dir)
I can see it under Linux (/mount/dir) where I can access (compile) the
files.

However, when I regenerate the file under Windows again (ie. I overwrite
the old files), and I try to compile the files again under Linux, "make"
hangs simply in D state:

# ps aux | grep make
user 7177 0.0  0.0 1984 760 pts/1 D+ 16:13 0:00 make -f myMakefile

The load average goes up one unit each time I reproduce this test 
(apparently, processes in non-interruptible state are considered as 
running).

 From then, the following actions does NOT unblock the process:
   - stopping or restarting the NFS service on the server
   - restarting the server
   - restarting autofs on the client
   - trying to unmount the NFS mount

If I reboot the client, all goes back to normal, until I repeat the
process below (ie. overwriting and compiling).
Typically, "shutdown -r" does not work, I have to "reboot -f".

There is nothing interesting in /var/log on the server nor on the
client.

Versions used on the server:
   - SuSE 9.3
   - kernel-default-2.6.11.4-21.11
   - nfs-utils-1.0.7-3
   - samba-3.0.13-1.1
   - filesystem: reiserfs

On the client:
   - SuSE 9.3
   - kernel-smp-2.6.11.4-21.10
   - nfs-utils-1.0.7-3
   - mounts:
     automount on /mount type autofs 
(rw,fd=4,pgrp=6529,minproto=2,maxproto=4)
     serv:/dir on /mount/dir type nfs (rw,addr=*IP*)
   - CPU: P4 dual core (2 virtual CPUs)
Note: maxcpus=0 does not make any difference regarding this issue. I
could not test yet with kernel compiled without SMP at all.


On the following clients on the very same server and network, I could 
not reproduce the problem:

   - SuSE 9.1
   - kernel-default-2.6.5-7.202.7
   - nfs-utils-1.0.6-103
   - same mounts
   - CPU: P4 single core

   - SuSE 10.0
   - Kernel: 2.6.14.3-default (from kernel.org)
   - nfs-utils-1.0.7-13
   - same mounts


Any idea?
Seems to me as it is related to the SMP. What do you think?
How to debug that deeper?




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

                 reply	other threads:[~2006-02-26 12:12 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44019B44.7050001@free.fr \
    --to=ocroquette@free.fr \
    --cc=nfs@lists.sourceforge.net \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.