Re: Oh no, not partitioning again!
on 20:32 Thu 03 Feb, PMA (peterarmstr...@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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110204075950.gj4...@altaira.krellpowersys.exo
Re: Oh no, not partitioning again!
On the 04/02/2011 02:54, Henrique de Moraes Holschuh wrote: On Thu, 03 Feb 2011, PMA wrote: [cut] /tmp As a rule of thumb -- i.e., special considerations notwithstanding -- what do you think of making this the same size as /var? I leave it on /, and ask the initscripts to mount a tmpfs of 1GB (or even less) on top. See attached file (/etc/default/tmpfs). Edit to fit your system and needs. Depends on the workload, If you do video editing of large files, or use application like Blender for large projects, you can end up with several GB's in /tmp very quickly, if space isn't available the application may freeze/crash and you don't want that in the middle of an editing session. Some cd/dvd burning applications can be using /tmp for large amount of data too, for instance when doing a backup/burn on the fly with only one dvd drive on the machine. With such workloads using a separate partition on a separate disk improves performances a lot, if you go the tmpfs way you'll need loads of ram. It's almost always possible to easily change the location of the temporary directory in the applications' preferences though. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d4bbb56.2050...@googlemail.com
Oh no, not partitioning again!
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: /srvI 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? /tmp As a rule of thumb -- i.e., special considerations notwithstanding -- what do you think of making this the same size as /var? Thanks in advance for your time! Regards, Pete -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d4b5737.4060...@aya.yale.edu
Re: Oh no, not partitioning again!
On Thu, 03 Feb 2011, PMA wrote: 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? No, it won't put stuff in there. /tmp As a rule of thumb -- i.e., special considerations notwithstanding -- what do you think of making this the same size as /var? I leave it on /, and ask the initscripts to mount a tmpfs of 1GB (or even less) on top. See attached file (/etc/default/tmpfs). Edit to fit your system and needs. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh # SHM_SIZE sets the maximum size (in bytes) that the /dev/shm tmpfs can use. # If this is not set then the size defaults to the value of TMPFS_SIZE # if that is set; otherwise to the kernel's default. # # The size will be rounded down to a multiple of the page size, 4096 bytes. SHM_SIZE=6G TMPFS_SIZE=1G RUN_SIZE=10M LOCK_SIZE=1M RW_SIZE=10M
Re: Oh no, not partitioning again!
On Thu, Feb 3, 2011 at 17:32, PMA peterarmstr...@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, Not really, unless you run a server and want to serve stuff from there. I use /srv for my file share, www space, git, etc. but I have yet to find anything *in* it. Will Squeeze put stuff in there if I haven't expressly told it too? Nope. /tmp As a rule of thumb -- i.e., special considerations notwithstanding -- what do you think of making this the same size as /var? That has worked out for me, but I usually have plenty of room. Cheers, Kelly Clowers -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktim3cxzawu4zl5dswsm3y40riug2zupb6jxwn...@mail.gmail.com
