beaulieu@uunet.uu.net (Larry Beaulieu) (03/08/90)
According to the 1/90 4.1 release report, TFS will be useful when "users want to install local versions of a binary..." Is this an implication that ONLY binary files will be supported under TFS? Larry Beaulieu ...uunet!gca!beaulieu SMTS/Software Engineer GCA Corporation, "Live to step, step to live..." Andover, MA
lm@sun.com (Larry McVoy) (03/09/90)
In article <5595@brazos.Rice.edu> gca!beaulieu@uunet.uu.net (Larry Beaulieu) writes: >X-Sun-Spots-Digest: Volume 9, Issue 79, message 4 > >According to the 1/90 4.1 release report, TFS will be useful when "users >want to install local versions of a binary..." Is this an implication that >ONLY binary files will be supported under TFS? You've misunderstood TFS (Translucent File System). It's a stacked file system - it sits on top of another file system and requests for files are satisfied from the top file system if the files exist in that system and from the bottom file system otherwise. The example is an obviuos use: if a use has some program (that is broken because: ) that insists on living in /usr/local/bin (like mh) and you can't write in /usr/local/bin (like me) then you can put your program in an otherwise empty file system and mount that file system over /usr/local/bin. What I say is my opinion. I am not paid to speak for Sun, I'm paid to hack. Besides, I frequently read news when I'm drjhgunghc, err, um, drunk. Larry McVoy, Sun Microsystems (415) 336-7627 ...!sun!lm or lm@sun.com
chuck@trantor.harris-atd.com (Chuck Musciano) (03/14/90)
Larry McVoy (lm@sun.com) writes: > You've misunderstood TFS (Translucent File System). It's a stacked file > system - it sits on top of another file system and requests for files are > satisfied from the top file system if the files exist in that system and > from the bottom file system otherwise. The example is an obviuos use: if > a use has some program (that is broken because: ) that insists on living > in /usr/local/bin (like mh) and you can't write in /usr/local/bin (like > me) then you can put your program in an otherwise empty file system and > mount that file system over /usr/local/bin. Ah, those who forget history are condemned to repeat it! Older Sun users will recognize Translucent File Systems to be a snappy new name for a very old idea. Go back, way back, to 1964, and IBM's OS/360. People who know the difference between an 026 and an 029 keypunch might recognize //SYSIN DD HOSAJM.FIRST.DATASET // DD HOSAJM.NEXT.DATASET as the way you created "translucent" file systems, concatenating multiple datasets into one logical dataset. A very handy concept, one missing from Unix for a long time. A new idea? No way. A good idea? Yes. I'm glad it will be in 4.1. Chuck Musciano ARPA : chuck@trantor.harris-atd.com Harris Corporation Usenet: ...!uunet!x102a!trantor!chuck PO Box 37, MS 3A/1912 AT&T : (407) 727-6131 Melbourne, FL 32902 FAX : (407) 727-{5118,5227,4004} I'm glad you asked, son. Being popular is the most important thing in the world. -- Homer Simpson
seeger@manatee.cis.ufl.edu (F. L. Charles Seeger III) (03/16/90)
Larry McVoy (lm@sun.com) writes: | You've misunderstood TFS (Translucent File System). It's a stacked file | system - it sits on top of another file system and requests for files are | satisfied from the top file system if the files exist in that system and | from the bottom file system otherwise. The example is an obviuos use: if | a use has some program (that is broken because: ) that insists on living | in /usr/local/bin (like mh) and you can't write in /usr/local/bin (like | me) then you can put your program in an otherwise empty file system and | mount that file system over /usr/local/bin. Chuck Musciano (chuck@trantor.harris-atd.com) writes: | ... A new idea? No way. A good idea? Yes. I'm glad | it will be in 4.1. OK. Can someone who has either used or read the manual briefly explain TFS? We would like to put copies of the most heavily read executables on local workstation disks. This seems to be the best use of TFS. However, it sounds as though the file server's /usr must be mounted first, then the smaller local /usr is "translucently" mounted over it. How should the local disk be laid out (I need to do this soon on some new drives)? When I first heard of TFS, I thought it worked the other way, i.e. I planned to keep a, say, 30-40 MB root partition with executables under /usr and /local (which we have started using rather than /usr/local). Then, the server's /usr and /local would be mounted. translucently over these directory trees. This appears to be backward. Do we need separate /usr and /local disk partitions to do this, or can a subdirectory of an already mounted partition be used to mount translucently over NFS mounted file systems? BTW, I thought it was a good idea to (a) have local stuff in a separate file system and (b) avoid mounting one NFS file system over another. That is why I started using /local. Does TFS make this look like a poor decision? I would not want to create separate local /usr and /local partitions on those small Quantum 100 MB drives. What are the wise choices here? Put /local back under /usr, so that all the executables on the workstation can share a single partition? Next, are there any other imaginitive uses of TFS, other than the these two examples? Is there much overhead involved with using TFS? Will "tfs" be a file system type in fstab, or will "translucent" be a mount option? Are there any restrictions on the stacking of file systems, especially with respect to depth or ordering of fs types? Finally, does anyone have any statistics on what executables/shared-libs are most heavily served over NFS? I suppose that we can guess fairly well, but there may be some suprises, as well as great variation between sites. Thanks, Charles Seeger E301 CSE Building +1 904 392 1508 CIS Department University of Florida seeger@ufl.edu Gainesville, FL 32611
aklietz@occam.ncsa.uiuc.edu (Alan Klietz) (03/20/90)
F. L. Charles Seeger III writes: >OK. Can someone who has either used or read the manual briefly explain TFS? TFS sounds a lot like Korn and Krell's 3-D File System. Given AT&T/SUN collaboration, it is possible that they are the similar. The 3-D FS adds a notion of "views" -- higher planes of file trees which can be laid atop the base tree by the user. Special privileges are not required. To get at the lower layers, you prefix the hidden component(s) with ".../". See the 1989 Summer USENIX proceedings for details. (And you thought symbolic links caused security holes? Just wait! :-) Alan E. Klietz University of Illinois at Urbana-Champaign 605 E. Springfield Avenue Champaign, IL 61820 Ph: +1 217 244 8024 Internet: aklietz@ncsa.uiuc.edu