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:
http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
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: