Disk Layout/Partitioning Practices

[Kent Borg]

On Wed, Jan 28, 2004 at 03:44:14PM +0000, Alan Dunkley wrote:
> On Wednesday 28 Jan 2004 3:01 pm, Ron Herardian wrote:
> > When installing everything and allowing for future updates and packages I
> > am using the following disk layout:
> >
> > 	Mount Point	Size
> > 	/boot		100MB
> > 	/		500MB
> > 	/usr		4GB
> > 	/var		2GB
> > 	swap		2x physical RAM, e.g., 1GB
> > 	/home		TBD, e.g., 1GB per user
> >         /opt		TBD/catchall [3rd party servers will be installed here]

A couple suggestions:

Swap: Just use 1 GB.  It is big enough to be significant from a RAM
perspective, but it is still small and cheap in terms of disk sizes.
Put a lot of physical RAM in your machine, certainly.  If you do have
a *lot* of RAM, then a "small" 1 GB swap partition is a cheap little
kicker that the OS will actually find useful.  If you have little RAM,
then the OS might actually need a few hundred MB, so 1 GB is plenty.
I don't think the current 32-bit Linux kernels can often make good use
of much more swap, but I know they *can* put hundreds of MBs to use.
1 GB seems to cover that territory.  Note: If you have some specific
task with a really large data set (but a reasonable working set), then
certainly set your swap to easily hold your data.

Extra disk space: Yes, users can use a lot of space, but disks are
getting so large that even users might have to work to use it all.  I
suggest using the extra space for incremental backups.  Yes, backups.
Particularly if you can do a raid 1 array (to protect against routine
hardware failures--those short of things such as fire, flood,
earthquake, and theft), it is also good to have protection against
user and admin accidents, and backups do that.

To do those backups I suggest you do something similar to "mikes.
handy rotating-filesystem-snapshot utility",
<http://www.mikerubel.org/computers/rsync_snapshots/index.html>.

The jist of it is that recent versions of rsync have a "--link-dest"
option that makes it possible to make a "complete" backup where files
that have not changed from the last "complete" backup are actually
hard links back to common data.  It means it is possible to have a
bunch of what appear to be complete backups, that look like simple
directory trees, but which are actually rather compact incremental
backups that only use up inodes and space for files that changed.

Maintenance is easy too: want to prune old backups, say deleting some
old dailies but keeping weeklies?  Cool.  Just delete the trees you
don't want and everything will work right.

I even do this on my notebook, which doesn't have raid 1, and what do
you know?, my notebook recently got knocked on the floor while playing
MP3s, ruining the disk.  However, "ruined" didn't mean every sector
was unreadable.  Using originals and on-disk backups I was able to
recover *everything* I wanted.

Combine on-disk backups with raid 1 mirroring and you are pretty damn
safe.  Note: this backup scheme keeps the backup partition read-only
all of the time for users, and nearly all of the time for root.  It is
pretty safe.

NB, I have my notebook partitioned this way:

   9.8G   /
  64  G   /root/backups
 299  M   /boot
   1  G   <swap>


-kb, the Kent whose 192MB notebook, with lots of web browser windows
open, is currently using 373MB of swap.