home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / sgi / 16790 < prev    next >
Encoding:
Internet Message Format  |  1992-11-23  |  6.8 KB

  1. Path: sparky!uunet!pipex!warwick!uknet!doc.ic.ac.uk!cc.ic.ac.uk!imperial.ac.uk!vulture
  2. From: vulture@imperial.ac.uk (Thomas Sippel - Dau)
  3. Newsgroups: comp.sys.sgi
  4. Subject: Re: Indigo as server for a RS600 client - was: NFS links from RS6000 server to SGI client (longish)
  5. Keywords: file system improvements, backup, archive, data interchange
  6. Message-ID: <1992Nov23.202620.18342@cc.ic.ac.uk>
  7. Date: 23 Nov 92 20:26:20 GMT
  8. References: <34067@adm.brl.mil> <1992Nov14.021925.14641@ultra.com> <1992Nov20.172633.26750@cc.ic.ac.uk> <sk0bfes@rhyolite.wpd.sgi.com>
  9. Sender: vulture@carrion.cc.ic.ac.uk (Thomas Sippel - Dau)
  10. Reply-To: cmaae47@imperial.ac.uk
  11. Organization: Imperial College of Science, Technology and Medicine
  12. Lines: 172
  13. Nntp-Posting-Host: cscgc
  14.  
  15. In article <sk0bfes@rhyolite.wpd.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
  16. -
  17. - A process can be running as root on the client, but not be root as far
  18. - as the NFS server is concerned. 
  19. - You don't really want each and every application including backup or
  20. - archive utility to duplicate the kernel suser() check.  The messiness
  21. - of real, effective, and other flavors of UID and GID are not the sort
  22. - of thing you really want to spread into every application that might be
  23. - called upon to do things that are priviledged.
  24.  
  25. I quite agree, but ...
  26. .....
  27. - Should the backup or archiving utility check to see that it is sufficiently
  28. - priviledged to write ordinary files where directed?  Or should it just
  29. - let the operating system worry about it?
  30.  
  31. Unfortunately backup and archive utilities are special, and the file system
  32. is also special. New concepts added to the file system will need to be 
  33. reflected in archiving utilities, and changes in archiving utilities are
  34. required to work across systems.
  35.  
  36. Time and again "improvements" to the unix file system have been made without
  37. parallel upgrading of backup utilities. Time and again these utilities
  38. have been "upgraded" to create portable media which cannot be interpreted 
  39. by other systems.
  40.  
  41. According to one of my pet hate lists, this has happened for:
  42.  
  43.     o   hard links
  44.     o   symbolic links
  45.     o   network access to files
  46.     o   long filenames
  47.     o   long pathnames
  48.     o   pseudo-files (named pipes, streams, sockets, ... )
  49.     o   access control lists
  50.     o   even longer filenames
  51.     o   whole file caching
  52.     o   i-node table limits
  53.     o   file space quotas
  54.  
  55. With hard links this has already been addressed in the bronze-age of unix,
  56. which is why tar processors on unix will generally not cause information
  57. to be duplicated on the tar set when it contains several links to the same 
  58. inode, and restored from there.
  59.  
  60. This puts us in a neat devil's triangle:
  61.  
  62.     A   improvements are impossible (have to be working across all systems
  63.         before being allowed on one system)
  64.  
  65.     B   data interchange is impossible (because of incompatible improvements)
  66.  
  67.     C   data backup is impossible (as the improvements are either not backed
  68.         up or not portable)
  69.  
  70. You can avoid one or two of these, but not all three. This happens with
  71. many aspects of computing (or life), it is just that a reliable file
  72. system is so important to use of a computer that makes the choice so
  73. invidious and so difficult to ease.
  74.  
  75. Manufacturers and other hackers have generally preferred to put in a 
  76. modification to the file system and let the user find out how to get 
  77. hold of a valid backup of the resulting filesystem, and how to implement
  78. the new concepts with other file system users or on other systems.
  79.  
  80. There is really no excuse any more not to provide a way to conserve such
  81. file system improvements in a dumpset with codified format (tar and cpio)
  82. so that these can be: 
  83.  
  84.     a.  recreated in the improved form on a system with the 
  85.         same processor and the improved concepts
  86.  
  87.     b.  transferred to a system without improvements, processed by a basic 
  88.         tar or cpio format processor, recreated on that system and restored
  89.         with improved conepts intact on an improved system.
  90.  
  91. Without that, I'm afraid, the old rule applies:
  92.  
  93.     Small improvements make it worse.
  94.  
  95. I conclude (yes please ...) with a few examples of particular howlers:
  96.  
  97. I-node table limits are just now starting to bite users, i.e. the file 
  98. system has been hacked to accept more than 2**15 - 1 inodes, but the 
  99. appropriate data items in tar have not been uprated. Consequently users
  100. will get additional files (instead of links) if the processor runs out
  101. of table space.
  102.  
  103. Some manufacturers (who shall be nameless) ship products that cannot be 
  104. backed up and restored with the systems backup utility, because a target
  105. of a symbolic link is too long. Is that a broken system, a broken product,
  106. or a broken product development tool and file naming convention ?
  107.  
  108. Or look at the following fortran program, which creates a temporary file
  109. if necessary, but deletes it only if it had actually itself created it.
  110. Such a code is often necessary in out of core solvers, so that users can
  111. place temporary files on fast access devices or those with enough filespace.
  112.  
  113.       program clod
  114.       logical ex
  115.       inquire ( file = 'bill', exist = ex )
  116.  
  117.       if ( ex ) then
  118.         open ( 1, file = 'bill', status = 'old' )
  119.         else
  120.         open ( 1, file = 'bill', status = 'new' )
  121.         endif
  122.  
  123.       write ( 1, '(a)' ) 'you clod'
  124.  
  125.       if ( ex ) then
  126.         print *, 'bill existed, keeping it'
  127.         close ( 1, status = 'keep' )
  128.         else
  129.         print *, 'bill did not exist, will delete it'
  130.         close ( 1, status = 'delete' )
  131.         endif
  132.  
  133.       stop
  134.       end
  135.  
  136. On unix it may fail because of a the way the richness of file system 
  137. facilities has been mapped into the limited set of fortran file concepts, 
  138. as follows:
  139.  
  140. carrion$ f77 clod.f
  141. carrion$ rm fred bill
  142. rm: bill non-existent
  143. carrion$ a.out
  144.  bill did not exist, will delete it
  145. carrion$ ls -l fred bill
  146. fred: No such file or directory
  147. bill: No such file or directory
  148. carrion$ ln -s fred bill
  149. carrion$ a.out
  150.  bill did not exist, will delete it
  151. carrion$ cat fred
  152. you clod
  153.  
  154. The reaction of an incredibly big manufacturer of a fortran compilers to
  155. a related problem with the "exist" keyword of "inquire" started with:
  156.  
  157. The Fortran Standard refers to files not datasets ... 
  158.          (I won't bore you with the details)
  159.  
  160. Editors trying to do atomic updates (by writing to a temporary file and
  161. renaming it) have been flattened again and again by additional concepts.
  162. The Andrew File System discussion groups are full of corpses like that.
  163. And with Windows, every application is an editor (for the user preference
  164. settings).
  165.                                 Thomas
  166. -- 
  167. *** This is the operative statement, all previous statements are inoperative.
  168. *   email: cmaae47 @ ic.ac.uk (Thomas Sippel - Dau) (uk.ac.ic on Janet)
  169. *   voice: +44 71 589 5111 x4937 or 4934 (day), or +44 71 823 9497 (fax)
  170. *   snail: Imperial College of Science, Technology and Medicine
  171. *   The Center for Computing Services, Kensington SW7 2BX, Great Britain
  172.