Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!pacbell.com!pacbell!rtech!ingres!daveb
From: daveb@ingres.com (When a problem comes along . . . you must whip it)
Newsgroups: comp.databases
Subject: Re: Ingres and NFS
Message-ID: <1990Oct30.200146.5810@ingres.Ingres.COM>
Date: 30 Oct 90 20:01:45 GMT
References: <4691@spdcc.SPDCC.COM> <1474@beguine.UUCP>
Reply-To: daveb@hydra.Ingres.COM (Dave Brower)
Organization: Ingres Corporation, Alameda CA 94501
Lines: 30

In article <1474@beguine.UUCP> robinson@uncmed.med.unc.edu (Gerard A. Robinson) 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'd like
>>to get a better restatement or a refutation of the problem. 
>>
>Your supposition that an NFS mounted directory can be a valid area for 
>database storage for a single installation, is correct, at least in
>practice.  It is probably not a 'supported' configuration, however.

We don't support NFS data directories because NFS doesn't work reliably
enough.  Existing NFS implementations have some problems that prevent us
from guaranteeing transaction recoverability and integrity in some
circumstances.

One particular problem is that when a disk gets full, NFS prevents a
process from writing back in the middle of a file.  This makes it hard
to back out a transaction that was extending a table.  This may not be
in the NFS protocol, but it is in all the existing implementations we've
checked.

In most cases you really don't want to have your data on the NFS disk
anyway. You should be running the DBMS on the machine with the physical
disk and using INGRES/NET from the clients to get to that server.  It's
a lot lighter load on the network.

-dB
--
"VMS is a text-only adventure game. If you win you can use unix." - w.davidson
David Brower: {amdahl, cpsc6a, mtxinu, sun}!rtech!daveb daveb@ingres.com