Date: Wed, 25 Aug 1999 00:13:22 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dg@root.com Cc: tlambert@primenet.com, mikel@zso.dec.com, freebsd-alpha@FreeBSD.ORG Subject: Re: Clustering? Message-ID: <199908250013.RAA09335@usr09.primenet.com> In-Reply-To: <199908242008.NAA15663@implode.root.com> from "David Greenman" at Aug 24, 99 01:08:01 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908250013.RAA09335>