[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Oh no, not partitioning again!

on 20:32 Thu 03 Feb, PMA (PeterArmstrong@aya.yale.edu) wrote:
> Hi List.
> I plan to install Squeeze pretty soon, and am reviewing
> my old decisions re disk partitioning.  I will mainly resize
> proportionally to my 'df -k' output's Used column.
> But two items puzzle me:
> /srv	I gather this is important to have, but I have yet
>          to find anything *in* it.  Will Squeeze put stuff in
>          there if I haven't expressly told it too?

Possibly.  I've got a /srv/cvs under there, and I couldn't swear how it
got there.  Debian Policy will tell you what the rules are.  It
references FHS, which states:


    This main purpose of specifying this is so that users may find the
    location of the data files for particular service, and so that
    services which require a single tree for readonly data, writable
    data and scripts (such as cgi scripts) can be reasonably placed.
    Data that is only of interest to a specific user should go in that
    users' home directory.

    The methodology used to name subdirectories of /srv is unspecified
    as there is currently no consensus on how this should be done. One
    method for structuring data under /srv is by protocol, eg. ftp,
    rsync, www, and cvs. On large systems it can be useful to structure
    /srv by administrative context, such as /srv/physics/www,
    /srv/compsci/cvs, etc. This setup will differ from host to host.
    Therefore, no program should rely on a specific subdirectory
    structure of /srv existing or data necessarily being stored in /srv.
    However /srv should always exist on FHS compliant systems and should
    be used as the default location for such data.

    Distributions must take care not to remove locally placed files in
    these directories without administrator permission. 

So:  yes, Debian packages may create directories here.  But not remove
files (without prompting).

As with otehr FHS constructs:  the _filesystem_ path must exist, but how
you map this onto your storage is up to you.  You could use a symlink,
union mount, or mount additions / external storage here.

On personal systems I generally symlink /srv and /opt to similarly named
directories under /usr/local/.

On production systems, I may do the same, or map these to dedicated
storage where requirements dictate.

> /tmp  As a rule of thumb -- i.e., special considerations
>          notwithstanding -- what do you think of making
>          this the same size as /var?

About 1-2 GB, possibly as tmpfs.

/var on should generally be at least 3-4 GB if allocated separately.
That's just for package archives and ordinary system state.  If you've
got additional storage (mail spools, databases, etc.), you'll want to
increase provisioning.

I try to stay on top of actual system usage, prefer separating
partitions, and find myself getting bitten.  I'm now suggesting about 1
GB for a separate root partition (independent of /usr /var /tmp /home
and /usr/local), and 10-12 GB for /usr.  For root, it's the
proliferation of kernel modules, and the need to be able to have at
storage for at least 2 (and more likely 3-4) kernel + module trees.  For
/usr, it's the internationalization and language support for packages.
/usr/share and /usr/lib/ run over 2.5 GB apiece, and that's _with_
localepurge installed.

Dr. Ed Morbius
Chief Scientist
Krell Power Systems Unlimited

Reply to: