public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Christian Reis <kiko@async.com.br>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Neil Brown <neilb@cse.unsw.edu.au>,
	linux-kernel@vger.kernel.org, NFS@lists.sourceforge.net
Subject: Re: [NFS] Re: NFS client locking hangs for period
Date: Sun, 26 Jan 2003 20:47:11 -0200	[thread overview]
Message-ID: <20030126204711.A25997@blackjesus.async.com.br> (raw)
In-Reply-To: <shs8yx7lgyt.fsf@charged.uio.no>; from trond.myklebust@fys.uio.no on Sun, Jan 26, 2003 at 10:49:14PM +0100

On Sun, Jan 26, 2003 at 10:49:14PM +0100, Trond Myklebust wrote:
> >>>>> " " == Christian Reis <kiko@async.com.br> writes:
> 
>      > I wonder why you can't do locking on NFS root (if it's a
>      > current limitation of if it doesn't make sense).
> 
> locking supposes that you are already running a statd daemon, which
> you clearly cannot be doing on an nfsroot system. If you need locking
> on a root partition, then you'll need to set up an initrd from which
> to start all the necessary daemons...

This makes a lot of sense, I just had never thought about it properly.
I'm not sure I *need* locking, so I'll run with nolock till it bites me.

> BTW: Did I understand you and Neil correctly when you appeared to say
> that you were sharing the *same* root partition between several
> clients?

Yes, you did understand correctly. The same root partition is mounted by
around 20 machines. It works, too. The bug that we have manifests itself
very rarely, and only when one of the machines does an unclean shutdown.
I still haven't been able to reproduce it so I still haven't seen a
solution yet.

> If so, then that could easily explain your problem: a directory like
> /var/lib/nfs simply cannot be shared among several different
> machines. Read the 'statd' manpage, and I'm sure you will understand
> why.

Well, none of the machines by default exports anything through NFS, so
none of them explicitly *need* /var/lib/nfs. I've done some careful
study and separated the directories which are written to on a per-host
basis, and used a lot of tmpfs. It works quite well, to be honest. A
breakdown of "special" directories:

- /var/spool and /var/log need to be separate, for obvious reasons.
- /proc/mounts should be linked to /etc/mtab to avoid the need for
  writing there. 
- /tmp, /var/tmp, /dev/shm, /var/lock, /var/run, /var/lib/nfs,
  /var/yp/binding, /var/lib/sendmail are tmpfs.

None of the users have root access so writing to the partition only is
done as the result of servers running. I used a lot of reboots and ls
-lt to find out what needs to be separate, and there are few issues that
need fixing (/etc/ioctl.save being the latest).

One issue I ran into that I only discovered today (well, we all have to
learn someday) was that a shared /dev is not a good idea, because some
programs write to it. Case in point was syslogd, which creates /dev/log
- all but the last machine had logging broken. Since nobody needs logs
on these boxes anyway, it had gone on unnoticed, but I'm now using
devfs, and it works fine.

Everybody seems to find this setup a bit bizarre. It's not. It keeps
maintenence down to zero for everything, and adding a new box means
running a script once.

statd(8) does indicate that /var/lib/nfs is private, so I just mount it
as tmpfs. Should I make it persistent, or is the fact those files
disappear on an unclean reboot a sign of trouble?

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 22:38 UTC|newest]

Thread overview: 14+ 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
2003-01-26 21:49     ` [NFS] " Trond Myklebust
2003-01-26 22:47       ` Christian Reis [this message]
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

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=20030126204711.A25997@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 \
    --cc=trond.myklebust@fys.uio.no \
    /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