DISK SLICES
-----------One important consideration is the allocation of disk slices. It's
certainly possible to install a system with a single partition mounted
on /. However, this can cause all sorts of problems. There are good
reasons to split up your disk, and I'll mention a few of them here. First, the root partition. This partition is critical to booting the
system. If the root partition cannot be mounted read-only
successfully, the system will simply hang. I haven't intentionally
sabotaged a Solaris 8 machine to find out what the exact behavior, but
in 2.6 it would just stop without even issuing any sort of message.
To fix this, you need to get physical access to the machine and boot
off another disk, cdrom, or the network and fsck the root partition. Because you never want this to happen, you should make sure that
nothing which receives frequent updates is on the root partition. If
you do not create an /opt slice, you should probably move /opt to /usr
and set up a symbolic link. When you edit files on /etc, you should
sync to help make sure the file system will not be left in an
inconsistent state if the machine experiences an abnormal shutdown. I generally make my root slices about 120MB. That's larger than they
need to be, but it never hurts to have a little extra room. If you're
setting up a system that has a lot of disk space, or one that can
never be taken down for maintenance, you might want to make it even
larger. In order for the root partition to be fscked and remounted read-write, the
system needs to be able to run fsck. Generally this isn't a problem, but
because of the way some of the system binaries are installed, it can be.
Let's take a look at /sbin/fsck... ls: /sbin/fsck: cannot open file: No such file or directory GAK! It's not there. It's actually in /usr/sbin/fsck, which means
that Solaris needs to mount /usr before it can fsck the root
partition. Now, /usr is the sort of partition that's likely to get
updated a lot, and therefore is likely to not mount cleanly during
boot. This means that if /usr won't mount, not only can Solaris not
fsck the root partition, it can't even fsck /usr to clean it up enough
to mount it read-only. <rant>
So, what can we do? My first thought was to put fsck in /sbin and
modify the boot scripts to call it from there during boot. If /usr
failed to mount correctly, we could fsck it and try again. It sounded
like a great idea, but take a look at this: mankind:~ % ldd /usr/sbin/fsck
libdl.so.1 => /lib/libdl.so.1
libc.so.1 => /lib/libc.so.1
/usr/platform/SUNW,Ultra-2/lib/libc_psr.so.1 fsck, and indeed most of /usr/sbin and /sbin, is not actually a static
binary. We could certainly copy those libraries into the root as
well, but fsck just calls /usr/lib/fs/ufs/fsck. mankind:~ % ldd /usr/lib/fs/ufs/fsck
libc2.so => /lib/libc2.so
libadm.so.1 => /lib/libadm.so.1
libc.so.1 => /lib/libc.so.1
libelf.so.1 => /lib/libelf.so.1
libdl.so.1 => /lib/libdl.so.1
/usr/platform/SUNW,Ultra-2/lib/libc_psr.so.1 At this point, I gave up. I swear that at some point I'll work out
exactly what I need to do to make the Solaris boot process more
reliable. When I do, I'll include a nice script here to patch the
boot scripts and move the necessary files into the root. Until then,
do be careful that you don't leave /usr in a dirty state very often.
You might want to make /usr/local a seperate partition if you install
things there often. In case someone from Sun is reading this and wants to take up the
challenge of fixing this nonsense, I'll include my thoughts on how
this SHOULD be done.] In my mind, the most effective thing for Sun to
do would be to set up a /boot partition with the kernel and all the
static binaries needed to bring the system up. This partition would
only be mounted read-only during normal system operation, and would be
mounted read-write only long enough to make changes to software and
configuration files installed there. This can't really be the root
partition itself, because /etc needs to be modified frequently. Once the software on /boot has insured that / and /usr are clean, the
boot could proceed more or less as it does now. This actually
requires mounting /boot as a dummy root and then mounting the real
root once it has finished it's work. I think the benefit of would be
immense, however. I can't count how many times I've had to drive to a
colo facility at 2am to fsck / or /usr and reboot a machine. The idea
that a rather stable system like Solaris can be so easily crippled and
rendered unbootable by a simple power failure is frustrating, and a
little embarassing.
</rant> The risk of instability during the boot process is nearly eliminated
if you enable logging on your file systems. This is discussed in the
section on /etc/vfstab below. This doesn't excuse Sun's poor
planning, but it can prevent it from causing problems for you. The /usr partition itself should probably be fairly large. Solaris
itself installs a lot here. If you do not have a large disk, you may
wish to make a very large /usr, let /usr/local live on it, and symlink
/home to /usr/home. This makes the most space available to both
/usr/local and /home, though it sacrifices some security and
stability. I build all of my new software in /usr/local, which I make a separate
partition when possible. This means that you can reinstall the OS
(letting it format /usr) without destroying everything you've built in
/usr/local. It also means that if you're really paranoid you can
mount /usr read-only, and possibly mount /usr/local nosuid. I generally symlink /opt to /usr/opt and let /opt-style packages
install themselves there. Trying to guess ahead of time how much of
your software will go in /usr and how much in /opt is frustrating and
rarely yields good results. Most of you have probably heard the old recommendation that your swap
should be at least twice the size of your physical memory. I'm not
going to explain why that rule of thumb made sense, but it's really
not that cut and dry. There are many things to take into
consideration, including the type of software running on the system,
the number of different programs running on the system, and the
physical memory in the system. Personally, I tend to provide between
one and two gigabytes of swap. For certain applications I might make
swap a few times larger than that. A few commonly suggested guidelines are:
0.5 * physical RAM over 1GB
2 * Oracle SGA, if running oracle
I also like to make sure that the physical ram + swap is at least 2GB,
even for a workstation. The /var partition is quite important. Your logs go in /var/log, and
some temporary files are stored in /var/tmp. This makes a root
mounting failure more likely than not after a power loss or kernel
panic. Also, because your logs go here and you don't want to risk
losing log data, you should make this fairly large. I generally make
/var 200-400MB, depending on the log volume the system will generate. If you have sufficient slices available, you may wish to make /var,
/var/log, and /var/tmp all separate. This protects /var/log from
being filled by bogus additions to /var/tmp. /var still needs to be
separate from / in this case because it is updated so frequently by
running applications. If you wish to store your mail in /var/mail,
you will definitely want to have a dedicated slice for this, or
relocate it and replace it with a symlink (see below). The /export/home partition that, by default, consumes the remaining
portion of your disk is related to nfs exporting and the automounter.
Personally, I don't really care for the automounter unless I'm
building a whole NIS+/NFS network with a lot of workstations and
users. If you're installing a standalone server or workstation, you
probably want to kill this and make a normal home volume somewhere.
Because the automounter lives on /home by default, you'll have to kill
it to get access to a partition on /home (see below).
|
