From: Christian Reis <kiko@async.com.br>
To: Neil Brown <neilb@cse.unsw.edu.au>
Cc: linux-kernel@vger.kernel.org, NFS@lists.sourceforge.net
Subject: Re: NFS client locking hangs for period
Date: Sun, 26 Jan 2003 14:02:00 -0200 [thread overview]
Message-ID: <20030126140200.A25438@blackjesus.async.com.br> (raw)
In-Reply-To: <15922.2657.267195.355147@notabene.cse.unsw.edu.au>; from neilb@cse.unsw.edu.au on Sat, Jan 25, 2003 at 02:54:09PM +1100
On Sat, Jan 25, 2003 at 02:54:09PM +1100, Neil Brown wrote:
> Hmmm. So you have several clients all mounting the same root
> filesystem, and mounting it writable? That doesn't sound like a plan
> for success. How do you make sure the clients don't tread over each
> other when using /etc files?
The truth is few (broken wrt the FHS) programs actually write to /etc. I
have set up everything so nothing is written to in /etc, and it actually
works very well (have to use a special init(8) that doesn't write to
/etc/ioctl.save). This setup has been running for almost a year now,
with the locking problem being the only one left to fix.
> I suspect that what you really want is to mount root read-only, or
> mount separate roots for each client, and then in either case to mount
> with the "nolock" flag.
Well, mounting root read-only is a good idea but it sacrifices being
able to administer the system from any station, and it also puts a lot
of burden on me to fix *all* programs to not write to anywhere on it.
This shouldn't be too hard, but we're still just working around the bug,
which I would really like to identify and fix.
> I suspect that your problem is related to the client trying to do
> locking, but no having statd running on the client.
I am 100% positive statd runs on every single client. This problem here
only happens spuriously. It goes away when I restart nfsd and mountd
(in that order). It really does look like a bug <wink>
> You cannot meaningfully do locking on an NFS mounted root filesystem.
> Infact, I think it would be good if the default mount options for nfs
> root included nolock... and if I read fs/nfs/nfsroot.c:root_nfs_name
> correctly, nolock is the default. Are you overriding that default
> be explicitly setting "lock"??
Nope. I've just tested and the default (specifying no lock option upon
bootup) really is nolock:
/dev/root on / type nfs (rw,v3,rsize=8192,wsize=8192,hard,udp,nolock,addr=192.168.99.4)
I wonder why you can't do locking on NFS root (if it's a current
limitation of if it doesn't make sense).
But I also think this problem shouldn't be happening if no locking was
going on. And when I checked using nlm_debug it sure did seem locking
was being used. What do you make of it?
Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL
next prev parent reply other threads:[~2003-01-26 15:53 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-24 20:49 NFS client locking hangs for period Christian Reis
2003-01-25 3:54 ` Neil Brown
2003-01-26 16:02 ` Christian Reis [this message]
2003-01-26 21:49 ` [NFS] " Trond Myklebust
2003-01-26 22:47 ` Christian Reis
2003-01-26 23:02 ` Trond Myklebust
2003-01-26 23:56 ` Christian Reis
2003-01-27 0:06 ` Trond Myklebust
2003-01-27 2:19 ` Dell Latitude CPi keyboard problems since 2.5.42 Tom Sightler
2003-01-28 8:14 ` [NFS] Re: NFS client locking hangs for period Denis Vlasenko
2003-01-28 16:47 ` Christian Reis
2003-01-28 8:00 ` Denis Vlasenko
2003-01-28 16:44 ` Christian Reis
2003-01-29 21:53 ` Daniel Egger
-- strict thread matches above, loose matches on Subject: below --
2003-04-25 4:57 Christian Reis
2003-04-25 4:57 ` Christian Reis
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=20030126140200.A25438@blackjesus.async.com.br \
--to=kiko@async.com.br \
--cc=NFS@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@cse.unsw.edu.au \
/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.