Date: Tue, 16 Sep 1997 23:51:21 -0700 (PDT) From: Simon Shapiro <Shimon@i-Connect.Net> To: jbryant@tfs.net Cc: freebsd-hackers@freebsd.org Subject: Re: Distributed Lock Manager on FreeBSD Message-ID: <XFMail.970916235121.Shimon@i-Connect.Net> In-Reply-To: <199709170613.BAA00466@argus.tfs.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Jim Bryant; On 17-Sep-97 you wrote: ... > > + What is it good for? We are using it to build our non-stop RDBMS > > server, > > which is composed of a group of FreeBSD machines tied to a single > > disk > > farm. The RDBMS is PgSQL with the lock manager replaced with the DLM > > and > > the storage manager replaced with the DBFS/DIO module I am still > > working > > on. > > More info please... Briefly (so I do not make too many mistakes :-) Postgress supports the notion of a modular storage manager. In RDBMS, sstorage manager is (more or less) akin to a filesystem. The modular storage manager is similar, in concept to a filesystem switch; It allows the RDBMS to use a consistent interface to varying methods of storage. The default Postgres uses the Unix filesystem to store the data; one file per table, one file per index, etc. It also supports a memory SM where the shared memory is used to ``store'' the relations (tables and indices). A less known storage manager is the Mariposa project which proposed to distribute the storage across a wide area network. Still another one I got a whiff of was the one that used the large SGI tri-level jukeboxes. Somewhat similar to the boces used in the original Plan9 fileserver. The DBFS works backwards from those; It stores the data in a shared disk array; Several database managers, in several computers share a single ``disk''. The advantages are obvious in non-stop applications and in places where the computational (or other, non-disk I/O) load exceeds the disk bandwidth. While at it, the DBFS extends the I/O model in several ways: * A ``filesystem'' can be composed of a large number of diverse ``resources''. Each resource can be local, remote, or shared. * When creating a ``file'' you can specify the resource you want the ``file'' to occupy, the backup strategy, etc. * All READ/WRITE operations are unbuffered, raw operations, unless you specify buffered I/O. * File sizes are static, and all files are contigious on the ``disk''. To utilize these features (and a host of others), we need to extend the semantics of the SQL CREATE in Postgres. Those of you familiar with Oracle will understand what I say here. Actually, most non-Unix mainfreamers know very well what.why. The first implementation of DBFS will be strictly an SM. I simply do not know how to map these features into the Unix model. The DIO module will allow a DBFS SM to apear as a block device. This will allow you to newfs it with some STRANGE sideefects :-) > > If any of this is of any interest to any of you, drop me a line. > > Please > > try to do so soon , so I can decide how to document the thing. > > documentation is one of the things i've been doing lately... I will need to have a man page (long and winding) written for the DPT driver, the DLM driver, the dlmctl utility, the dlmd daemon, etc. While I used to be able to type troff directly, and man was the ``easy part'', I can no longer claim that. If you are willing to take upon yourself to translate a draft to English and then format into a manpage, I will be very, very grateful. --- Sincerely Yours, (Sent on 16-Sep-97, 23:21:39 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970916235121.Shimon>