From owner-freebsd-current  Sat Dec  4 17:29:58 1999
Delivered-To: freebsd-current@freebsd.org
Received: from flamingo.McKusick.COM (flamingo.mckusick.com [209.31.233.178])
	by hub.freebsd.org (Postfix) with ESMTP
	id 0C82A15366; Sat,  4 Dec 1999 17:29:51 -0800 (PST)
	(envelope-from mckusick@flamingo.McKusick.COM)
Received: from flamingo.McKusick.COM (mckusick@localhost [127.0.0.1])
	by flamingo.McKusick.COM (8.9.3/8.9.0) with ESMTP id PAA05208;
	Sat, 4 Dec 1999 15:02:18 -0800 (PST)
Message-Id: <199912042302.PAA05208@flamingo.McKusick.COM>
To: George Michaelson <ggm@dstc.edu.au>
Subject: Re: Mounting one FS on more than one system 
Cc: Mike Smith <msmith@freebsd.org>, match@elen.utah.edu,
	current@freebsd.org
In-reply-to: Your message of "Sun, 05 Dec 1999 09:44:32 +1000."
             <1082.944351072@dstc.edu.au> 
Date: Sat, 04 Dec 1999 15:02:18 -0800
From: Kirk McKusick <mckusick@flamingo.McKusick.COM>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

	To: Kirk McKusick <mckusick@flamingo.McKusick.COM>
	cc: Mike Smith <msmith@FreeBSD.ORG>, match@elen.utah.edu,
	    current@FreeBSD.ORG
	Subject: Re: Mounting one FS on more than one system 
	In-reply-to: Your message of "Sat, 04 Dec 1999 12:44:43 PST."
		     <199912042044.MAA05073@flamingo.McKusick.COM> 
	Date: Sun, 05 Dec 1999 09:44:32 +1000
	From: George Michaelson <ggm@dstc.edu.au>

Let me start by saying that I do not have the definitive answers
to all your questions. I'll take a crack at some of them.

	Allowing for cache writeback delays, is the speed of
	direct-to-shared-disk fast enough that using NFS as an
	"abstraction" layer would be faster than any network extant?

The gains come from being able to read data directly from the
disk rather than transferring it across the network. However,
the cost of maintaining cache coherency would be at least as
difficult and bandwidth consuming as a distributed filesystem.

	Would it be as fast? would the effort to make this work
	exceed the cost of making real networks exist?

As the network speed approaches the disk speed, the gains
would diminish.

	It would seem that there might be opportunities to do 'cut
	through' in the coding for known-private files after open
	(ok, inode allocation/extension has problems) to optimize
	them to at-worst 'disk+bits' instead of NFS costs.

The problem is in identifying when private goes to shared. Also
as you point out, new block and inode allocations have to be
centrally coordinated.

	If one party mounts -r the FS (eg news spool) then does
	this reduce the complexity? eg /usr mounted read-mostly
	for a bunch of tightly coupled boxes.

If any machine can write, then all the other machines have to
have some way of keeping their caches consistent with the
machine that did the modification.

	If some other protocol is used for interlock, does this
	make mmap shares across clusters faster?

Mmap sharing across machines is going to be slow. I have never
been a fan of distributed shared memory as a programming model,
and this does not look like a way of making it run any faster.

	-George

	--
	George Michaelson         |  DSTC Pty Ltd
	Email: ggm@dstc.edu.au    |  University of Qld 4072
	Phone: +61 7 3365 4310    |  Australia
	  Fax: +61 7 3365 4311    |  http://www.dstc.edu.au


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message