Date: Mon, 28 Apr 1997 21:21:55 -0700 (PDT) From: Simon Shapiro <Shimon@i-Connect.Net> To: freebsd-hackers@freebsd.org Subject: New Features - invitation to comment Message-ID: <XFMail.970428222317.Shimon@i-Connect.Net>
next in thread | raw e-mail | index | archive | help
Hi Y'all, We are developing a new feature set for FreeBSD. We would like to have as many of this new functionality adopted as standard features of FreeBSD. The complete feature set will be able to: A. Distribute disk blocks across multiple hosts. The first item, to be called, in this (hopeful) discussion ``DDIO'' works as follows: * Disk blocks receive an arbitrarly address, which is composed of a host identifier and a block Id on the host. * A request for any block can be sent to any participating host. * Block access is mutually exclusive. Provisions will be made for shared access. * A Distributed Lock Manager coordinates access and ``ownership'' of participating blocks. * Although blocks are ``owned'' by a particular host, they can be leased to any participating host. * Access to distributed blocks is quick. * Reasonable security is provided, to protect the system from intrusion and terrorism. A bit of imagination can lead you to quickly see the potential for this technology. What my employer intends to do with this technology is not going to be available until the appliation is patented or otherwise protected. the core technology described here is going to be made public. To provide for this technology, several pieces of code will be necessary. 1. The DLM itself. 2. The DDIO server. We have completed the DDIO server as a user process, and can do, platform depending, about 50-400 disk I/O operations per second. We would like to hear some ideas about what YOU think it should do and how (if?) it should be implemented in the Kernel. The DLM has been designed. We are looking for two things: 1. Ideas which will [in]validate our design. 2. Interested people to work on it. There is a kernel part to the DLM and there is a user part. The kernel part implements the low level, hardware dependant and real-time detection (dead-man switch and packets exchange). The user part handles the resources database. B. Provide non-stop access to common disk farms from multiple instances. Building on the above and adding to it, we will allow shared access to system resources. The first (and most obvious) target will be disk farms which will give us what is known as ``disk clusters''; A disk subsystem which is sharable among several Unix instances. Again, there is a kernel component and a user component to this; In addition to the DLM coordination, and wide area distribution afforded by the DDIO, there is a SCSI component, which I think I am going to ask Justin to lead/manage. Right? The rest of this functionality is a deriviative of the DDIO and DLM. An exciting possibility for utilizing this technology, in a genral manner, is the creation of distributed file systems, which do not share some of the ``exciting features'' of NFS. C. Virtual IP Clustering Those of you familiar with the ISIS project (Georgia Tech?), will know, by reference, what I am after, only much simpler. Consider the following: Few systems, hooked up to a (SCSI) disk farm, are sharing access to the disk. They are made to appear as if they are a single IP address, or a single hostname (Named can actually ``flip-flop'' between several hosts in response to gethostbyname()). As long as all is well, the participants share the load by responding, in some allocation fasion (round robin, or whatever) to individual requests. Were one of them to fail/disappear/die, the other(s) will continue to serve. Again, we have our own ideas HOW to go about it and what IT may be. I am soliciting ideas, levels of interest, how to participate, etc. Compensation: I have a team of 3 good engineers working on this project. I am in the process of adding two more. I have the authority to hire contractors for the duration of the project (at least). We can develop a plan by which participants get compensated individually, the FreeBSD organization receives payment in money or services, or whatever we can agree upon. At the minimum, we can all participate in the design. Background: I feel very hesitantly about this, but feel that we can save a lot of time if we introduce ourselves. I have a pretty good idea about the core team competence by observing and somewhat participating in the FreeBSD mailing lists. I really do not know much more except for being greatly impressed. As I am not a follower of conventions, media or other ``publishing'' circuits, I really know nothing about the core team in person. Keep me in the dark, if that is what you want :-) As I am the newcomer, let me introduce my employer and myself. I work for a medium size conputer company (which really likes, at this point, to stay under cover, I know not why) which specializes in telephony applications. We have several lines of business and are doing rather well. I was hired about 9 months ago to design and see to the implementation of a whole new generation of technology and applications. The purpose can be guessed from what we want to do. Before that I worked for 3-4 years on very large database systems. I have done Unix kernel internals (mainly for the ``Other Unix'' - SV :-) and specialized in large scale I/O subsystems (my employer for 6.5 years was/is a major DBMS vendor). Before that I designed some strange distributed applications, robotics, large scale financial systems and manufacturing systems (process monitoring, tracking systems). Early on (1970's), a group of us built a Unix-like Z-80 based muti-processor system. I really am a bashful, shy person andreally eager to NOT barge-in, not offend and really cooperate. I have tried my hands at the Linux circuit for a while but got burned by the (frankly) imaaturity and the excessive argumentativeness i found there. I switched my attention to FreeBSD, on a recommendation and a whim, and belive we can all mutually benefit. I talked to David, who recommended I approach you (collectively). Tell me what you think. Simon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970428222317.Shimon>