Re: PATCH: NFS oops in 2.1.117

Alan Cox (alan@lxorguk.ukuu.org.uk)
Sat, 22 Aug 1998 00:44:27 +0100 (BST)


> Ok. Peace.

Ditto. There are times you drive me up the wall, maybe I should have taken
the job at transmeta so I got visual clues instead.

> The obvious breakage is that even though you disabled the IS_SOFT testing
> for pending signals, you didn't do the "current->state" thing right. Do
> you now wonder why I thought you were just completely out to lunch?

IS_SOFT() is a macro of 0 - that is it was disabled. The IS_SOFT was wrong
anyway - soft is times out, hard is doesnt time out, intr is interruptible

The current->state thing being what - the TASK_INTERRUPTIBLE/UNINTERRUPTIBLE ?

I left that for the moment. I didnt think that could cause signals to be
misdelivered. What worries me about backing it off (apart from the mount
problems and I can send you patches so there is clnt->no_signals field
for NFS to use if we cant sort this) is that if you are right I took
a blocked signal. Needless to say we shouldnt be taking blocked signals and
that may have other ramifications.

> In short, I may have over-reacted. Sorry. But I'm still going to revert
> that, because right now 2.1.117 looked _very_ good, and whatever you say

Ok. And yes 2.1.117 doesnt look too bad. I can crash it to order as a user
still but its not crashed too much without being ordered (myeb the known
AF_UNIX bugs [hopes]).

> about the current NFS, it is stable. It has one known (but yet
> unexplained) bug with regards to O_APPEND, and it has nasty behaviour when
> the NFS server doesn't reply, but it's certainly been stable for quite
> some time.

and the problem of losing writes, and the lockd Oopses. Losing writes on a disk
full and not reporting it is _very_ bad. That one lost pieces of my mailbox
and corrupted some patches. We can (and should) switch to synchronous writes
by default for 2.2. It would be nice to fix the caching problem (discard
cache on close) but thats not essential just bad - its what makes 2.0 faster
for some NFS benches.

Switching to sync by default is (fortunately) trivial.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html