Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!pacbell.com!decwrl!ucbvax!agate!darkstar!nexus.yorku.ca
From: davecb@nexus.yorku.ca (David Collier-Brown)
Newsgroups: comp.os.research
Subject: Re: Extremely Fast Filesystems
Message-ID: <5584@darkstar.ucsc.edu>
Date: 31 Jul 90 12:41:07 GMT
Sender: usenet@darkstar.ucsc.edu
Organization: York U. Computing Services
Lines: 54
Approved: comp-os-research@jupiter.ucsc.edu


In <5465@darkstar.ucsc.edu> Craig Partridge writes:
|  I'm curious.  Has anyone done research on building extremely
|  fast file systems, capable of delivering 1 gigabit or more of data
|  per second from disk into main memory?  I've heard rumors, but no
|  concrete citations.

puder@zeno.informatik.uni-kl.de (Arno Puder) writes:
| Tanenbaum (ast@cs.vu.nl) has developed a distributed system called
| AMOEBA. Along with the OS-kernel there is a "bullet file server".
| (BULLET because it is supposed to be pretty fast).
| 
| Tanenbaum's philosophy is that memory is getting cheaper and cheaper,
| so why not load the complete file into memory? This makes the server
| extremely efficient. Operations like OPEN or CLOSE on files are no
| longer needed (i.e. the complete file is loaded for each update).

  Er, sorta...  You could easily write an interface that did writes
or reads without open or closes, for some specific subset of uses.

| 
| The benchmarks are quite impressive although I doubt that this
| concept is useful (especially when thinking about transaction
| systems in databases).

  Well, I have something of the opposite view: a system like Bullet makes a
very good substrate for a database system.  

  The applicable evidence is in the article "Performance of an OLTP
Application on Symmetry Multiprocessor System", in the 17th Annual
International Symposium on Computer Architecture, ACM SigArch Vil 18 Number
2, June 1990. (see, a reference (:-))
  The article uses all-in-memory databases in the TP1 benchmark as a
limiting case while investigating the OS and architectural support that
are necessary for good Transaction Processing speeds, and the speeds
are up in the range that Craig may find interesting...

  My speculation is that a bullet-like file system with a relation-
allocating layer (call it the Uzi filesystem? the speedloader filesystem??)
on top would make a very good platform for a relational database.  Certainly
the behavior patterns of an in-memory, load-whole-relation database would be
easy to reason about, and would be easy and interesting to investigate.

| You can download Tanenbaum's original paper (along with a "complete"
| description about AMOEBA) via anonymous ftp from midgard.ucsc.edu
| in ftp/pub/amoeba.


--dave
-- 
David Collier-Brown,  | davecb@Nexus.YorkU.CA, ...!yunexus!davecb or
72 Abitibi Ave.,      | {toronto area...}lethe!dave 
Willowdale, Ontario,  | "And the next 8 man-months came up like
CANADA. 416-223-8968  |   thunder across the bay" --david kipling