From owner-freebsd-hackers Wed Mar 4 11:43:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA08269 for freebsd-hackers-outgoing; Wed, 4 Mar 1998 11:43:02 -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 LAA08246 for ; Wed, 4 Mar 1998 11:42:45 -0800 (PST) (envelope-from shimon@sendero-fxp0.simon-shapiro.org) Received: (qmail 9281 invoked by uid 1000); 4 Mar 1998 19:49:35 -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: Date: Wed, 04 Mar 1998 11:49:35 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: sbabkin@dcn.att.com Subject: RE: SCSI Bus redundancy... Cc: wilko@yedi.iaf.nl, tlambert@primenet.com, jdn@acp.qiv.com, blkirk@float.eli.net, hackers@FreeBSD.ORG, grog@lemis.com, karl@mcs.net Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 04-Mar-98 sbabkin@dcn.att.com wrote: ... > Databases are not regular filesystems. They have little number of > big files. Wrong. First, databases can have many small tables (let's stick with RDBMS for simplicity). What you refer to is what you can see from the utside. Inside these few big files, is a complex organization that takes closely related blocks of data and names them. This is what a filesystem is. So, inside the big files, which reside in a Unix filesystem, there is another filesystem. It is called a ``storage manager'' or something like that, but it is a filesystem. Second, A Unix filesystem is nothing more than a heirarchial database, with a single key index, variable length records, with one record per table. Then, at the application level, you assign meanings to the contents of that record by breaking it into sub records. For example, most Unix utilities will read this one record sequentially, and everytine they see a '\n', they will declare it an end-of-record. ... > Save it to tape as an image of logical disk. Restore it in the same > way. With things like OnlineJFS you can even do save it online. I have this new, imaginary Super-DAT tape that does 1 gigabyte/Sec. Itis attached to a Super-Duper-Ultra-SCSI thatt= has 1GB/Sec throughtput, and a small, 100GB database. The application is sinmple, for every telephone call the switch wants to make, we need to find the customer's telephone number, his long-distance company code, is his account valid, etc. then we add a CDR (Call Detail Record) that said that Simon called George on such-and-such date and talked for so many minutes. This is a highly, overly simplified application. Now, these database inquiries come at the rate of only 200/Sec. For simplicity sake, each CDR is exactly one half of a sector on the disk (forget databases. We are in the raw here :-). The database never shuts down, as you hate it when there is no dialtone when you pick up the phone. Now go and backup this database: a. You cannot shut it down, because the PUC said so and you hate prisons. b. By the time you back it up (100 seconds, there have been 20,000 modifications to the database. c. If you do a hot backup of the files, you will have approximately 10,000 changes that are not in your backup. d. If this was on a Unix filesystem, your files are now corrupt. Totall. you tell me why. This is a simplistic examples. Life is nastier than that. Can it be solved? Of course. With Unix? Yes, what do you think a 5ESS switch runs? With FreeBSD? Yes. As is today? No.... ---------- 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