home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / alt / hackers / 1827 next >
Encoding:
Text File  |  1992-12-12  |  3.0 KB  |  70 lines
  1. Newsgroups: alt.hackers
  2. Path: sparky!uunet!caen!batcomputer!bouncer
  3. From: eirik@elf.TN.Cornell.EDU (Eirik Fuller)
  4. Subject: fun with tmpfs
  5. Message-ID: <1992Dec12.115358.14593@tc.cornell.edu>
  6. Sender: news@tc.cornell.edu
  7. Nntp-Posting-Host: dumpster.tc.cornell.edu
  8. Organization: Cornell Theory Center
  9. Date: Sat, 12 Dec 1992 11:53:58 GMT
  10. Approved: tmporarily
  11. Lines: 57
  12.  
  13.  
  14. I recently upgraded elf.TN.Cornell.EDU from a 3/280 to a 4/280; this
  15. required a complete overhaul of several file systems, namely "/",
  16. "/usr", and "/usr/local".
  17.  
  18. In preparation for this overhaul, I booted the new CPU board as a
  19. diskless client of the 3/280, so that I could do such things as
  20. building a custom kernel (necessary for my Rimfire disk controllers)
  21. and bootstrapping the latest gcc.  I put all the sun4 binaries into
  22. the same filesystem, "/export", for this.  Ordinarily I like to keep
  23. "/usr/local" a separate partition from "/usr", but for temporary usage
  24. I didn't mind mixing it all in "/export".  Anyway, when the time came
  25. to build the new file systems, I didn't feel like copying them
  26. separately, so I did something like
  27.  
  28.     for fs in /dev/rrf4[agf]; do newfs $fs; done
  29.     mkdir -p /tmp/root/dumpster /tmp/exec/sun4
  30.     mount /dev/rf4a /tmp/root/dumpster
  31.     mount /dev/rf4g /tmp/exec/sun4
  32.     mkdir /tmp/exec/sun4/local
  33.     mount /dev/rf4f /tmp/exec/sun4/local
  34.     cd /tmp
  35.     dump 0f - /export | restore rf -
  36.  
  37. In addition to sorting out the three new file systems, this also made
  38. copies of the other client root directories, and all of the client
  39. swap files.  I wasn't especially worried about filling up "/tmp",
  40. given that (at least, in single user mode) it has more free space in
  41. it than the total size of "/export".
  42.  
  43. To reclaim the virtual memory used up by the "restore leakage", I
  44. unmounted "/tmp" and remounted it again.  I was in single user mode,
  45. so I wasn't concerned with "/tmp/.X11-unix/" and such disappearing.
  46.  
  47. Usually when I set up the boot disk for a new machine, or an OS
  48. upgrade, or anything along those lines, I boot the new machine
  49. diskless long enough to set up the new boot disk.  For this upgrade, I
  50. did something like that, but when it came time to boot the new CPU for
  51. real, its file server (the prior CPU in the same cage) wasn't up.  I
  52. did the last part of the disk setup with the old CPU, installboot and
  53. all.  When it came time to make the switch, I recabled the disks (I
  54. essentially swapped the controllers).  If I want to "downgrade", I can
  55. put the disks back the way they were and swap CPU boards back, at
  56. least until I scrub the original boot disk.
  57.  
  58.  
  59. For those who aren't sufficiently familiar with SunOS, perhaps I
  60. should mention that tmpfs is a "virtual memory RAM disk".  While it
  61. should work nearly as well mounting the new file systems under any
  62. file system with enough free space, I find it more satisfying to
  63. confine "restore leakage" to a truly disposable file system.
  64.  
  65.  
  66. P.S.  Yes, I really did call the client dumpster; in fact, the machine
  67. from which I'm posting this is a Sun3 diskless client with that name.
  68. The name goes back to another Sun3 which used to perform our daily
  69. backups (dumps) on an Exabyte.
  70.