dyer@spdcc.COM (Steve Dyer) (10/30/90)
I'm sorry this question is on such a primitive level, but
it reflects the primitive nature of the information which
has percolated back to me, none of which I've heard told by
anyone who might really know what is going on. (I also don't
read comp.databases regularly, so I don't know if this has been
discussed before.)
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.
I'm not intimately familiar with the innards of Ingres,
but I would assume that this might refer to the need for
a local raw device to hold the log file. Also, too, it would
seem obvious that two Ingres instances running on different
machines but on the same database thru NFS won't work (at least
without lots of external support added into the Ingres code for
serialization and coordination.) But it isn't obvious to me
that just having the databases placed in a directory on a NFS
mounted filesystem managed by a single Ingres instance would
not work, as long as you has a local raw device for the log.
(Yes, there are issues of speed. I'm discounting that for now...)
Can anyone who might know about this or have tried it comment?
Thanks.
--
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu, dyer@hstbme.mit.edurobinson@durham.med.unc.edu (Gerard A. Robinson) (10/30/90)
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. > The most likely answer to this is that INGRES version 6.0-6.2 had no provisions for supporting diskless clients sharing an INGRES directory tree. There was an internal document which one could obtain that described how to cobble together an installation, which worked, but was tedious. Version 6.3 (for Suns at least) provides an additional directory under II_SYSTEM, the admin directory. Under 'admin' there is a directory for each host sharing the distribution. This directory contains the files for global INGRES environment variables and INGRES/Net startup options. The installation assumes (correctly) that no DBMS servers will be running. This makes the installation much easier. While there are still no provisions for sharing the INGRES/Net authorization and control files, it is much nicer than in 6.2. 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. Gerard Robinson
kbittner@oracle.uucp (Kurt Bittner) (10/30/90)
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. > 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. In general, I wouldn't be real excited about someone using NFS for a database application even if it is technically possible. Most database vendors now provide the ability to use client-server software to achieve distrubuted access to data that go beyond NFS in their capabilities (at least as far as the DBMS app is concerned). This is not to say, however, that you can't run other apps on the same machine using NFS, just don't use it for the DBMS. --- "My opinions are solely my own and do not reflect those of my employer."
daveb@ingres.com (When a problem comes along . . . you must whip it) (10/31/90)
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
mao@eden.Berkeley.EDU (Mike Olson) (10/31/90)
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
mh@roger.imsd.contel.com (Mike Hoegeman) (10/31/90)
In article <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'd like >>to get a better restatement or a refutation of the problem. does'nt work is way too vague, but see the stuff below... >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. Yes, NFS is stateless, but what does this have to do with the statement below ?? >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. umm... The database itself usually does transaction recovery and rollbacks. NFS has nothing to do with it, NFS just reads and write disk blocks basically. >As a result, a database running on NFS would >have a high likelihood of corruption in the event of a crash. This is a bogus statement. I used to use oracle on a machine which had it's database files on a another machine (which had extra disk space but no oracle software) via an NFS hard mount. I *never* had any problem with it and the nfs server used to go up and down all the time unexpectedly (the power in the building was pretty bad). When the server goes belly up, oracle just blocks until it the server comes back up. if the client w/ oracle got rebooted is has the same recovery abilites as if it was'nt using an NFS file system. > >In general, I wouldn't be real excited about someone using NFS for a database >application even if it is technically possible. Most database vendors now >provide the ability to use client-server software to achieve distrubuted access >to data that go beyond NFS in their capabilities (at least as far as the >DBMS app is concerned). This is not to say, however, that you can't run other >apps on the same machine using NFS, just don't use it for the DBMS. Well, i would'nt heartily recommend using NFS for databases either. But in the case of oracle and probably most other db's that don't use a raw filesystem in the context is described above it's not terribly dangerous either. Actually a funny thing about my weird oracle/NFS setup was that it ran *faster* than when i had the files locally oracle machine because of biod (read ahead deamons). (i was doing mostly db reads).
sergio@ingres.com (Sergio Aponte) (11/01/90)
In article <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'd like >>to get a better restatement or a refutation of the problem. >> > The suported use of NFS is for client installations to run clients (or front ends, as they used to be called). You install Ingres on the server node, and NFS mount to a client node, and you run the clients processes on it, not the DBMS. The DBMS should run on the server node, and you should use Ingres/NET to access the DBs. That way, you use the CPU on the client to run the client processes, and keep consistency on your DB by using the server DBMS on your server node. In this scenario, NFS saves you from having many installations of Ingres eating up disk space. Good use for it. /* As before, this is my own contribution and in no way an official statement from ASK Computers, Ingres Division */ -- ------------------------------------------------------------------------------- | Internet: sergio@squid.ingres.com Sergio L. Aponte, MTS @ Ingres Corp. | | UUCP : {sun,mtxinu,pyramid,pacbell,hoptoad,amdahl}!ingres!squid!sergio | -------------------------------------------------------------------------------
henkp@ruuinf.cs.ruu.nl (Henk P. Penning) (11/02/90)
In article <1990Oct31.174509.14988@ingres.Ingres.COM> sergio@ingres.com (Sergio Aponte) writes: > [ A description of how to use ingres on a client using NFS ] I would very much like to hear how to use ingres on a number of diskless HP 9000/300 7.0 HP/UX clients served by a HP 9000/300 cluster server. As is customary with HP Diskless, such clients are not served by NFS but 'see' the very same file-system that the server does. Ingres claims to have a version for HP 9000/300 HP/UX 7.0, but are Diskless clients supported ? Did anyone try to make this work ? === HenkP === -- Henk P. Penning, Dept of Computer Science, Utrecht University. Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31-30-534106 e-mail : henkp@cs.ruu.nl (uucp to hp4nl!ruuinf!henkp)