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@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org