From owner-freebsd-alpha Tue Aug 24 17:14:44 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 9CCE7152BC for ; Tue, 24 Aug 1999 17:14:41 -0700 (PDT) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id RAA02027; Tue, 24 Aug 1999 17:13:37 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp01.primenet.com, id smtpd001967; Tue Aug 24 17:13:28 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id RAA09335; Tue, 24 Aug 1999 17:13:22 -0700 (MST) From: Terry Lambert Message-Id: <199908250013.RAA09335@usr09.primenet.com> Subject: Re: Clustering? To: dg@root.com Date: Wed, 25 Aug 1999 00:13:22 +0000 (GMT) Cc: tlambert@primenet.com, mikel@zso.dec.com, freebsd-alpha@FreeBSD.ORG In-Reply-To: <199908242008.NAA15663@implode.root.com> from "David Greenman" at Aug 24, 99 01:08:01 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >> FreeBSD doesn't support shared filesystems. You would need to add support > >> for that into FFS and presumably get or implement a distributed lock manager. > > > >The David Sarnoff stuff supports this. It would not be too > >difficult to hack up the disctubted memory coherency manager > >to use low level SCSI I/O primitives to support this. > > I thought the Sarnoff stuff was a DSM implementation. If so, then it's not > what we're talking about (shared access to filesystems). That's just the MNFS stuff. The Sarnoff code implements a number of things, including a fully distributed lock manager. While not ideal, you could implement shared disk access by adding a shim into the disk access code, using the shared lock manager as a basis for gating requests through the shim. You could lock on a cluster access basis. You could also implement "soft read-only", which would give you the equivalent of a volume lock, where the FS was known to be in a good state (e.g. "virtually clean") before the lock was passed. This isn't nearly as efficient as cluster-level granularity, but it's passable, depending on how much reading vs. writing is going on. Normally, if you are implementing something like a web farm, you are doing mostly reading, and infrequent writing. Kirk and Julian both ran their soft updates test bed with a shared SCSI drive, with manual gating (an implementation detail) of read-only vs. read-write access. If he's going to buy the hardware, then it has to be with the caveat that he will have to hack code to implement this reasonably; soft updates, for example, would need synchronization points added to achieve lock handoff, without something like "soft read-only". As you pointed out in your original post, though, he's probably going to have to at _least_ hack code for his controller, anyway, so if he's in a "hacking mood", it might be reasonable for him to hack the other stuff as well (assuming he was deep in the "wolfpack" developement, this shouldn't be too hard for him to do, I think). XFS deals with all this crap by gating access to the Journal, and gating access to region allocation through a promiscuous mechanism not specific to the disks. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message