Mike Pepe wrote:
Hi Mike, I've been following this thread with some interest.
Mike McCarty wrote:
Well, I don't especially. And I'm open to suggestions.
My point is to let the variable-sized stuff which can
grow beyond all bounds due to defects in software or
boo-boos by the operator (read: me) not contaminate the
system.
That's an interesting consideration, but unless you've written all the
software you're running, (and even if you did) there's no guarantee that
some berserk program won't fill up /, or /usr, or /var, or /etc, or
/home... you get the point.
Well, I thought that *was* my point. If I put /home, /var,
/usr/local/var, /tmp, /var/spool and so on onto another disc, then
this will provide a measure of protection agains defective
software. Certainly not foolproof. And those areas which need
write access by the system can be writable by root only.
Already /etc is that way. Obviouly I can't just make /tmp
be writable only by root. So I'd like to move it somewhere
it won't/can't blast /.
Other than making a separate partition for every single directory on
your machine, there's no way to prepare for that contingency.
Eh? I'm not trying to protect everthing from everything else. Just
the system from beserk programs and disc fill-up.
It's not uncommon these days for systems out there to be configured with
one huge root filesystem, since then whatever processes need the space
have it wherever they may be. It does make tracking down where problems
occur more difficult.
That is (almost) the situation I'm in, now. I've got /boot, /swap,
and /. (Not counting removable medium devices.)
]# fdisk -l
Disk /dev/hda: 40.0 GB, 40020664320 bytes
16 heads, 63 sectors/track, 77545 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
Device Boot Start End Blocks Id System
/dev/hda1 1 8625 4346968+ b W95 FAT32
/dev/hda2 * 8626 60915 26354160 7 HPFS/NTFS
/dev/hda3 60916 61118 102312 83 Linux
/dev/hda4 61119 77545 8279208 f W95 Ext'd (LBA)
/dev/hda5 61119 76505 7755016+ 83 Linux
/dev/hda6 76506 77545 524128+ 82 Linux swap
/dev/hda1 and /dev/hda2 are Windows XP, /dev/hda3 is /boot,
hda5 is /, and /dev/hda6 is /swap.
I'm considering repartitioning and using a file for swap, rather
than a separate partition. That would make the system somewhat
more vulnerable to fs corruption, but I've read where file access
is just as fast, and a file is easier to resize than a partition.
However if you're really concerned about your home-grown application
going crazy and filling up the disk, you should obviously either put it
in its own partition or put it into a filesystem that can fill up
without too much negative impact on the system. (/home or /usr/local may
be good choices in this regard)
Everything I'm doing I'm putting into /home.
I'm not "really concerned" about my disc getting filled up.
And I've never had that problem with my own software.
All significant software has defects. A file system is
a significant piece of software. I don't want to push
the limits on the FS where the OS is contained. I don't
want an unbootable system. I want one partition on a
separate disc to contain that stuff. But I see that /home
and /tmp (and /var to a lesser extent, though /var/spool
is pretty much vulnerable) both need mount points.
True, but remember that nothing that happens in the filesystem will
prevent you from booting off the CD/DVD and fixing it, short of massive
hardware failure or total filesystem corruption. In that case, the
fullness of the underlying filesystem is unimportant.
Certainly I have not forgotten that.
[snip]
Dynamic, on-the-fly filesystem resizing is the domain of a LVM, but like
you I'd rather spend a couple of hours repartitioning the system than
worry about getting that to work.
Hallelujah and pass the donation plate!
If I were in your situation, and /home is big enough to handle user home
directories and your backup application, I'd just make a /home/tmp and
use that in my script. There's nothing special about /tmp except some
apps use it. Others use /var/tmp or whatever they're coded to do.
My main partition is quite full, unfortunately.
$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda5 7633264 5124056 2121460 71% /
/dev/hda3 99075 24602 69358 27% /boot
none 124044 0 124044 0% /dev/shm
I find that Linux is rather cramped in only 7G. What you suggest
would likely give me 80% or more of what I want.
Partly, this is an exercise in exploring what can be done.
I think a sane place to start would be to partition your disk with a
small /boot partition at the start, a large / partition, a swap
partition, and then either one big /home partition or separate /home and
/usr/local for the stuff you want to play with. Or as you're thinking,
putting /home and/or /usr/local on partition(s) on a separate disk
entirely. Seems entirely reasonable to me. If need be I can show you how
I have similar systems laid out.
LOL!
Exactly what I was proposing to do.
My question really revolved around making /tmp into a soft link
to /home/tmp on another disc. I was concerned with possible
race conditions during boot. I've gotten good feedback on using
a loopback mount rather than a soft link (which now that I have
a better understanding of what a loopback mount is, makes sense)
and some assurance that there would be no boot issues.
How *do* you have your system set up?
Also in Fedora, /tmp is not in RAM, and it is not automatically wiped
out at boot time. This behavior is common in Solaris.
Yes, I'm aware of some of the differences between different
UNIX like systems, having used UNIX, Xenix, Mt. Xinu,
HPUX, SunOs, Solaris, FreeBSD, LynxOs, and several flavors of
Linux.
I thought the way Solaris uses /usr/local is rather nice,
actually.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
