From: Bernd Schubert <bernd-schubert@web.de>
To: nfs@lists.sourceforge.net
Subject: Re: client apps not surviving nfsd restart
Date: Fri, 20 Aug 2004 15:25:31 +0200 [thread overview]
Message-ID: <200408201525.36681.bernd-schubert@web.de> (raw)
In-Reply-To: <4125EA9F.3040304@bio.ifi.lmu.de>
[-- Attachment #1: Type: text/plain, Size: 2736 bytes --]
Hello Frank,
> 1) After installing SusE 9.0, the default was set to nfs-over-tcp. I didn't
> know that, but suddenly after every server reboot I had at least 4-5
> of the work station users complaining about stale NFS handles, e.g.,
> /usr was stale and so java didn't start anymore etc. It's not really
> reproducable by some certain sequence of starting apps and rebooting
> the server etc., but it happens every time the server has to reboot
> with a few clients.
can you confirm this with vanilla client/server kernel version? We have 45
diskless clients here and each of them has no problem on a server reboot.
This works for more than two years with vanilla 2.4.X kernel versions. Since
about 4-5 month we also use nfs-over-tcp and this also has no negative
effect.
We also tried using 2.6.7 on our server, but it always crashed every morning
with page allocation errors, so we had to give up with this version and
switched back to 2.4.X. However, although the server was rebooted every
morning (and/or the failover server took over), this caused no problems for
the clients (except for the directories mounted from ClusterNFS, but thats a
different more complicated CNFSD related story).
>
> In the NFS howto I read that the disadvantage of nfs-over-tcp is that
> "If your server crashes in the middle of a packet transmission, the
> client will hang and any shares will need to be unmounted and
> remounted."
This howto seems to be slightly outdated.
>
> But I thought a clean reboot with a clean stop and later start of the
> nfsserver shouldn't make a problem.
It doesn't make a problems with vanilla kernel version.
[snip]
>
> 2) We are currently testing kernel 2.6.8.1. The nfs behaviour seems
> to have changed in some ways. Running e.g. "find /" on a diskless
> client with kernel 2.4 would just hang when the server rebootet
> and later go on when the server was back.
> With 2.6.8.1, the find command will immediately abort and report
> some stale nfs handles.
We only tested 2.6.7 and it caused no such problems, as we have failover, I
tested failover during file transfers and this worked like a charm.
Cheers,
Bernd
PS: About 1.5 years ago we were forced to use a Suse kernel on our server (due
to a closed-sources binary only kernel module) and this kernel caused a lot
of nfs related trouble for us. As the module also didn't work properly we
finally decided not to buy this software ;)
--
Bernd Schubert
Physikalisch Chemisches Institut / Theoretische Chemie
Universität Heidelberg
INF 229
69120 Heidelberg
e-mail: bernd.schubert@pci.uni-heidelberg.de
[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2004-08-20 13:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-20 12:12 client apps not surviving nfsd restart Frank Steiner
2004-08-20 13:02 ` Olaf Kirch
2004-08-20 13:55 ` Frank Steiner
2004-08-20 13:21 ` Olaf Kirch
2004-08-20 14:26 ` Frank Steiner
2004-08-20 13:25 ` Bernd Schubert [this message]
2004-08-20 14:34 ` Frank Steiner
2004-08-20 14:46 ` Olaf Kirch
2004-08-20 18:28 ` Hans-Peter Jansen
2004-08-20 15:31 ` mehta kiran
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=200408201525.36681.bernd-schubert@web.de \
--to=bernd-schubert@web.de \
--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.