From: "Peter T. Breuer" <ptb@it.uc3m.es>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Mike Black <mblack@csihq.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: 2.4.8 NFS Problems
Date: Fri, 7 Sep 2001 14:05:10 +0200 (CEST) [thread overview]
Message-ID: <200109071206.OAA24577@nbd.it.uc3m.es> (raw)
In-Reply-To: <shsae07md9d.fsf@charged.uio.no> "from Trond Myklebust at Sep 7, 2001 01:49:50 pm"
"A month of sundays ago Trond Myklebust wrote:"
> >>>>> " " == Mike Black <mblack@csihq.com> writes:
>
> > I've been getting random NFS EIO errors for a few months but
> > now it's repeatable. Trying to copy a large file from one
> > 2.4.8 SMP box to another is consistently failing (at different
> > offsets each time). This doesn't appear to be a network
> > problem as the last comm between the machines looks OK. By the
> > timestamps it appears that a read() is taking too long and
> > causing a timeout?
>
> Morale: Don't use soft mounts: they are prone to these things. If you
> insist on using them, then try playing around with the `timeo' and
Unless you like having all your clients hang when the server happens to
be rebooted, and like having to go round hunting for them in dark
recesses in order to try and fool them into unmounting and remounting,
I'd recommend soft mounts every time!
> `retrans' mount variables.
It would be nice if nfs could do the a remount automatically when the
nfs handle it has goes stale an dit discovers it. Is that part of v3
nfs or not?
> Soft mount timeouts are not only due to network problems, but can
> equally well be due to internal congestion. The rate at which the
> network can transmit requests is usually (unless you are using
> Gigabit) way below the rate at which your machine can generate them.
But soft mounts at least break nicely and automatically. And since
failures are inevitable, I prefer them.
Come to think of it, why not have an option that does a hard,intr but
sends a ^C automatically to all referents when a stale handle is detected.
Peter
next prev parent reply other threads:[~2001-09-07 12:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-05 11:56 2.4.8 NFS Problems Mike Black
2001-09-07 11:49 ` Trond Myklebust
2001-09-07 12:05 ` Peter T. Breuer [this message]
2001-09-07 12:27 ` Trond Myklebust
2001-09-07 12:36 ` Trond Myklebust
2001-09-07 13:13 ` Mike Black
2001-09-07 14:42 ` Trond Myklebust
2001-09-07 15:46 ` Mike Black
2001-09-08 10:53 ` Trond Myklebust
2001-09-08 11:53 ` Mike Black
-- strict thread matches above, loose matches on Subject: below --
2001-12-20 9:44 Steffen Persvold
2001-12-20 11:10 ` Trond Myklebust
2001-12-20 14:40 ` Steffen Persvold
2001-12-20 20:27 ` Trond Myklebust
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=200109071206.OAA24577@nbd.it.uc3m.es \
--to=ptb@it.uc3m.es \
--cc=linux-kernel@vger.kernel.org \
--cc=mblack@csihq.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.