centos - How bad is it really to install Linux on one big partition?

itemprop="text">

We will be running CentOS 7 on our new
server. We have 6 x 300GB drives in raid6 internal to the server. (Storage is largely
external in the form of a 40TB raid box.) The internal volume comes to about 1.3TB if
formatted as a single volume. Our sysadmin thinks it is a really bad idea to install the
OS on one big 1.3TB partition.

I am a
biologist. We constantly install new software to run and test, most of which lands in
/usr/local. However, because we have about 12 non-computer savvy biologists using the
system, we also collect a lot cruft in /home as well. Our last server had a 200GB
partition for /, and after 2.5 years it was 90% full. I don't want that to happen again,
but I also don't want to go against expert
advice!

How can we best use the 1.3TB available
to make sure that space is available when and where it's needed but not create a
maintenance nightmare for the sysadmin??

class="post-text" itemprop="text">

class="normal">Answer

The
primary (historical) reasons for partitioning are:

• to
  separate the operating system from your user and application
  data. Until the release of RHEL 7 there was no supported
  upgrade path and a major version upgrade would require a
  re-install and then having for instance /home and other
  (application) data on separate partitions (or LVM volumes) allows you to easily preserve
  the user data and application data and wipe the OS partition(s).
  




• Users can't log in properly and your
  system starts to fail in interesting ways when you completely run out of disk space.
  Multiple partitions allow you to assign hard reserved disk space for the OS and keep
  that separate from the area's where users and/or specific applications are allowed to
  write (eg /home /tmp/ /var/tmp/ /var/spool/ /oradata/ etc.) ,
  mitigating operational risk of badly behaved users and/or
  applications.
  





• Quota.
  Disk quota allow the administrator to prevent an individual user of using up all
  available space, disrupting service to all other users of the system. Individual disk
  quota is assigned per file system, so a single partition and thus a single file-system
  means only 1 disk quotum. Multiple (LVM) partitions means multiple file-systems allowing
  for more granular quota management. Depending on you usage scenario you may want for
  instance allow each user 10 GB in their home directory, 2TB in the /data directory on
  the external storage array and set up a large shared scratch area where anyone can dump
  datasets too large for their home directory and where the policy becomes "full is full"
  but when that happens nothing breaks either.
  




• Providing dedicated IO
  paths. You may have a combination of SSD's and spinning disks and would
  do well to address them differently. Not so much an issue in a general purpose server,
  but quite common in database setups is to also assign certain spindles (disks) to
  different purposes to prevent IO contention, e.g. seperate disk for the transaction
  logs, separate disks for actual database data and separate disks for temp space.
  .




• Boot
  You may have a need for a separate /boot partition.
  Historically to address BIOS problems with booting beyond the 1024 cylinder limit,
  nowadays more often a requirement to support encrypted volumes, to support certain RAID
  controllers, HBA's that don't support booting from SAN or file-systems not immediately
  supported by the installer etc.
  




• Tuning
  You may have a need for different tuning options or even completely different
  file-systems.
  

If you use
hard partitions you more or less have to get it right at install time and then a single
large partition isn't the worst, but it does come with some of the restrictions above.

Typically I recommend to partition your main
volume as a single large Linux LVM physical volume and then
create logical volumes that fit your current needs and for
the remainder of your disk space, leave unassigned until
needed.

You can than
expand those volumes and their file-systems as needed (which is a trivial operation that
can be done on a live system), or create additional ones as well.

Shrinking LVM volumes is trivial but often
shrinking the file-systems on them is not supported very well and
should probably be avoided.