m5@lynx.uucp (Mike McNally) (06/08/89)
What bad bad things happen if I symbolically link /tmp to /usr/tmp? My
root file system is tiny and I run out of space often. Thanks to the
wondrous Integrated "Solutions" SCSI driver, I can't repartition the
disk.
My fear is that some demon or something will go nuts when the system
boots. I guess I could make a /usr/tmp in the root file system, which
will go away when /usr is mounted. Hopefully nothing bad happens if a
file is open in a directory when it gets "covered up" by a mount.
--
Mike McNally Lynx Real-Time Systems
uucp: {voder,athsys}!lynx!m5 phone: 408 370 2233
Where equal mind and contest equal, go.karl@giza.cis.ohio-state.edu (Karl Kleinpaste) (06/09/89)
I have had /tmp as a symlink to a variety of other places around my filesystems for ages. It's harmless and useful for the extra disc space available by doing so. Go ahead.
kai@uicsrd.csrd.uiuc.edu (06/09/89)
> What bad bad things happen if I symbolically link /tmp to /usr/tmp? My > root file system is tiny and I run out of space often. Thanks to the > Mike McNally uucp: {voder,athsys}!lynx!m5 Nothing bad should happen. I have done this on a few of our BSD and SVR3 systems where we didn't have enough disk space to create a standalone /tmp partition, and /usr had about 60 Mb free space. Just make sure your boot time scripts don't "rm -rf /tmp; mkdir /tmp" like one System V host I have did.
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/09/89)
In article <5712@lynx.UUCP> m5@lynx.UUCP (Mike McNally) writes: >What bad bad things happen if I symbolically link /tmp to /usr/tmp? As you suggested later, the main thing to worry about is that /tmp is probably required before the /usr filesystem is mounted.
kemnitz@mitisft.Convergent.COM (Gregory Kemnitz) (06/10/89)
In article <5712@lynx.UUCP>, m5@lynx.uucp (Mike McNally) writes: # What bad bad things happen if I symbolically link /tmp to /usr/tmp? My # root file system is tiny and I run out of space often. Thanks to the # wondrous Integrated "Solutions" SCSI driver, I can't repartition the # disk. # # My fear is that some demon or something will go nuts when the system # boots. I guess I could make a /usr/tmp in the root file system, which # will go away when /usr is mounted. Hopefully nothing bad happens if a # file is open in a directory when it gets "covered up" by a mount. # # -- # Mike McNally Lynx Real-Time Systems # uucp: {voder,athsys}!lynx!m5 phone: 408 370 2233 # # Where equal mind and contest equal, go. I once wrote a piece of software that did autosaves into /usr/tmp and restored from them if the system went down (or if my software crashed :-). I don't know how many other programs use /usr/tmp to save autosave files (does VI??) but I know at least one does :-). -- ----------------------------------+-------------------------------------- Greg Kemnitz | "May you live in interesting times" kemnitz@Convergent.COM | | --Chinese curse
steve@nuchat.UUCP (Steve Nuchia) (06/10/89)
In article <10390@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <5712@lynx.UUCP> m5@lynx.UUCP (Mike McNally) writes: >>What bad bad things happen if I symbolically link /tmp to /usr/tmp? >As you suggested later, the main thing to worry about is that /tmp >is probably required before the /usr filesystem is mounted. That is easy to deal with as long as no file in /tmp needs to survive the mounting of /usr. Just create a /usr/tmp under the /usr mount point directory, ie, mkdir /usr/tmp while /usr is not mounted. Then the symbolic link will have somewhere to point during the early boot phase and single user mode. Actually most people I know who do this use /usr/realtmp or something like that rather than /usr/tmp. I can't think of anything that will collide off the top of my head by why risk it. -- Steve Nuchia South Coast Computing Services uunet!nuchat!steve POB 890952 Houston, Texas 77289 (713) 964 2462 Consultation & Systems, Support for PD Software.
envbvs@epb2.lbl.gov (Brian V. Smith) (06/10/89)
In article <10390@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > In article <5712@lynx.UUCP> m5@lynx.UUCP (Mike McNally) writes: > >What bad bad things happen if I symbolically link /tmp to /usr/tmp? > > As you suggested later, the main thing to worry about is that /tmp > is probably required before the /usr filesystem is mounted. We haven't had any problem with our /tmp directory sym-linked to /usr/tmp.from.root (as we call it). It doesn't seem that it is needed during booting. _____________________________________ Brian V. Smith (bvsmith@lbl.gov) Lawrence Berkeley Laboratory We don't need no signatures!
grr@cbmvax.UUCP (George Robbins) (06/11/89)
In article <2803@helios.ee.lbl.gov> envbvs@epb2.lbl.gov (Brian V. Smith) writes: > In article <10390@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > > In article <5712@lynx.UUCP> m5@lynx.UUCP (Mike McNally) writes: > > >What bad bad things happen if I symbolically link /tmp to /usr/tmp? > > > > As you suggested later, the main thing to worry about is that /tmp > > is probably required before the /usr filesystem is mounted. > > We haven't had any problem with our /tmp directory sym-linked to > /usr/tmp.from.root (as we call it). It doesn't seem that it is needed > during booting. One possible area of concern would be if you are in a situation where fsck uses/needs a workfile to check your larger filesystems. You might note that in this case, using a workfile in /tmp, where /tmp is just a directory in the root is not a very good idea - you're better off putting the file in a partition the gets check first (perhaps a /tmp partition) or having an itty-bitty partition that is used only as a fsck workfile. In general, /usr/tmp isn't an idea that maps comfortably onto larger systems all that comfortably unless it happens to be the mount point for a "work" partition. There's an implicit assumption, that /usr is the filesystem where the user directories live, and thus a good place to put big work files. Unfortunatly, user and backup administration is much simpler if user directories are in their own filesystem, and /usr is a "system" directory. In this case, you may be better off with a /tmp filesystem, and no /usr/tmp. In the olde days, there was no requirement that you have a /usr/tmp - programs could try to put files there if it existed and if not were then expect to try again in /tmp. I don't know if this is still a safe assumption or not. Note that most of the problem goes away with BSD, since symbolic links allow a fairly arbitrary mapping of the conventional filesystem hierarchy onto the underlying partitions. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
mday@ohs.UUCP (Matthew T. Day) (06/12/89)
We have also done such a thing (link /tmp to /usr/tmp), with only one side effect. When we enter single user mode for disk backups, it complains that about the set-up, and we have to manually mount /usr. No big deal, it sure solved our problems we had here. -- +----------------------------------------------------------+-----------------+ | Matthew T. Day, Orem High School, Orem, Utah | "He who laughs, | | Internet: mday@ohs.uucp UUCP: ..!uunet!iconsys!ohs!mday | lasts." | +----------------------------------------------------------+-----------------+
mouse@mcgill-vision.UUCP (der Mouse) (06/22/89)
In article <310@ohs.UUCP>, mday@ohs.UUCP (Matthew T. Day) writes: > We have also done such a thing (link /tmp to /usr/tmp), with only one > side effect. When we enter single user mode for disk backups, it > complains that about the set-up, and we have to manually mount /usr. Not at all - just mkdir /usr/tmp, with /usr not mounted. Then when /usr is unmounted, /usr/tmp is on your root partition, but it exists. When you mount /usr, everything in the root partition's /usr is hidden, and whatever's in the filesystem appears there, complete with /usr/tmp. I'd advise clearing /usr/tmp before mounting /usr in your boot script, though, to make sure it doesn't accumulate junk and gradually fill your root partition. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu