Mainly the concern was one regarding /var being filled because of errant
emails that could fill the root partition, besides other issues listed below.
For the newer OS ie Solaris 2.5.1 and newer harddrives in my opinion (only)
it seems that freehogging a disk has many advantages . I'd freehog the
first disk0 and add another harddrive for the user files (on the server) --
disk1.
Conclusion (with standard disclaimer): There is no major technical
disadvantage in freehogging a harddrive in Solaris 2.5.1. Configure the
system as your work environment requires you to do, and makes it easier for
you to administer it, given the resources at hand.
Advantages:
The entire disk is available, you don't have to worry
about individual partitions filling up. It's easy to administer.
There's no need to worry about all those pesky partitions.
Definitely the most efficient use of disk space.
All free space on the disk is in one partition, so it's available
to /, /var, /opt, /usr, etc.. (Avoid problem of free space in
/usr when you need it in /opt.)
Simple to set up.
Makes it easy to set up backups/disk clones, albeit not that
much easier.
It's what I prefer to do (single partition). It means you can't set
different quotas for different partitions. Your backup device should
be big enough to handle the entire partition. If /var/mail is on the
same partition as user files then huge emails or log files can affect
system usability (run out of space).
I'm setting up a 2Gb disk with 512Mb swap space and the rest as /.
Disadvantages:
If you need to reload the OS, you'll have to backup any
non-OS directories, add-on software, etc. With separtate
partitions, you can set up partitions that only contain
user directories for example, and just preserve the partitions.
Another disadvantage is, if you need to share a directory
across NFS, you'll have to share the whole / partition.
This could definitely cause security problems.
Disadvantages are lack of ability to control free space in a particular
partition, and in a multiple disk system, lack of spindle control, i.e.
the ability to distribute disk usage to multiple disks. Lack of ability
to control out of control logging situation in /var are probably the most
dangerous...of course, having a huge amount of free space in /var tends
to give you more time to scream in that situation as well.
If any filesystem is corrupted, they're all corrupted, since
you've combined them all into one.
Doesn't allow you to spread out activity over multiple disks;
under SunOS, I always split / and /usr, at least, and preferred
to split out /var and /usr/local as well. Under Solaris,
I usually put /, /usr, /opt, and /var on as many different
disks as possible to load-balance.
The downside to this disk set up is, should you encounter serious
disk probelms, you will have a very hard time recovering from them.
I like slicing up the drive so that when FSCK finds a problem I won't
lose my whole drive.
The biggest advantage is that you don't waste a lot of space on partitions
that may or may not need them.
One big problem with breaking up your OS into several partitions such that
/
/usr
/var
/opt ... etc, are on separate partitions, is how much space to allocate
to each. You not only need to leave room for your current installation,
but also for patches, upgrades, and software.
What if you allocate 100 MB to /opt and then later you find you really
needed it to be 130 MB. Or you allocated 100 MB for /usr and then you find
you need to add patches to the system and can't.
Here is an example of what not to do:
Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c0t3d0s0 15135 11693 1932 86% /
/dev/dsk/c0t3d0s6 97463 77413 10310 88% /usr
/proc 0 0 0 0% /proc
fd 0 0 0 0% /dev/fd
/dev/dsk/c0t3d0s4 106047 5818 89629 6% /var
swap 111812 13820 97992 12% /tmp
/dev/dsk/c0t3d0s7 424759 197757 184532 52% /export/home
/dev/dsk/c0t3d0s5 166655 88437 61558 59% /opt
/dev/dsk/c0t3d0s3 121215 94759 14336 87% /usr/openwin
This is a Solaris 2.4 system. There isn't enough disk space on / or /usr
to upgrade the Jumbo patch to the latest rev. Yet there is approx 90 MB
free on /var and that is not likely to get used up quickly. Also,
upgrading to 2.5.1 is probably not going to work with these partition sizes.
Here is another 2.4 system:
Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c0t3d0s0 932350 363186 475934 43% /
/proc 0 0 0 0% /proc
fd 0 0 0 0% /dev/fd
swap 39928 200 39728 1% /tmp
It runs very well this way. The only potential drawback is, if someone
fills up the filesystem by placing files in their home directory, they can
fill up the root and /var filesystems. It is difficult to login to a
system with /var at 100% capacity, since the system won't be able to write
to /var/adm/wtmp.
Besides limitations on the number of INODES in a single partition,
depending on the size of the disk, it would simply be a waste of space.
For all intents and purposes, the / directory should contain the boot
image and the mount points for all other directories. That should take
very little space overall.
Building a well-planned directory hierarchy makes it easier to manage
the disk.
Suvrit
mailto:varshney@pacbell.net