Strategy for /tmp and /home Partitioning

[Mike McCarty]

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!