From: Jakob Østergaard <jakob@unthought.net>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Stale NFS handles on 2.4.1
Date: Wed, 14 Feb 2001 00:43:55 +0100 [thread overview]
Message-ID: <20010214004355.C11906@unthought.net> (raw)
In-Reply-To: <20010214002750.B11906@unthought.net> <E14SovJ-0003H1-00@the-village.bc.nu>
In-Reply-To: <E14SovJ-0003H1-00@the-village.bc.nu>; from alan@lxorguk.ukuu.org.uk on Tue, Feb 13, 2001 at 11:31:50PM +0000
On Tue, Feb 13, 2001 at 11:31:50PM +0000, Alan Cox wrote:
> > The NFS clients are getting
> > "Stale NFS handle"
> > messages every once in a while which will make a "touch somefile.o"
> > fail.
>
> If they have the previous .o handle cached and it was removed on another
> client thats quite reasonable behaviour. NFS isnt coherent
So a solution would be to
<local node> rm -f output.o
<remote node> g++ .... -o output.o
<local node> touch output.o
I do the touch in the first place because a subsequent link job on
another remote node used to fail if I didn't. NFS caching magic I guess...
>
> > It's quite annoying and I didn't see it on 2.2 even after the NFS
> > patches were integrated.
>
> I wonder if its because 2.4 runs faster and caches better 8). You can
> tune the attribute cache times that may help. Are we talking 30 second
> intervals here or stuff being cached for far too long (which would imply a bug)
It runs faster indeed, and it makes the work more fun and makes the
internet go faster ! (uhhh... or maybe the internet speedup is because
of the Intel CPUs - I forgot...)
Usually how a compile goes is:
a make -j10 spawns concurrent compile jobs. Each job consists of
"spawn on remote node" g++ ... -o somefile.o
"on local node" touch somefile.o
After a truckload of .o files have been generated, it will start
up link jobs, on other remote nodes. I haven't tried this without
the touch trick for a long time.
Each g++ job takes from a few seconds to several minutes depending
on the file and optimization options etc. I think I mainly see this
with the fast jobs... Most .o files are ~1-4 MB and I have about 200
of them.
~200 compilers and ~12 linkers take about 4-5 minutes to complete on
the cluster of three dual machines and two-three single cpus. Producing
about 1.5G of object code in total (yes C++ symbols are HUGE).
So, the touch is _immediately_ after a compile completion. But the
.o file has not been in use on any other machine than the one running
the compiler for hours or at least many minutes (a different compile).
I'll try this without the touch trick and see how things fare...
--
................................................................
: jakob@unthought.net : And I see the elder races, :
:.........................: putrid forms of man :
: Jakob Østergaard : See him rise and claim the earth, :
: OZ9ABN : his downfall is at hand. :
:.........................:............{Konkhra}...............:
next prev parent reply other threads:[~2001-02-13 23:44 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-13 23:27 Stale NFS handles on 2.4.1 Jakob Østergaard
2001-02-13 23:31 ` Alan Cox
2001-02-13 23:43 ` Jakob Østergaard [this message]
2001-02-14 8:35 ` Rogier Wolff
2001-02-14 0:02 ` Trond Myklebust
2001-02-24 20:18 ` Stale NFS handles on 2.4.2 David Fries
2001-02-25 5:43 ` Neil Brown
2001-02-25 5:53 ` David Fries
2001-02-25 9:25 ` Neil Brown
2001-02-25 19:10 ` David Fries
2001-02-28 0:12 ` Neil Brown
2001-02-28 12:02 ` Trond Myklebust
2001-02-28 22:15 ` Neil Brown
2001-03-01 1:13 ` Trond Myklebust
[not found] ` <20010228211808.C24668@d-131-151-189-65.dynamic.umr.edu>
2001-03-01 9:07 ` Trond Myklebust
[not found] ` <s5gwva9simp.fsf@egghead.curl.com>
2001-03-01 14:13 ` Stale NFS handles on 2.4.2^H^H^H^H^H2.2.19 Trond Myklebust
2001-02-25 14:00 ` Stale NFS handles on 2.4.2 Trond Myklebust
2001-02-26 9:54 ` Lennert Buytenhek
2001-02-26 15:56 ` David Fries
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=20010214004355.C11906@unthought.net \
--to=jakob@unthought.net \
--cc=alan@lxorguk.ukuu.org.uk \
--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