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>