From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3cd3b8571c28b75f X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-09-03 10:13:02 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!small1.nntp.aus1.giganews.com!border1.nntp.aus1.giganews.com!nntp.giganews.com!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: A Customer's Request For Open Source Software References: <3F44BC65.4020203@noplace.com><20030822005323.2ff66948.david@realityrift.com> <3F4828D9.8050700@attbi.com> <3F4EA616.30607@attbi.com> <3F512BD1.8010402@attbi.com> <3F52AA5F.8080607@attbi.com> <3F5559A4.8030507@attbi.com> In-Reply-To: <3F5559A4.8030507@attbi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <34p5b.8361$Kj.843491@news20.bellglobal.com> Date: Wed, 03 Sep 2003 12:57:48 -0400 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1062608255 198.96.223.163 (Wed, 03 Sep 2003 12:57:35 EDT) NNTP-Posting-Date: Wed, 03 Sep 2003 12:57:35 EDT Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:42106 Date: 2003-09-03T12:57:48-04:00 List-Id: Robert I. Eachus wrote: > Larry Kilgallen wrote: > >> In article <3F53B88E.7040405@attbi.com>, "Robert I. Eachus" >> writes: >>> As I said, most RDBMSs already have the ability to bypass the OS and >>> access disk drives directly. > >> They do ? On what operating systems ? > > I guess we have a different idea of what bypassing the OS means. I was > thinking of for example, Oracle on Solaris. You can go through the file > system, bypass the file system and have Oracle manage a partition (raw > mode), or give Oracle full control of the DISK device or devices. But > even then you are right, the DBMS uses the standard device drivers. The > difference is that if Oracle controls the entire disk, it can take > control of the head positioning and other driver level functions. INFORMIX and Sybase can work with the raw devices as well. This was in fact, a problem in early Linux kernels, as they did not support raw devices (only "block" devices where the disk blocks are cached -- database engines prefer to do their own caching techniques). Linus didn't understand the need for these raw (unbuffered) devices in the beginning. I think Oracle was probably the source of enlightening on that front. ;-) So on the early Linux kernels, only file system based versions of INFORMIX and Sybase databases were possible. Now I would expect that has all changed. You might wonder why buffered "block" devices are not good enough for the purpose. I can't answer to the specifics, but only that database engines are in a position to better manage the cache based upon what they "know" needs to be done. Another important reason to control caching details is that when a transaction is committed, you need to guarantee that the data is written to the disk media (or can be recovered if the database is to be restarted at that point). The database must be recoverable at any given point anyhow, and this usually requires fine grained control over physical writes to the media. This aspect and performance means that the engine must balance performance with reliability (persistance), which are conflicting goals when using disk. It is this last area where oodles of persistent fast memory (instead of disk), can make a world of difference. In this case persistence = memory performance, which of course is where the win is. If disks became obsolete (one can hope), then I could see that new database engine design (internals) will become much different than what it is today. Certainly, many of the present compromises would be eliminated. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg