Partitioning System Disk
When performing a new Unix OS installation you are usually presented with a choice of accepting the default partitioning layout or going into advanced settings and defining your own partitions. The default layout will normally create separate partitions for boot, swap and root. The root partition will include /, var, etc, usr, and opt directories.
In the old days of small hard drives it has been a standard operating procedure for many sysadmins to split up the root directory into several separate partitions, trying to keep /var, /etc, /usr, and sometimes /opt separate. The logic behind this was to avoid problems if the system disk runs out of space. For example, most software is installed in /usr and /opt and these two directories may cause your system to run out of disk space. If there is no space left in /var, the only way to login may be from the console in single-user mode. Additionally, /var/log is used by the OS as well as by various applications and all this logging activity may eat up all of your disk space even if log rotation is properly configured.
Modern hard drives offer hundreds of gigabytes of space, but it is still a good idea to split them up into several partitions when installing the OS. Doing so will minimize the change of a system-wide crash when bad blocks are encountered on the system hard drive. We recommend creating separate partitions for /, /etc, /usr, /var, /var/log, /opt, /boot, /home, and swap. With large modern hard drives you can allocate generous space to each filesystem, with the bulk of the space going into /usr, /home, /opt, and swap.
We further recommend placing /home and swap on a secondary disk, if available, to minimize the impact of swapping and user activity on the performance of your system. It is a good idea to export /var/log filesystem via NFS to another server. On the other server you can set up a synchronization process to regularly copy the contents of NFS-mounted /var/log to a local directory. If your system becomes unresponsive, you may still be able to access the NFS-mounted /var/log from the other server or view the local copy of the log file to figure out what is happening. The ability to view the log files (even if they are not entirely up to date) before attempting to bring up a downed server will prove very useful.
Below is a sample filesystem layout for a Solaris boot disk. In this example the server has 16Gb of RAM and uses two 146Gb disks (c0d0t0 and c1d0t0) – one for the OS and the other for swap and /home. If you have multiple disk controllers available, it is a good idea to put swap space and /home on the separate controller for best performance. Having swap space on a separate disk/controller will not make much difference if your system has plenty of RAM and swap activity is low. However, if you are short on RAM or if you are running memory-intensive applications and your swap I/O is high, you will see a significant performance improvement by moving the swap space off the system disk.
FS Size Partition ----------------------------------- / 10Gb c0t0d0s0 /var 10Gb c0t0d0s3 /var/adm 10Gb c0t0d0s4 /etc 5Gb c0t0d0s5 /opt 30Gb c0t0d0s6 /usr 70Gb c0t0d0s7 /home 100Gb c1t0d0s0 swap 32Gb c1t0d0s1
Back in the days of limited RAM the recommended swap size was twice the amount of installed memory. The example above shows 32Gb swap partition for a server with 16Gb of RAM. Generally, for systems with more than 8Gb of installed memory you can keep the swap just slightly larger than the amount of RAM you have. Another consideration is disk space availability for core dumps, which are very useful for analyzing OS and application problems. Your system needs to be configured to create a core dump in a filesystem that has at least enough space to accommodate your entire RAM. However, this should not be a filesystem critical to your server’s operation. Do not use /var, /, /etc, or /usr for core dumps.