Ultralinux archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: ultralinux@vger.kernel.org
Subject: Re: strange sparc64 -> i586 intermittent but reproducible NFS write errors to one and only one fs
Date: Sun, 19 Jan 2003 21:00:14 +0000	[thread overview]
Message-ID: <marc-linux-ultrasparc-104301002809481@msgid-missing> (raw)
In-Reply-To: <marc-linux-ultrasparc-104300775807656@msgid-missing>

>>>>> " " = nix  <nix@esperi.demon.co.uk> writes:


     > Anyway, the problem appears in 2.4.20-pre10; I suspect

     > Trond Myklebust <trond.myklebust@fys.uio.no>:
     > o Workaround NFS hangs introduced in 2.4.20-pre

     > (so Cc:ed)

     > Does anyone have a pointer to this patch so I can try reversing
     > it from 2.4.20pre10? (I can't see it on l-k, but since I don't
     > know what it looks like it's hard to find it in the archives; I
     > don't have bitkeeper on this machine, and can't, as one of my
     > current projects involves version-control filesystems).

It sounds rather strange that this particular patch should introduce
an EIO, but here it is (fresh from BitKeeper)

Cheers,
  Trond

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.717.1.6 -> 1.717.1.7
#	   net/sunrpc/xprt.c	1.30    -> 1.31   
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/10/07	trond.myklebust@fys.uio.no	1.717.1.7
# [PATCH] Workaround NFS hangs introduced in 2.4.20-pre
# 
# Alan,
# 
# Does the following patch make any difference to the hangs?
# 
# It reverts one effect of my changes, and ensures that requests get resent
# immediately after the timeout, even if doing so would violate the current
# congestion window size.
# Doing this ensures that we keep probing the `connection' to the server
# rather than just waiting for the entire window to time out. The latter
# can be very expensive due to the exponential backoff rule...
# 
# Cheers,
#   Trond
# --------------------------------------------
#
diff -Nru a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c
--- a/net/sunrpc/xprt.c	Sun Jan 19 21:56:20 2003
+++ b/net/sunrpc/xprt.c	Sun Jan 19 21:56:20 2003
@@ -171,10 +171,10 @@
 
 	if (xprt->snd_task)
 		return;
-	if (!xprt->nocong && RPCXPRT_CONGESTED(xprt))
-		return;
 	task = rpc_wake_up_next(&xprt->resend);
 	if (!task) {
+		if (!xprt->nocong && RPCXPRT_CONGESTED(xprt))
+			return;
 		task = rpc_wake_up_next(&xprt->sending);
 		if (!task)
 			return;
@@ -1013,7 +1013,6 @@
 		}
 		rpc_inc_timeo(&task->tk_client->cl_rtt);
 		xprt_adjust_cwnd(req->rq_xprt, -ETIMEDOUT);
-		__xprt_put_cong(xprt, req);
 	}
 	req->rq_nresend++;
 
@@ -1150,10 +1149,7 @@
 		req->rq_bytes_sent = 0;
 	}
  out_release:
-	spin_lock_bh(&xprt->sock_lock);
-	__xprt_release_write(xprt, task);
-	__xprt_put_cong(xprt, req);
-	spin_unlock_bh(&xprt->sock_lock);
+	xprt_release_write(xprt, task);
 	return;
  out_receive:
 	dprintk("RPC: %4d xmit complete\n", task->tk_pid);

  reply	other threads:[~2003-01-19 21:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-19 20:21 strange sparc64 -> i586 intermittent but reproducible NFS write errors to one and only one fs Nix
2003-01-19 21:00 ` Trond Myklebust [this message]
2003-01-20  6:01 ` strange sparc64 -> i586 intermittent but reproducible NFS write David S. Miller
2003-01-20 20:53 ` strange sparc64 -> i586 intermittent but reproducible NFS write errors to one and only one fs Nix
2003-02-03 17:35 ` Nix

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=marc-linux-ultrasparc-104301002809481@msgid-missing \
    --to=trond.myklebust@fys.uio.no \
    --cc=ultralinux@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