Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!ucsd!ucbvax!pasteur!eden.Berkeley.EDU!mao
From: mao@eden.Berkeley.EDU (Mike Olson)
Newsgroups: comp.databases
Subject: Re: Ingres and NFS
Message-ID: <29392@pasteur.Berkeley.EDU>
Date: 31 Oct 90 01:03:56 GMT
References: <4691@spdcc.SPDCC.COM> <1990Oct30.151205.5406@oracle.com>
Sender: news@pasteur.Berkeley.EDU
Reply-To: mao@postgres.Berkeley.EDU.UUCP (Mike Olson)
Followup-To: comp.databases
Organization: University of California, Berkeley
Lines: 34

In <1990Oct30.151205.5406@oracle.com>, kbittner@oracle.uucp (Kurt Bittner)
writes:

> In article <4691@spdcc.SPDCC.COM> dyer@ursa-major.spdcc.com (Steve Dyer)
> writes:
> :
> :I've heard that Ingres rel 6 "doesn't work" on NFS.  ...
> 
> I'm certainly not an expert on Ingres, but there is a general problem
> with NFS that affects all DBMS's running under it:  NFS is stateless.
> This means that in the event of a system or network crash, NFS doesn't
> know enough information about what was going on at the time of the crash
> to do anything like a transaction recovery or rollback.  As a result,
> a database running on NFS would have a high likelihood of corruption
> in the event of a crash. 

i don't understand your problem statement.  the statelessness of NFS
doesn't propogate upwards.  that is, the DBMS is responsible for recovery
and rollback, not the file system, and the DBMS is certainly capable of
recording sufficient state to do either.  network latency makes log
writes expensive, but that isn't a priori a barrier to using a network
file system.

what DBMS implementors *really* want to do is rip the unix file system
abstraction out altogether and replace it with a system that does ordered
writes in accordance with some program-specified dependency graph.  since
that's not possible, they wind up doing gymnastics to guarantee atomicity
of transactions.  those gymnastics in principle should have the same effect
whether the disk is local or remote.

					mike olson
					postgres research group
					uc berkeley
					mao@postgres.berkeley.edu