From owner-freebsd-hackers Tue Sep 16 19:35:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA06549 for hackers-outgoing; Tue, 16 Sep 1997 19:35:56 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA06544 for ; Tue, 16 Sep 1997 19:35:53 -0700 (PDT) Received: (qmail 1264 invoked by uid 1000); 17 Sep 1997 02:36:16 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Date: Tue, 16 Sep 1997 19:36:15 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: FreeBSD-Hackers@FreeBSD.org Subject: Distributed Lock Manager on FreeBSD Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk We are putting the finishing touches on a true general purpose distributed lock manager for FreeBSD. This message is a solicitation for interest. If I receive enough interest in it I will start a chain of discussions on the subject and solicit core review for inclusion in FreeBSD. This may not be easy as some of my management would like to keep it proprietary. To illustrate, an Oracle equivalent (subset, really) had a cost of over $250,000 for the source and about 1/5 for binary. VERY BRIEF SUMMARY: DLM is a method by which cooperating processes on different machines (even different operating systems) can inform each other of interest in a named object. Just like a database lock manager, or a file system lock manager, but with the ability to span hosts in real time. Some highlight of this DLM: * Kernel implementation; All the locking logic is in the O/S kernel, not in userspace. * Multi-state, hirerchial lock with up to 32 states per lock. * Conflict resolution built in; Caller can specify which states to consider in conflict analysis. * Conflict Blocking; Caller can specify which conflict to block on. * Programmable conflict block; Allows caller to specify how long to wait. * Multiple-locking. Individual states can accumulate; A locker can specify that multiple ``read'' locks are permitted. the DLM will track how many are actually applied. * Remote Locking; A call to the local DLM agent for locking a remote resource is automatically proxied. * Shared Locking; If a resource is shared, the DLM will apply both local and remote lock and automatically/instantly resolve deadlocks. * Multi-path; Each resource can have its own data path (TCP/IP, SCSI, RCS-232, etc.) UDP support is running, SCSI support via DPT is forthcoming. * External resource management; The mapping of resources is external to the locking agent. * Distributed; There is no central locking authority, although you can easily create one via resource configuration. + 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. 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. --- Sincerely Yours, (Sent on 16-Sep-97, 19:18:09 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