Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site watdcsu.UUCP
Path: utzoo!watmath!watdcsu!herbie
From: herbie@watdcsu.UUCP (Herb Chong [DCS])
Newsgroups: net.arch
Subject: Re: Magic Cookies and File Systems (Religious FLAME)
Message-ID: <1091@watdcsu.UUCP>
Date: Fri, 8-Mar-85 16:12:57 EST
Article-I.D.: watdcsu.1091
Posted: Fri Mar  8 16:12:57 1985
Date-Received: Sat, 9-Mar-85 08:06:09 EST
References: <917@sjuvax.UUCP> <538@rlgvax.UUCP> <190@u1100s.UUCP>, <1078@watdcsu.UUCP> <5185@utzoo.UUCP>
Organization: U of Waterloo
Lines: 74

>Nobody ever said that locks should necessarily be *implemented* using
>the file system.  The point is that they should *look* like part of
>the file system to the customer.  We have a perfectly good name->resource
>mapping mechanism already in existence; why invent another?
>				Henry Spencer
--------------------------------------
>However, I believe that in this case you are making an unnecessary
>assumption that "file system" means "disk drives".  The first is a
>logical concept, while the second is a physical concept.  Part of the
>file system (the temporary part) can be kept in (virtual) memory at all
>time, and the magic cookies can be in this part.  The advantage of
>keeping locks in the file system is that the single naming domain
>allows any program to access any object, if necessary.
>Ralph Johnson

point taken, gentlemen.  i alluded to this possibility when i spoke
about keeping the file system in real memory.  why not map to virtual
memory instead?  in fact, why not have an entire file system in virtual
memory?  (here i use file system to mean the unix definition of file
system which corresponds to a logical disk pack rather than the ENTIRE
file system.) let's have a look at the pluses and minuses.  first the
pluses:

1)	consistent object naming convention (a pathname)
2)	high access speed and ease of consistency checking
3)	trivial generalization to virtual files that can be read/written,
	and otherwise manipulated using existing system calls
4)	small changes in kernel code, if any, of existing unix systems

now some minuses:
1)	if the virtual files are being used for anything other than
	locking, yur system MUST not be memory bound and MUST have
	a well tuned pageing system.  otherwise your CPU thrashes
2)	relating file systems to a lock is not as intuitively obvious as
	you think.  it's hard enough to explain interprocess synchronization
	sometimes without bringing in the complexity of using the
	file system for locking.

mostly, i am quibbling over conceptualization.  even if the lock is
viewed as a file, what is actually happening is still that a named
object in storage (usually a bit or word) is what the system
itself will be testing for existence of a lock.  you have just added a
layer of abstraction to the problem to unify a logical description of
the system.  deep down inside, it's still bits in memory that are being
massaged.  (i wonder why AT&T or Berkeley don't implement a virtual file
system for unix.  i think it would be a wonderful thing, if done right.)

as a side note, OS/360 (really MVS) implements a virtual file system if
one desires to by refering to UNIT=VIO in DD statements.  the file
(which cannot be permanent) is mapped to virtual storage and is handled
by paging devices if real I/O needs to be done.  one must not be
storage constrained, have an inefficient pageing system, nor be
accessing large amounts of storage (large files) with it or the system
will page itself to death.  MVS never thrashes due to the design of the
scheduler, but it will spend almost all it's time in page-wait if many
large VIO files are open at once.  a good MVS system administrator will
keep a careful watch on usage of VIO.  MVS never uses the VIO files for
locking, to my knowledge, though there is nothing to stop it from doing
so.  the ENQ/DEQ facility used for locking files is generalized enough
to lock on any resource.

as a further digression, i keep mentioning MVS because i know a lot
about it, and just about everything in operating system design has been
tried on it.  if nothing else, every algorithm that has even a
reasonable chance of working was tried at one time or another on OS/360.

Herb Chong...

I'm user-friendly -- I don't byte, I nybble....

UUCP:  {decvax|utzoo|ihnp4|allegra|clyde}!watmath!water!watdcsu!herbie
CSNET: herbie%watdcsu@waterloo.csnet
ARPA:  herbie%watdcsu%waterloo.csnet@csnet-relay.arpa
NETNORTH, BITNET, EARN: herbie@watdcs, herbie@watdcsu