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

[Adam Tauno Williams]

On Fri, 2012-03-02 at 09:42 -0500, Mark Montague wrote:
> 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,

Nope, it makes it far *MORE* flexible.  If by chopping we mean logical
volumes and not "partitions".

>  and you run the risk of running out of space on one partition 
> while having plenty of space left on other partitions.

Don't over provision.  Allocate what you need.  You can grow the volumes
later if you need to.

> 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.

Why I love "chattr +i ...".  Even with sudo he can't do that.

> "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.

Unless you mount read-only or use "chattr +i ..."