[mdlug] What are the best practices for Linux partitioning & Mount points for Production systems

[Mark Montague]

On March 2, 2012 4:04 , nk oorda <nk.oorda at gmail.com> wrote:
> i need some suggestion for defining the partition size for my production
> systems.  we are going to use CentOS 6.2 (64 bit)
>
> - Partition size
> - Mount points

Generally, I prefer to not have "unnecessary" partitions since chopping 
up your disks into too many pieces can limit your flexibility in storing 
data, and you run the risk of running out of space on one partition 
while having plenty of space left on other partitions.  Since modern 
disks are big, modern data is big, disk and filesystem performance are 
high, and filesystem corruption is not a significant problem anymore 
like it was in the 1990s, I prefer to have a smaller number of larger 
partitions rather than a larger number of smaller ones.

Thus, I'll usually only create a separate partition for things that 
write a lot of data.  Having a separate partition for these things puts 
a limit on what the data-writer can write, and controls the amount of 
things it can affect if it writes a LOT of stuff.

So, for example, I always give /var a separate partition from the OS (/) 
so that log files or other things under /var won't cause / to run out of 
space.  If the machine is a web server or a database server then I'll 
also give /var/www or /var/lib/mysql their own partition, for the same 
reasons, and to keep them from interferring with the ability to write 
logs to /var

I'll only give /home its own partition if I have 
non-system-administrator users logging into the machine or if there is a 
service that has its program or data directories under /home.

I never give /usr its own partition any more -- this was valuable to do 
in the 1990s to isolate filesystem corruption on / from affecting /usr 
and vice-versa, which helped ensure that you'd be able to reboot into 
single user mode to do filesystem repairs, and that no single filesystem 
took "too long" to repair (with non-journaling filesystems, repair time 
could sometimes grow as the square of the size of the filesystem).  But 
with modern size disks, the efficiency of journaling filesystems 
(filesystem repair time is now often linear with filesystem size), and 
with filesystem corruption being much less common than it used to be, I 
find it to be more efficient in terms of disk space, more flexible, and 
simpler to have / and /usr share the same, large, partition.

> what is concern is that one of the developer accidentally deleted the /usr
> files with sudo access. if somehow i can protect the core system from the
> developers mistake that would be really good.

"sudo rm -rf /" will delete everything regardless of how you partition 
the disks.  rm (and most other things as well) are totally ignorant of 
filesystem boundaries.

The best solutions are either (1) don't give developers sudo access at 
all; (2) limit developer sudo access to only things that they need to do 
(e.g., running "service {stop,start,restart,graceful,status}" or running 
"chown" but only when the path begins with "/home/service-name"); or, 
(3) recognizing that people with sudo access will occasionally mess 
things up and put things in place to protect against those events, such 
as filesystem snapshots, or frequent backups from which you know you can 
quickly and reliably restore the entire system to its previous state.

--
   Mark Montague
   LSA Research Systems Group
   University of Michigan
   markmont at umich.edu