Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.UUCP
Newsgroups: comp.unix.questions
Subject: Re: shared crontab and ND caching
Message-ID: <12907@sun.uucp>
Date: Sun, 8-Feb-87 18:39:13 EST
Article-I.D.: sun.12907
Posted: Sun Feb  8 18:39:13 1987
Date-Received: Mon, 9-Feb-87 04:51:23 EST
References: <136@quacky.mips.UUCP> <201@devon.UUCP> <2409@mcc-pp.UUCP> <6437@allegra.UUCP> <632@mcgill-vision.UUCP>
Sender: news@sun.uucp
Reply-To: guy@sun.UUCP (Guy Harris)
Organization: Sun Microsystems, Mountain View
Lines: 20

>> shared crontab, I think the problem may be due to the caching in ND.

>Doesn't `sync' work?  There's a syscall sync() to flush the buffer
>cache, and there's a program /etc/sync which calls it.

Umm, err...  having a writable ND partition available to more than
one machine is an error.  Would you take a vanilla UNIX kernel, put
in a driver for a dual-ported disk, and have a file system writable
by one machine and accessible to another machine, and expect it to
work?  I thought not.  Think of an ND partition as residing on a
multi-ported disk; it was not intended to be used in this fashion,
and has no "cache invalidate" operation to enable an ND client to
invalidate other ND clients' caches, so in that sense you still have
a vanilla UNIX kernel.

If you do a "sync" on a machine that has the disk mounted read-only,
it does nothing for you.  If you do it on a machine that has it
mounted read-write, it will push any unwritten blocks to the disk but
will *NOT* invalidate any copies of those blocks in any other
machine's cache.