From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Janne Karhunen <Janne.Karhunen@gmail.com>
Cc: MrUmunhum@popdial.com, linux-kernel@vger.kernel.org
Subject: Re: Mounting NFS root FS
Date: Mon, 04 Dec 2006 13:21:30 -0500 [thread overview]
Message-ID: <1165256490.711.233.camel@lade.trondhjem.org> (raw)
In-Reply-To: <200612041912.30527.Janne.Karhunen@gmail.com>
On Mon, 2006-12-04 at 19:12 +0200, Janne Karhunen wrote:
> > 2) NFS provides persistent storage.
>
> To me this sounds like a chicken and an egg problem. It
> both depends and provides this at the same time :/. But
> hey, if it's supposed to work then OK.
??? Locking depends on persistent storage, but persistent storage never
depended on locking. Neither rpc.statd nor lockd, nor the nfs client
depend on locking working a priori.
> Anyhoo, I tried this at some stage and failed as random
> clients seemed to occasionally get stuck in insmod¹ at
> boot (infinite wait on lock that never gets released).
> At that stage guess was that server could not properly
> recognize client reboot given stale client lock data.
> But if it's supposed to work I guess I have to give it
> another shot and do better analysis on it.
>
> What about NLM/NSM protocol issues - do they properly
> deal with packet loss and clients that stay down (client
> holding a lock crashing and staying down; will the lock
> ever be released)?
1) Packet loss is dealt with by retrying ad-infinitum.
2) No. The problem of client crashes was fixed in NFSv4 with the
addition of lease-based locks.
> ¹ And why does insmod require a lock on module at load??
Does it? I've no idea why it should need that.
Trond
next prev parent reply other threads:[~2006-12-04 18:21 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-02 19:03 William Estrada
2006-12-02 19:07 ` Jan Engelhardt
2006-12-02 21:15 ` Willy Tarreau
2006-12-02 21:56 ` Jan Engelhardt
2006-12-02 22:55 ` Willy Tarreau
2006-12-03 2:37 ` Trond Myklebust
2006-12-03 6:02 ` Willy Tarreau
2006-12-03 7:05 ` Trond Myklebust
2006-12-03 8:30 ` Willy Tarreau
2006-12-03 11:04 ` Jan Engelhardt
2006-12-03 16:59 ` Trond Myklebust
2006-12-04 11:51 ` Janne Karhunen
2006-12-04 15:29 ` Trond Myklebust
2006-12-04 17:12 ` Janne Karhunen
2006-12-04 18:21 ` Trond Myklebust [this message]
2006-12-04 20:05 ` Janne Karhunen
2006-12-04 21:27 ` Trond Myklebust
2006-12-05 0:20 ` H. Peter Anvin
2006-12-04 20:03 ` Jan Engelhardt
2006-12-04 20:27 ` Janne Karhunen
2006-12-04 20:47 ` Trond Myklebust
2006-12-05 18:43 ` Jan Engelhardt
2006-12-05 19:37 ` Trond Myklebust
2006-12-05 19:59 ` Jan Engelhardt
2006-12-05 20:12 ` Trond Myklebust
2007-01-27 14:47 ` Jan Engelhardt
2006-12-07 22:27 ` Hans-Peter Jansen
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=1165256490.711.233.camel@lade.trondhjem.org \
--to=trond.myklebust@fys.uio.no \
--cc=Janne.Karhunen@gmail.com \
--cc=MrUmunhum@popdial.com \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®