Particionar 80 Gb para mailserver?

[Germán Poó-Caamaño]

On Wed, 2008-02-06 at 01:57 -0300, Aldrin Martoq wrote:
> On Tue, 2008-02-05 at 22:50 -0300, Germán Poó-Caamaño wrote:
> > On Tue, 2008-02-05 at 20:40 -0300, Aldrin Martoq wrote:
> > > De mi experiencia, estoy en contra de "sobre-particionar" cualquier
> > > instalación. / y /usr/bin y /boot no tiene mucho sentido separarlas.
> > > Además, tengo la sensación que LVM es algo lento (fueron unas pruebas
> > > rápidas, no tengo números).
> > > 
> > > Mi recomendación es la siguiente:
> > > / 5-10GB para S.O. (incluye /boot /bin /usr /etc /lib ... de sobra)
> > > /tmp es buena idea separarlo (en particular si los usuarios acceden la
> > > máquina), pero no estrictamente necesario... te recomiendo 5GB si lo
> > > separas, o sumalos a / con 15GB en total
> > > /var 65 GB (lo que sobra) Ahi tendras la base de datos y el correo.
> > En estas situaciones /tmp *debe* estar separado.  Es mejor que se
> > llene /tmp a quedarse sin espacio en /.  Además que lo que está en
> > /usr, /lib, /etc, /bin y /boot suelen ser contenido estáticos; mientras
> > que /tmp es altamente dinámico.
> 
> Esto es parte del "folklore y mitos" heredados de tiempos antigüos y
> oscuros. Es como el clásico swap = 2*RAM o calcular el tamaño de una
> máquina en SUMx*30%. Hoy en día la situación es MUY diferente.

Es mucho más fácil visualmente un df que te indique qué se está 
llenando.

> Hagan la prueba. Llena / como usuario y como root (si usas ext3). Podrás
> ingresar al sistema sin problemas y resolver la situación. Si, digamos,
> el software de webmail no funciona porque se llenó /tmp da lo mismo si
> esta en otra partición o en /: igual no va a funcionar en *ambas
> situaciones*, asi que pierdes ese servicio igual.

Eso es por la reserva de espacio del fs, que realmente nunca está
lleno.

> [...]
> > > Si deseas, puedes poner /var en LVM para futuros "agrandamientos"... /
> > > no es necesario, 10 GB es suficiente.
> > En un servidor de correo, debiera estar separado /var de 
> > /var/donde/se/alojan/los/buzones.  Por ejemplo, /var/mail (para un
> > sistama tradicional como wu-imap, /var/spool/cyrus
> > 
> > Así tienes control del espacio que
> > ocupan los buzones, respecto de /var/tmp, /var/log, /var/cache, etc.
> > Sería lamentable que los usuarios no pudieran recibir correos porque
> > un archivo de logs creció demasiado.
> > 
> > /var/spool no es necesario que vaya aparte, nunca crece tanto. A menos
> > que se vayan a quedar sin Internet por un mes y la gente siga enviando
> > correos hacia el exterior.  En el sentido inverso, los mensajes suelen
> > despacharse rápidamente.
> > 
> > Dado que quiera instalar MySQL, desconozco donde CentOS crea las
> > bases de datos para MySQL, pero si fuera en /var/lib; tal vez se
> > deba considerar si vale la pena una partición individual para
> > /var/lib.  No creo que vaya a ocupar mucho espacio en todo caso.
> 
> Siento lo mismo que la respuesta de arriba... Si no puedes
> escribir /var/log, de todas formas estás mal. Para el caso del correo,
> no podrás recibir pero el host que envía se queda esperando un par de
> días o el correo rebota. Para el caso de enviar, chilla altiro... Si
> quieres "controlar" el espacio de los correos, primero declara políticas
> de buen uso. Es mejor educar (lo dices un par de veces a todos tus
> usuarios) que estar jugando al paco y al ladrón (cada vez que alguien
> rompla la regla de cuota de disco, te preguntaran las N veces que pase
> "por qué no puedo recibir correo???").

Nuevamente, un df te indica fácilmente si el problema es el crecimiento
de logs o el crecimiento del volumen de correo.  Se puede determinar con
du si lo haces todo junto; pero estar recorriendo todo el sistema de 
archivos para un dato que se soluciona trivialmente con particiones 
separadas, no me parece 'más fácil administrativamente'.

> Insisto en la idea que es más fácil administrativamente unir los
> espacios (particiones) que separarlos ya que todos los huecos libres se
> aprovechan mejor y el sistema tiende menos a caerse porque se llenó un
> sistema de archivos, sobre todo cuando no cuentas con un "gran" espacio.

Lo mismo indico, administrativamente es más fácil un df. Sabes de
inmediato como va todo, el espacio requerido para un respaldo completo.
Y al momento de solucionar (o intentar) sabes directamente adonde debes
ir.

> O viéndolo al reves: cuando tiendes a "sobre-particionar" son mas
> ocurrentes los problemas de discos al tope o casi llenos, usualmente
> porque no pudiste adivinar el espacio que realmente requerían.

En eso te ayuda LVM.  Además, tener 4 particiones
(/, /tmp, /var, /var/mail) no me parece sobreparticionado.

-- 
Germán Poó-Caamaño
Concepción - Chile
http://www.calcifer.org/