linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  reply	other threads:[~2003-01-26 15:53 UTC|newest]

Thread overview: 15+ 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
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).