Xref: utzoo comp.unix.admin:76 comp.unix.internals:195
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!sdd.hp.com!decwrl!nsc!amdahl!ikluft
From: ikluft@uts.amdahl.com (Ian Kluft)
Newsgroups: comp.unix.admin,comp.unix.internals
Subject: Re: Same device, two mount points? Or, overutilizing my RAM disk...
Message-ID: <708v02ukc7P801@amdahl.uts.amdahl.com>
Date: 10 Sep 90 18:34:39 GMT
References: <900908.7074@franklin.com>
Reply-To: ikluft@uts.amdahl.com (Ian Kluft)
Distribution: usa
Organization: Amdahl Corporation, Systems Software, Santa Clara CA
Lines: 31

In article <900908.7074@franklin.com> bill@franklin.com (Bill) writes:
>I have a question, or rather several. I just recently wrote myself
>a RAM disk driver for my system for use with /tmp. [...]
>
>The first is that /tmp is not the only directory that I'd like to
>put into the RAM disk; I'd also like to put in /usr/tmp and maybe
>/usr/spool/locks and I'm sure I could find a few others that
>could be usefully made to go there. Well, the only solution I
>could think of (remember, this is SysV, no symbolic links), is to
>create several device files, each pointing to the same RAM disk
>and to mount each separately. (No, I don't want several RAM
>disks!)
>[...]

We have had a similar situation here with "shared DASD" (multi-ported
disks accessed by several mainframes running UTS).  Basically, any number
of systems can have the file system mounted read-only but only one can
have it read/write.

I believe that even with a RAMdisk accessed by one system, multiple mount
points for the same device would have to be treated the same way because you
can confuse the kernel.  Unwritten buffers can make each mount point out of
sync.

Since you're posting from a commercial site, I think you'd be best off to
take the conservative route (multiple RAMdisks) so that your organization
can continue to count on the system's reliability.
-- 
Ian Kluft                              UTS Systems Software, Amdahl Corporation
ikluft@uts.amdahl.com                                           Santa Clara, CA
          **** UTS == System V for mainframes and power users ****