RE: [suse-linux-s] Particiones para servidor
Hola :) [...]
He incluído /var/spool/mail porqué repasando el archuivo de la lista he visto que así lo recomendaban varios listeros a la hora de montar un mail server. ¿y eso exactamente porqué? Me tengo que poner la pilas con el tema mail...
Porque en principio se monta "sync", es decir, sin guardar los datos en memoria, para que en caso de problemas no se pierda correo. Más lento, y más seguro. Por contra, implica limitar el tamaño de los correos a algo razonable (un mega ya es mucho), so pena de cargar el sistema.
Las razones por las que debes montar distintos directorios sobre distintas particiones son: - como dice Carlos, puedes montar cada partición con diferentes opciones para diferente comportamiento/necesidad de cada servicio: permitir o no ejecutar ficheros, sync o async, atributos extendidos o no, atime/noatime, ... - puedes establecer diferentes sistemas de ficheros en función de los datos que se van a manejar - puedes establecer diferentes sistemas de ficheros en función de lo que se quiere hacer con esos datos (clustered file system, servidor de ficheros de sólo lectura, ...) - puedes usar algún SW de gestión de volúmenes de forma que si una de las particiones crece o necesita más espacio, puedes añadirle más espacio/discos (lo más típico es LVM en Linux) - puedes facilitar las copias de seguridad/recuperación de datos (si esto lo juntas con volúmenes, puedes hacer snapshots :) - puedes trabajar con sistemas de ficheros remotos - puedes duplicar sólo determinados sistemas de ficheros mediante drbd - aunque dos de las particiones vayan a usar el mismo sistema de ficheros, puedes usar diferentes opciones (por ejemplo, tamaño de log del journal distinto, ...) para crear los sistemas de fichero para afinar su funcionamiento para cada sistema de ficheros Como ves, razones para separar los directorios de cada servicio es aconsejable ;)
¿Sería recomendable también montar una particion con /srv/ con tal de meter ahí la data de www y ftp? No creo que sea mala idea, pero he visto que sea tampoco un práctica habitual.
Facilita las cosas en caso de updates.
Como te he comentado antes, yo separaría todo :)
¿Qué filesystem meto? Había pensado un clásico como ext3 para /boot
ext2. Tiene un par de pistas no más, o sea, 20 megas más o menos. ext3 es un desperdicio, y puede que no te lo admita, necesita un minimo de tamaño.
Depende de los datos y/o lo que vayas a hacer con esos datos, dbes usar un sistema de ficheros u otro. Voy a dar una opinión personal que a mi me ha ido bien, pero NO significa que funcione para otros. ext3 -> si no sabemos el tamaño de ficheros que vamos a manejar reiserfs -> si los ficheros vana ser pequeños, muchos y muchos directorios y subdirectorios XFS -> si los ficheros con los que vayas a trabajar son grandes Cosas a tener en cuenta: reiserfs necesita mínimo 32 MB de espacio en diso XFS (a menos que lo tunees) es lento borrando ficheros cada sistema de ficheros consume más o menos CPU, memoria, ... para cada cosa que hace. Por ejemplo, XFS puede escribir y leer en paralelo si tenemos un sistema SMP, pero consume más CPU. Si NO tienes SMP, no es aconsejable activar esto. ext2 y jfs ni los tengo en cuenta Para acabar todo este rollo que estoy contando, si puedes poner los diferentes sistemas de ficheros en diferentes discos duros ... esto ya va a ser impresionante ;)
o /,
Si, ext3 está bien.
mientras que en otras particiones quizá ResiserFS o XFS serían más óptimas dependiendo del tamaño medio de los archivos que se manejen.
También. El segundo parece mejor todavía; necesita memoria.
Leí una vez una comparativa muy buena en Bulmalug, es algo antigua, pero te puede ser útil. HTH Rafa
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2005-07-21 a las 10:56 +0100, Rafael Griman escribió:
Las razones por las que debes montar distintos directorios sobre distintas particiones son:
Me las guardo para mi FAQ particular :-)
ext2 y jfs ni los tengo en cuenta
Discrepo :-) - ext2 es buena en ciertos casos, como por ejemplo, cuando la partición es pequeña: caso de /boot o de discos zip. Son discos de escritura esporádica, y donde el tamaño del "diario" es demasiado considerable para el poco espacio disponible. Por ejemplo, el tamaño minimo para una reiser son 100 megas.
Para acabar todo este rollo que estoy contando, si puedes poner los diferentes sistemas de ficheros en diferentes discos duros ... esto ya va a ser impresionante ;)
En maquinas antiguas con poca cpu, el separar el sistema habilmente en dos discos duros lo acelera apreciablemente (y no hablo de raid). Hasta viene comentado en el manual de la SuSE ;-) Por cierto, también tengo la sospecha que en maquinas con poca cpu usar ext puede ser ventajoso frente a ext3. Y si hay poca memoria, también puede interesar no usar varios tipos de sistemas de ficheros, puesto que cada uno añade su propio modulo al kernel.
Leí una vez una comparativa muy buena en Bulmalug, es algo antigua, pero te puede ser útil.
En el manual de administración hay una. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFC3+A1tTMYHG2NR9URAruaAJ9/S3t4JijCyOwJfbfo1C6DF5308wCePj4M ue7wTKRTP1R9Su9+kAwWHbU= =WADK -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2005-07-21 a las 10:56 +0100, Rafael Griman escribió:
ext3 -> si no sabemos el tamaño de ficheros que vamos a manejar
reiserfs -> si los ficheros vana ser pequeños, muchos y muchos directorios y subdirectorios
XFS -> si los ficheros con los que vayas a trabajar son grandes
Me acabo de topar con una cosa interesante, que viene en REISERFSTUNE(8): DESCRIPTION reiserfstune is used for tuning the ReiserFS. It can change two journal parameters (the journal size and the maximum transaction size), and it can move the journal's location to a new specified block device. (The old ReiserFS's journal may be kept unused, or discarded at the user's option.) Besides that reiserfstune can store the bad block list to the ReiserFS and set UUID and LABEL. Note: At the time of writing the relocated journal was implemented for a special release of ReiserFS, and was not expected to be put into the mainstream kernel until approximately Linux 2.5. This means that if you have the stock kernel you must apply a special patch. Without this patch the kernel will refuse to mount the newly modified file system. We will charge $25 to explain this to you if you ask us why it doesn't work. Perhaps the most interesting application of this code is to put the journal on a solid state disk. Los dos detalles que me llaman la atención son: a) el ultimo parrafo b) que cobran 25Eur por explicarte el porqué el kernel normal necesita un parche para que funcione la deslocalización del diario. Lo del ultimo párrafo ya se me había ocurrido hace tiempo, y es obvio: si puedes separar el diario a otro disco, y este es un disco de estado sólido, pues obviamente vamos a acelerar el rendimiento considerablemente. Ahora, ¿quien los vende? No me he topado con ellos, salvo unos que emulaban flopies para pcs "embebidos" (no me gusta esa traducción). - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFC3+N8tTMYHG2NR9URAorLAJ4wOr+aoONA9Ep5H8s2iAvuo2ci8QCdF9VA u0OhfQyQdEfpig0yPWhqj50= =yXEF -----END PGP SIGNATURE-----
participants (2)
-
Carlos E. R.
-
Rafael Griman