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