-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 >:-) 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.
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. 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. 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. 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.
No es cierto y lo he vivido con clientes nuestros. Han migrado a DAM y proveedores y usuarios internos trabajan tan contentos. ¿Saben realmente que es un FTP o un WebDAV o un CIFS? No. ¿Lo tienen que saber? No. Tu le das una interfaz web o si quieres les programas un cliente nativo para su sistema operativo o un cliente XUL para Firefox o como te de la gana o creas que es más sencillo para el usuario y ya está. Generalmente lo más sencilo para el uusario es una interfaz web.
Rafa, yo no puedo controlar a nuestros proveedores ni decirles cómo tienen que hacer las cosas. Nos mandan a freír monas. Si ellos quieren enviar por e-mail lo que tengan que enviar lo hacen a su modo o como buenamente puedan/sepan (una memoria completa en PDF de un proyecto puede ocupar más que un sólo archivo de CAD con los planos o los cálculos de las estructuras) .
A ver, cada proveedor es distinto. Con unos sí podemos hacerlo (porque llevamos más tiempo trabajando con ellos, sabemos su metodología y ellos la nuestra, hemos establecido un protocolo de actuación, etc...) pero con los que tenemos poca relación, no.
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. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkvTj/4ACgkQU92UU+smfQVQiQCfX8KvLVQrGBiAPuUv2qo7c2tf 9HgAoICnPjVXyIzrUvihmr0VHNY2mP2/ =fjqE -----END PGP SIGNATURE----- -- 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