9:01 a.m.
Hello,
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]
I want to have enough space on required partitions but not waste space on infrequently
modified filesystems where add-on packages will probably not go.
I'd like to get an idea what other folks are doing in terms of disk layouts. What are
the best practices?
Ron
--
Global System Services Corporation (GSS)
650 Castro Street, Suite 120, Number 268, Mountain View, CA 94041, USA
+1 (650) 965-8669 phone, +1 (650) 965-8679 fax, +1 (650) 283-5241 mobile
rherardi(a)gssnet.com, http://www.gssnet.com
"The best way to predict your future is to create it." - Stephen Covey
9:28 a.m.
Ron Herardian wrote:
Hello,
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]
I want to have enough space on required partitions but not waste space on infrequently
modified filesystems where add-on packages will probably not go.
I'd like to get an idea what other folks are doing in terms of disk layouts. What are
the best practices?
Ron
My only real comment is on the swap allocation.. I think the 2 X RAM is
old school thinking from back in the day when RAM was expensive and a
highend server had 128MB of it.. If your system ever needs to used more
than about 128 - 256MB of swap space then you seriously need to a) add
more RAM or b) offload some of the services on the server to another..
But thats just my opinion..
Also I would probably allocate a bit more to /var depending on how much
loging you plan to do and how long you plan to keep the logs, also how
big you expect you mail queue and users mail inbox's to be since they
are also usually in /var..
later..
10:26 a.m.
New subject: Swap size (was: Disk Layout/Partitioning Practices)
On Wed, Jan 28, 2004 at 03:28:19PM +0000, WipeOut wrote:
My only real comment is on the swap allocation.. I think the 2 X RAM
is
old school thinking from back in the day when RAM was expensive and a
highend server had 128MB of it.. If your system ever needs to used more
than about 128 - 256MB of swap space then you seriously need to a) add
more RAM or b) offload some of the services on the server to another..
Actually, the whole swap story is a strange one as far as I've seen
it... In the time of kernel 2.0.x, it was indeed advised to have 2xRAM
as a minimum, just for the reasons you mentioned. Later, with 2.2.x,
most people agreed that "RAM+swap" should just be enough to cater for
the maximum of memory usage you expect to see, ever. That's when I
switched to 1xRAM.
However, then 2.4.x came and suddenly, everybody suggested 2xRAM again.
I remember reading about it and there was some reasoning behind it, but
I don't know the details. If someone can shed some light on this, I'd
appreciate it.
Cheerio,
Thomas
--
===> Netiquette - read it, use it: http://www.faqs.org/rfcs/rfc1855.html <===
-----------------------------------------------------------------------------
Thomas Ribbrock http://www.ribbrock.org
"You have to live on the edge of reality - to make your dreams come true!"
10:37 a.m.
New subject: Swap size (was: Disk Layout/Partitioning Practices)
On Wed, Jan 28, 2004 at 05:26:30PM +0100, T. Ribbrock wrote:
However, then 2.4.x came and suddenly, everybody suggested 2xRAM
again.
That was only true for a short time in the early 2.4s, something about
the kernel wanting to collect stuff on speculation up to that level.
The VM has changed a lot since then.
-kb
5:06 p.m.
New subject: Swap size (was: Disk Layout/Partitioning Practices)
On Wed, Jan 28, 2004 at 11:37:47AM -0500, Kent Borg wrote:
[swap for 2.4.x = 2xRAM?]
That was only true for a short time in the early 2.4s, something
about
the kernel wanting to collect stuff on speculation up to that level.
The VM has changed a lot since then.
Ah! Well, that's enlightening, thanks!
Cheerio,
Thomas
--
===> Netiquette - read it, use it: http://www.faqs.org/rfcs/rfc1855.html <===
-----------------------------------------------------------------------------
Thomas Ribbrock http://www.ribbrock.org
"You have to live on the edge of reality - to make your dreams come true!"
10:48 a.m.
New subject: Swap size
T. Ribbrock wrote:
On Wed, Jan 28, 2004 at 03:28:19PM +0000, WipeOut wrote:
>My only real comment is on the swap allocation.. I think the 2 X RAM is
>old school thinking from back in the day when RAM was expensive and a
>highend server had 128MB of it.. If your system ever needs to used more
>than about 128 - 256MB of swap space then you seriously need to a) add
>more RAM or b) offload some of the services on the server to another..
>
>
Actually, the whole swap story is a strange one as far as I've seen
it... In the time of kernel 2.0.x, it was indeed advised to have 2xRAM
as a minimum, just for the reasons you mentioned. Later, with 2.2.x,
most people agreed that "RAM+swap" should just be enough to cater for
the maximum of memory usage you expect to see, ever. That's when I
switched to 1xRAM.
However, then 2.4.x came and suddenly, everybody suggested 2xRAM again.
I remember reading about it and there was some reasoning behind it, but
I don't know the details. If someone can shed some light on this, I'd
appreciate it.
That is interesting.. I still think its more of a guideline.. Think of
the following senario..
Server with 2GB of RAM, using the 2x RAM rule would mean 4GB of swap
space.. To my mind this means the server would have to address 6GB or
memory and so would probably need , I asume, the "bigmem" kernel in
order to manage the RAM properly and from what I have read the "bigmem"
kernel has an overhead to system performance of about 6-10%.. Add to
that the "slowness" of hard drives it really does not sit well with me..
There probably is no "correct" answer I think its would be up to the
Admin for the most part as to how the system needed to run.. Pesonally I
would rather have my system working out of RAM than having hundreds or
thousands of MB of "slow memory".. :)
later..
9:44 a.m.
On Wednesday 28 Jan 2004 3:01 pm, Ron Herardian wrote:
Hello,
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]
I want to have enough space on required partitions but not waste space on
infrequently modified filesystems where add-on packages will probably not
go.
I'd like to get an idea what other folks are doing in terms of disk
layouts. What are the best practices?
Ron
This is something that I have considered a lot, since I first started using
Unix back in 1985. It very much depends on what you are using the system for
and how much disk space is available. Generally, you should not let
filesystems get more than about 75% full because performance can start to
tail off. I use 2.5x physical RAM for swap and have multiple swap partitions
for good measure.
My layout is
/ 1GB
/boot 256 MB
/tmp 4 GB
/usr 8 GB
/usr/local 8GB (aka /opt)
/usr/src 16GB
/var 8GB
/home 52 GB
Never, underestimate how much disk space users use. My 52GB /home has 18GB of
data stored on it by 1 user (me). I would recommend allowing at least 16GB
per user nowadays. I also link /var/tmp/ -> /tmp so all the true temporary
areas are using storage in one place (/usr/tmp is already linked to
/var/tmp). What you are trying to avoid is a rogue hog (process) from
filling either /usr or /var thus causing instabilities in your system.
Hope this helps, I have based my current system design on years of
experience, (and no decent LVM, not like AIX anyhow) probably not valid
nowadays but old habits ... and having 2x80GB RAID-1 disks helps.
The real question you have to answer is what is a good backup/recovery
strategy for your system. Disks may be more reliable nowadays but this still
break when you least expect !
--
Alan D
9:50 a.m.
Alan Dunkley wrote:
..{snip}..
Hope this helps, I have based my current system design on years of
experience, (and no decent LVM, not like AIX anyhow) probably not valid
nowadays but old habits ... and having 2x80GB RAID-1 disks helps.
I was considering using LVM on my next server.. I would be interested to
hear what issues do you have with the current implimentation of LVM on
Linix..
10:06 a.m.
On Wednesday 28 Jan 2004 3:50 pm, WipeOut wrote:
Alan Dunkley wrote:
>..{snip}..
>
>Hope this helps, I have based my current system design on years of
>experience, (and no decent LVM, not like AIX anyhow) probably not valid
>nowadays but old habits ... and having 2x80GB RAID-1 disks helps.
I was considering using LVM on my next server.. I would be interested to
hear what issues do you have with the current implimentation of LVM on
Linix..
I have not looked at LVM for a while, so my feelings about LVM may be out of
date, but you cannot boot off a LVM partition. I dont know whether LVM2/2.6
addresses this or not. The other issue is that not all filesystems are
growable, no point growing a LV if the filesystem is static.
Hope this clarifies it.
--
Alan D
9:59 a.m.
Alan Dunkley wrote:
2x80GB RAID-1 disks
How? I tried SuSE, Fedora, Lindows & Mandrake, and couldn't find out how
to install to RAID1. All I could find said this is only possible via
software, creating a major chicken & egg situation that is complicated
by having windoze already installed using the motherboard "hardware"
RAID.
--
"The object and practice of liberty lies in the limitation of
governmental power." General Douglas MacArthur
Team OS/2 ** Reg. Linux User #211409
Felix Miata *** http://members.ij.net/mrmazda/
10:09 a.m.
On Wednesday 28 Jan 2004 3:59 pm, Felix Miata wrote:
Alan Dunkley wrote:
> 2x80GB RAID-1 disks
How? I tried SuSE, Fedora, Lindows & Mandrake, and couldn't find out how
to install to RAID1. All I could find said this is only possible via
software, creating a major chicken & egg situation that is complicated
by having windoze already installed using the motherboard "hardware"
RAID.
--
"The object and practice of liberty lies in the limitation of
governmental power." General Douglas MacArthur
Team OS/2 ** Reg. Linux User #211409
Felix Miata *** http://members.ij.net/mrmazda/
Sorry,
Should of said software RAID-1, I have never got hardware raid to work, did
not see my promise raid controller chip. Software raid works fine for me
without any major performance hits, once the raid is built.
--
Alan D
10:40 a.m.
On Wed, Jan 28, 2004 at 04:09:44PM +0000, Alan Dunkley wrote:
Software raid works fine for me
Software raid 1 is also bootable. Each mirror, though part of a raid
1 array, also looks like a regualr partition, so the boot loader can
use it just fine.
Raid 1 is also faster for reading than a single disk, and no slower
for writing. (Assuming you put your disks on separate IDE controllers
so reads and writes cna be dispatched to each disk in parallel.)
-kb
10:14 a.m.
Felix Miata wrote:
Alan Dunkley wrote:
>2x80GB RAID-1 disks
>
>
How? I tried SuSE, Fedora, Lindows & Mandrake, and couldn't find out how
to install to RAID1. All I could find said this is only possible via
software, creating a major chicken & egg situation that is complicated
by having windoze already installed using the motherboard "hardware"
RAID.
There is nothing wrong with Linux software RAID, in fact it does have
some strong advantages.. But I am not going to fire up that debate again..
If you are refering to the Promise or similar ATA RAID controllers these
are also *software* RAID since most of the RAID finctionality is
performed by the driver not the card.. The only exception to this that I
know of so far is the 3ware ATA RAID cards which are true hardware RAID
controllers, and the driver is included in Linux as well so installation
is a breeze..
later..
10:34 a.m.
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.
11:45 a.m.
On Wed, Jan 28, 2004 at 11:34:19AM -0500, Kent Borg wrote:
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.
This is a good place to start unless you have experience otherwise.
Put a lot of physical RAM in your machine, certainly.
Yes, Yes, Yes... DRAM....
Remember that Linux supports swap to files. If you need more swap space
for a project you can add swap files at a later time.
You do want enough DRAM + swap to permit your largest processes to do
common things like "fork(); exec()" and not have the kernel return
errors for want of virtual resources.
Today DRAM is inexpensive and "disk-speed to DRAM-speed" ratios so
large that you do not want much if any swap IO. With modern VM
systems and concepts like shared pages, copy on write etc... the key
value for a 'big' swap is kernel book keeping. The kernel must
believe that it has has enough backing store in case you "touch"
the pages the process requested.
I happen to like testing various bounds and limits so my swap space is
big. Big enough for two run away big processes (~6GB). In practice
this is way too large and when swapping the box is worthless for
interactive work.
The classic 2xDRAM, 4xDRAM, 8xRAM swap rules had a lot to do with the
balance of DRAM cost (expensive) to disk cost to system usefulness.
Today time slices are very short. When time slices are compared to
disk access time extensive swap IO does not make sense. When the
effective runtime for a set of pages is larger than the disk IO time
and overhead it can make sense. See stuff like job control, Ctl-Z
stop, checkpoint and restart. On an interactive workstation swap IO
does not make much sense.
--
T o m M i t c h e l l
mitch48-at-sbcglobal-dot-net
11:37 a.m.
On Wednesday 28 January 2004 07:01 am, Ron Herardian wrote:
Hello,
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]
I want to have enough space on required partitions but not waste
space on infrequently modified filesystems where add-on packages
will probably not go.
I'd like to get an idea what other folks are doing in terms of disk
layouts. What are the best practices?
Ron
4GB /usr might be a little tight, depending on what you like to
install. I'm sitting on a 5GB /usr right now, but I have a lot of
stuff in /usr/local and I don't use /opt.
Regards,
John
12:27 p.m.
On Wed, 2004-01-28 at 10:01, 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]
I want to have enough space on required partitions but not waste space
on infrequently modified filesystems where add-on packages will
probably not go.
I'd like to get an idea what other folks are doing in terms of disk
layouts. What are the best practices?
FWIW, this is my general server guideline layout...
/boot = 100M
/ = 500M
/home = Varies depending on the ratio of users to total drive space
/opt = Between 1G and 5G depending on what you're installing
/usr = 2G
/usr/local = Between 1G and 2G
/var = 2G
/var/spool = 2G to 5G depending on potential mail usage
--
Akebono vs Godzilla! Coming soon to a theater near you.
10:15 a.m.
On Wednesday 28 January 2004 16:01, Ron Herardian wrote:
Hello,
When installing everything and allowing for future updates and packages I
am using the following disk layout:
Mount Point Size
/boot 100MB
I really wonder why people still use /boot partitions when they have
a small
root (/) partition.
My prefered layout is
/ 500M
/2 500M (alternate root for testing/upgrading)
everything else on LVM
/usr 5-6G
/var 1G
/tmp 1G
/home - what one needs
/opt
/usr/local - if you use it much
--
ronny
10:53 a.m.
Ronny Buchmann wrote:
On Wednesday 28 January 2004 16:01, Ron Herardian wrote:
>Hello,
>
>When installing everything and allowing for future updates and packages I
>am using the following disk layout:
>
> Mount Point Size
> /boot 100MB
>
>
I really wonder why people still use /boot partitions when they have a small
root (/) partition.
My prefered layout is
/ 500M
/2 500M (alternate root for testing/upgrading)
everything else on LVM
/usr 5-6G
/var 1G
/tmp 1G
/home - what one needs
/opt
/usr/local - if you use it much
Thats actually not a bad idea.. In fact I may actually use it.. :)
Later..
7429
days inactive
7432
days old
18 comments
10 participants
participants (10)
-
Alan Dunkley -
Felix Miata -
Joe Klemmer -
John Wendel -
Kent Borg -
Ron Herardian -
Ronny Buchmann -
T. Ribbrock -
Tom Mitchell -
WipeOut