From owner-freebsd-hackers Tue Mar 3 12:24:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA25814 for freebsd-hackers-outgoing; Tue, 3 Mar 1998 12:24:43 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero-fxp0.Simon-Shapiro.ORG [206.190.148.34]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA25708 for ; Tue, 3 Mar 1998 12:24:16 -0800 (PST) (envelope-from shimon@sendero-fxp0.simon-shapiro.org) Received: (qmail 15945 invoked by uid 1000); 3 Mar 1998 20:31:22 -0000 Message-ID: X-Mailer: XFMail 1.3-alpha-021598 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <87pvk3sj07.fsf@phaedrus.uchicago.edu> Date: Tue, 03 Mar 1998 12:31:22 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: stephen farrell Subject: RE: hook database into filesystem like BeOS? Cc: freebsd hackers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 03-Mar-98 stephen farrell wrote: ... > so my question is: 1. anyone thinking about this? 2. how difficult do > you think it would be to get started playing with this--adding hooks > to the vfs layer to maintain the state in a rdbms (mysql, postgres, > etc)? 3. do you think it might be possible that such a system could > be, in principal, integrated with the c library so that applications > (e.g., find, file managers) would use it while calling the existing > api (analagous to nis vs. passwd file... perhaps a /etc config file > telling it whether it should use database, if so what kind, if so > which hostname is the database on, etc)? Yes, I am. Although nice and highly optimized for their own declared purpose (video streams, if I remember), this structure is not fit for most RDBMS storage managers. Database engines tend to view the disk as an array of blocks and no more. In Postgres, for example (I would have commented on Oracle OSD but cannot), you simply cannot do anything to the disk other than read a block, and write a block. (Well, there are few others). Locking cannot and should not be associated with disk blocks, as in an RDBMS you want to be able to lock abstract objects that may map to vlocks, may not map to blocks, map to multiple blocks, etc. If you examine the lock manager in Postgres, you will see what I mean. Locking ``one'' object can translate to several hundred lock operations. Ugly indeed. Since you opened this can of worms, I'll add that there is a loose group of us which contemplates the merging of RDBMS storage management and a Unix O/S. This is an interesting subject, and FreeBSD is actually a good O/S for this type of work. ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message