[SGVLUG] newbie qu: HDD partitions

[Dustin]

On Fri, 29 Jul 2005, Jeff Kutz wrote:

> I am going to load Fedora on a Dell Latitude C600 (1 GHz) laptop for a 
> dedicated Linux learn/play computer.  I am going with Fedora because it came 
> with the book Red Hat Linux by Mark G Sobell.

Welcome to the Free World. :-)

> My question is what would be the smartest way to partition the 20 GB hard 
> drive.  The author talks about partitions but it seems more like 
> subdirectories that he is talking about.

It is.  Tom explained this but it might help to give a little more detail:
drive letters were a bad idea that MS-Windows should have gotten rid of
(actually it has, you *can* mount NTFS partitions as directories just like
in a unix filesystem--I don't know why people don't do this).  Unix always
had a much better system (which NTFS borrowed): make them look like
subdirectories.  It works like this: your author suggests a separate
partition for logs.  Log files are kept in /var/log/* in unix, so what you
would do (actually what the installer would do) is create an empty
/var/log directory.  Then when you boot the system there will be a line in
a file called /etc/fstab (fstab == (f)ile(s)ystem(tab)le) which says
effectively attach (mount) the log partition to the empty /var/log
directory so it looks as though it *is* /var/log.  If you could look in
that directory before it was mounted (or booted into a special mode called
single-user mode where it hasn't been mounted yet), it would be empty:

$ ls /var/log
$

But after it is mounted you see all the log files stored in that partition 
exactly as though they are just an ordinary subdirectory:

$ ls /var/log
XFree86.0.log          dirmngr.log.1   mail.log.0         news
XFree86.0.log.old      dirmngr.log.2   mail.log.1.gz      ntop
XFree86.1.log          dirmngr.log.3   mail.log.2.gz      ntpd
XFree86.1.log.old      dirmngr.log.4   mail.log.3.gz      ntpd.0
XFree86.8.log          dmesg           mail.warn          ntpd.1.gz
XFree86.8.log.old      exim4           mail.warn.0        ntpd.2.gz
apache2                firewall        mail.warn.1.gz     ntpd.3.gz
aptitude               firewall.1      mail.warn.2.gz     ntpstats
aptitude.1.gz          firewall.2      messages           postgresql
aptitude.2.gz          firewall.3      messages.0         privoxy
aptitude.3.gz          flexbackup      messages.1.gz      samba
aptitude.4.gz          fontconfig.log  messages.2.gz      scrollkeeper.log
auth.log               gdm             messages.3.gz      
scrollkeeper.log.1
auth.log.0             kern.log        messages.4.gz      
scrollkeeper.log.2
auth.log.1.gz          kern.log.0      messages.5.gz      syslog
auth.log.2.gz          kern.log.1.gz   messages.6.gz      syslog.0
auth.log.3.gz          kern.log.2.gz   mindi.log          syslog.1.gz
base-config.log.1      kern.log.3.gz   mondo-archive.log  syslog.2.gz
base-config.timings.1  kern.log.4.gz   mysql              syslog.3.gz
boot                   kern.log.5.gz   mysql.err          syslog.4.gz
btmp                   kern.log.6.gz   mysql.err.1.gz     syslog.5.gz
btmp.1                 ksymoops        mysql.err.2.gz     syslog.6.gz
clamav                 lastlog         mysql.err.3.gz     tor
cups                   lpr.log         mysql.err.4.gz     user.log
daemon.log             lpr.log.0       mysql.err.5.gz     user.log.0
daemon.log.0           lpr.log.1.gz    mysql.err.6.gz     user.log.1.gz
daemon.log.1.gz        mail.err        mysql.err.7.gz     user.log.2.gz
daemon.log.2.gz        mail.err.0      mysql.log          user.log.3.gz
daemon.log.3.gz        mail.err.1.gz   mysql.log.1.gz     uucp.log
debian-installer       mail.err.2.gz   mysql.log.2.gz     wtmp
debug                  mail.info       mysql.log.3.gz     wtmp.1
debug.0                mail.info.0     mysql.log.4.gz     xdm.log
debug.1.gz             mail.info.1.gz  mysql.log.5.gz     xdm.log.1
debug.2.gz             mail.info.2.gz  mysql.log.6.gz
debug.3.gz             mail.info.3.gz  mysql.log.7.gz
dirmngr.log            mail.log        netatalk.log
$

(That is the actual contents of my /var/log directory, BTW.  It looks like 
I need to clean out some old logs.)

> ...The way I read the book he would 
> have me putting in some half-dozen partitions.  I am coming from the 
> DOS/Windows world.  Am I missing something here in the transition?

No, but that advice isn't necessarily the best if you're new to Linux.

> He talks about where I might run into a situation like a DOS attack and I 
> could suddenly get a truly huge collection of log files that would fill up a 
> partition and block other functions that need some disk room to operate.

Yes, that can be a problem.  However, if you're new to Linux, you may well 
have bigger problems on your mind.  If it gets too complex, don't worry 
about it this first time.

> ...It 
> has been my practice, even in the DOS/Windows world, to create a separate 
> partition for my data files.

If you wish to do that in Linux, what you should do is create a separate 
/home partition (which means a partition that would be mounted as though 
it were /home).  This means that all files owned by you (or any other 
users you create) will be on their own partition.  It's like having a data 
partition, but better because you just save things in your home directory 
as normal (this is why mounting as subdirectories is much better than 
drive letters--everything behaves identically either way).

> If you are starting from scratch, with a dedicated Linux laptop, how many 
> partitions would you build and what would you establish in each one?

Probably more than you should--how I do it isn't necessarily how you
should.  Sometimes it is bad to imitate experienced users, because they
might do things that will make life needlessly hard for you.  Tom's 
mention of LVM is a perfect example. :-)

Everything the book says is true; there are benefits to having many
partitions.  However, there is a significant downside: you must predict
how large the partitions should be or you waste a lot of disk space at
best, and can't use the system as you wish to at worst.  As an example of
the former, suppose you allocated 20G of space to /usr, and then it turns
out that installing everything you want only uses 6G.  You're wasting 14G
of space, and it isn't that easy for you to get it back (you could create
a special subdirectory for your data there and a symbolic link to it from
your home directory, but this is not only confusing but dangerous next
time you upgrade).  Now suppose you only allocated 4G to /usr and it turns
out that as time goes on you find some packages you really want to use,
but you have no space to install them (installed binaries generally go in
/usr).  Again, no good solution.  So don't overdo it until some time in
the future when you know exactly what you want and why.

BTW, when calculating partition space keep in mind that the performance of
all filesystems will degrade as it gets past, oh, 85% full.  So you need 
to plan to leave empty working space in each filesystem.

> ...Would 
> I maybe want three partitions, one for data, one for the OS and 
> applications, and one for swap and log files?

Here are some directories you could separate into their own partitions
and some comments about why you might or might not do it.  Some are more 
useful than others, which is why it's worth thinking about them one by 
one.

swap: *necessary*.  Linux can technically run with a swapfile in the
      filesystem (or none at all, for that matter), but it reduces
      performance for no gain.  Practically, you must have a separate
      swap partition.

If you only have swap and / (root), you have the "one big partition"
theory of disk partitioning.  Books don't usually recommend this, but
*many* people install Linux this way and they sky doesn't fall on their 
heads.  Do this if you really don't want to mess with 
partitioning--otherwise, at least break out /home.

/home: *extremely useful*.  This is the biggest win for a beginner,
       because it pays off when you upgrade your system.  This way the
       installer can blow away everything else and re-create a nice
       clean filesystem without ever touching your data.  The biggest
       downside: you have to have some idea of how much space the system
       needs.  Hopefully your distro offers some advice.  I currently
       have 7.2G used for everything but /home, and I have a reasonably
       full-featured install (inc. Gnome, OpenOffice, a bunch of audio
       apps).

Just swap, root, and home is a pretty good setup for beginners, and would
be my recommendation for most people.  You'll be glad you went to the
trouble of creating /home when you upgrade.

/var: This is where your logs are, caches, and other stuff.  Unix gets
      quite nasty if it runs out of space on the root partition.  For a
      beginner I doubt some kind of attack is the most likely reason for
      this to be useful.  Most likely, you'll have a log that isn't 
      getting rotated (perhaps you installed a third-party program and
      didn't remember or didn't know how to tell logrotate about it), and
      it'll grow quietly for months or years until bam, the system acts
      flaky and you have no clue why.

      I once had this happen running some old RedHat or the other (6.3?),
      and the install was broken so my logs weren't getting rotated.  The
      symptom, IIRC, was that X couldn't start.  Confusing, huh?

/tmp: something of a similar case to /var, in that a program can run amok
      and write tons of data to /tmp.  However, typically /tmp is emptied
      on each reboot so it's less of a problem.  Not that important for
      you right now.  In a security-minded install you can also mount this 
      "no execute" and foil script-kiddie attacks that depend on putting 
      something executable in /tmp.  But if you're worried about security
      you can probably find better places to start, like configuring a
      firewall and shutting down some of the useless services your distro
      probably "helpfully" installs for you.  This can be half a Gb or
      so (unless you run Gentoo, in which case either this or /var/tmp,
      I think the latter, needs to be *big* to hold temporary files when
      building gargantuan bloated packages like OpenOffice or KDE).

/boot: this doesn't have to be at the start of the disk anymore, modern
      boot loaders and kernels can boot off the last cylinder on the disk
      if you like.  It's a bit safer to have it on a small separate
      partition because you don't even have to have it mounted except when
      you install a new kernel or reconfigure the grub bootloader (so, 
      basically never for most users).  That means it's almost impossible 
      to screw up your kernel image and the like.  But it isn't *that*
      much help, so it's skippable your first time if you like.  On the
      plus side, it's small and doesn't grow--someone said
      200Mb, which is quite reasonable.

/usr: here is where most of your OS lives.  This doesn't make sense to
      break out unless you are doing other things as well.  One good 
      reason is if you're trying to lock down your box and want to mount 
      /usr read-only.  Another good reason is that if you break 
      *everything* out then "/" is left real small and won't ever grow,
      because it is mostly just things like text configuration files in 
      /etc.  So you can put it on a small partition, ideally also 
      read-only but I think in practice you can't really do that on most
      distros without a lot of work.  But you still have pretty close to
      a guarantee that / never runs out of space because almost everything 
      that programs actually write to is on some other partition.

      Probably not worth your time for now.

/opt: kind of like a confusing variant of /usr for some packages on some
      distros.  Don't bother unless you're fanatically tossing everything
      big out so you can mount / on a tiny partition.

/usr/local: if you install a lot of packages by hand without going through
      your distro'ss package manager, it's a good idea to make these 
      separate so when you upgrade you don't blow them all away (you may
      well still need to upgrade a bunch of stuff, but at least you get
      to choose the time).  Otherwise, it's basically empty.

/var/log, /var/spool/mail, /var/spool/news, var/cache, var/www....

      If you know exactly what you are doing, you can do some nice things
      by breaking some of these out.  For example, if you run a 
      full-fledged news spool, it's nice to have it on a separate 
      /var/spool/news partition so that (a) if it fills up there is still 
      room for stuff like logs so unix doesn't start getting real cranky, 
      and (b) you can optimize the filesystem for the sorts of files news 
      creates.  Similarly, if you ran an ISP you'd definitely want user
      mail on its own partition.

      If you don't know exactly what you are doing, though, don't bother
      and leave all of /var on a single filesystem.

Another advantage of many partitions: each one can have a different
filesystem, to take advantage of it's particular advantages.  Don't worry
about this either, for now.

There are further strange tricks you can play; for example, lvm lets you
make partition-like volumes that are very flexible and dynamic, so you
don't have to predict their size in advance.  This is another good thing
to ignore until you know why you want it.

Dustin