Mailinglist Archive: opensuse-es (614 mails)

< Previous Next >
Re: [opensuse-es] Crecimiento de /var [Era: lvm o particiones extendidas]
  • From: Rafa Grimán <rafagriman@xxxxxxxxx>
  • Date: Sun, 25 Apr 2010 12:32:36 +0200
  • Message-id: <201004251232.36867.rafagriman@xxxxxxxxx>
Hola :)

On Sunday 25 April 2010 02:42 Carlos E. R. wrote
On 2010-04-24 22:51, Rafa Grimán wrote:
No pillo ese "no crecimiento físico" del que hablas. Los datos ocupan
espacio físico, estén en /var, en /home o en cualquier otro lado
(recurso de red, servidor remoto...).

Te pongo el ejemplo que ya he puesto, imagínate que tienes (4 sistemas de

ficheros, 4 particiones):
/dev/sda1 -> disco de 80 GB -> /
/dev/sdb1 -> disco de 80 GB -> /var
/dev/sdc1 -> disco de 80 GB -> /var/correo
/dev/sdd1 -> disco de 80 GB -> /var/log
/dev/sde1 -> disco de 80 GB -> /home

Haces hoy un df -h y te sale (ponemos sólo lo ocupado):
/ 3 GB
/var 2 GB
/var/correo 10 GB
/var/log 10 GB
/home 30 GB

Pero eso es ser tiquismiquis >:-)


No es ser tiquismiquis, es ser realista ;)


Ya sabemos que puedes organizar la estructura como quieras, puedes tener un
espacio tremendo en alguno de los subdirectorios del /var para lo que sea
que sepas que crece mucho, en un disco físico clase enterprise, con LVM,
RAID, HSM o lo que te de la gana, y tener el resto en un espacio más
normalito.

Pero es que esa no era la pregunta original... el OP tiene sólo un disco de
65 gigas y preguntaba como particionarlo, con LVM o con lógicas. En ese
contexto, a la partición de /var no se le puede presuponer un tamaño fijo
y pequeño. En este contexto, /var crece. Si especificas que vas a separar
las partes de /var que crecen más y ponerlas en otro sitio para evitar que
/var crezca (considerando estrictamente /var), es otra cosa. Pero se sale
de la premisa inicial o las habituales. Claro que se puede hacer, y se
hace.


Pero es que yo ya contesté a su pregunta, lo que estaba haciendo era aclarar
que tenemos que tener en cuenta la disposición física y que no necesariamente
parte lógica = parte física. Si no tenemos eso en cuenta ... la podemos liar
;)


Te lo vuelvo a repetir quere != necesitar. Yo quiero un Rolls Royce con
chófer, pero no lo necesito ;) Tu quieres tener esos ficheros on-line,
pero no los necesitas on--line. Los quieres on-line porque no quieres
que la gente te dé la murga pidiéndote los ficheros (fax) que se
encuentran en una cinta o en

un CD. Pero es que no funciona así, te lo vuelvo a repetir:
- si es HSM: el usuario no sabe que está en cinta, el usuario pincha

en la unidad D: (o la que sea) y ya está

- si es Archivado: el usuairo abre su aplicación y reclama el fichero,

igual que si se tiene que levantar físicamente e ir a un archivador

a coger una factura o un plano ploteado

Suponte que uno de los usuarios hace un grep sobre todos los faxes... ya la
has liado, porque o se cargan todos en disco (si caben) o tienes un
sistema que haga la busqueda por zonas. Y como el usuario te haya
programado un script que hace tres greps paralelos, y cada uno consistente
en 20 greps secuenciales, pues la has cagado.


¿Cuántos usuarios saben que grep existe? ;)


Me dirás ¿Y quien es el idiota que...? Pues yo... yo en mi trabajo hacía
greps de esos en los logs de todo el año.


Ya me has dado parte de una política: 1 año ;) La cosa es saber cuáles son los
flujos de trabajo. Si no conocemos nuestra empresa ni cómo trabaja la gente ...
mal vamos porque no seremos capaces de:
- dimensionar hardware
- hacer un cálculo de presupuestos para el año siguiente
- hacer previsiones de crecimiento
- hacer frente a situaciones inesperadas
- ...


Obviamente, si tengo un sistema de faxes en una empresa que manda y recibe
cientos de faxes diarios, y de varias páginas con gráficos, y me piden que
sean accesibles siempre los de todos los años (copia legal aparte), pues o
pongo unos discos grandes, con backups incrementales, o pongo un sistema
de esos que dices de tres capas, la ultima en cinta, con lo que los discos
van a ser más pequeños.


Esa es la idea.


Pero eso no es rentable si el volumen de faxes en total cabe en un disco de
menos de 500 gigas. Y me apuesto una pizza que los de Camaleón caben y le
sobra.


Y dale ... Que yo no le estoy intentando convencer que tiene que usarlo. Yo no
he dicho en ningún momento que Camaleón (o cualquier otro lector de esta
lista) lo tenga que implementar.

Qué perra habéis cogido! Que me da igual que lo implemente o no, que no esa no
es mi "misión". Me he limitado a comentaros una tecnología que existe y os
habéis empeñado en que quiero que todo el mundo lo use. No sé de dónde habéis
sacado esa idea. Si claramente he dicho, copio y pego:

"En ningún momento te he dicho que lo uses. Es másm te he dicho
que prefiero qu eno lo uses ni tu ni nadie porque así me hago rico
vendiendo discos :D"

Otra cosa que no tenéis en cuenta es que os estáis obsesionando única y
exclusivamente con los fax y los crreos. Ya sí, era un ejemplo, pero estáis
suponiendo un único tipo de fichero no el almacenamiento como un todo, lo cual
es un error porque tu empresa almacena más que faxes y el volumen total de tu
almacenamiento es lo que te (tiene que) preocupa(r).

Una empresa NO monta esto SÓLO para gestionar un tipo de fichero. Es decir,
aunque tus 27 años de fax quepan en un disco de 80 GB, estas soluciones NO se
implementan SÓLO para el fax sino para todos los ficheros: PDFs, DOCs, PPTs,
XLSs, XDGs, JPGs, AVIs, MOVs, AIFFs, ...

Las tecnologías de las que he hablado son para gestionar ALMACENAMIENTO, como
un todo, NO son para gestionar un único tipo de fichero. Y, de hecho, tenemos
clientes que usan esta tecnología para su almacenamiento, pero excluyen un
determinado tipo de fichero o sistema de ficheros poruqe no crece. También se
os
está escapando que estoy hablando de POLÍTICAS de migración:
- por fecha
- por tamaño
- por usuario
- por tag (puedes ponerle un tag a los ficheros)
- ...
- incluso los puedes mover manualmente, como os he
dicho en correos anteriores, bien sea el admin, bien
sea el usuario ... Eso es otra política: si queremos que
el usuario pueda o no migrar lo datos

[...]


A lo mejor me he explicado mal, no te estoy diciendo que lo hagas, te
estoy diciendo cómo lo puedes hacer en caso de querer hacerlo.

Yo lo que haría sería poner dos servidores de correo, uno "normal", y otro
para los enormes, con baja prioridad. Si envias uno muy grande al
principal, que rebote. Me sospecho que podría ser automático.

O bien, en el interior de la empresa, los distribuiría en dos servidores
imap distintos, para evitar que el servidor habitual se vuelva
horriblemente lento.


Es otra opción. Cada maestrillo tiene su librillo ;) Hay muchas alternativas
:)

Rafa

--
"We cannot treat computers as Humans. Computers need love."

Happily using KDE 4.4.1 :)
--
Para dar de baja la suscripción, mande un mensaje a:
opensuse-es+unsubscribe@xxxxxxxxxxxx
Para obtener el resto de direcciones-comando, mande
un mensaje a:
opensuse-es+help@xxxxxxxxxxxx

< Previous Next >