Mailinglist Archive: opensuse-es (614 mails)

< Previous Next >
Re: [opensuse-es] Re: lvm o particiones extendidas
  • From: Rafa Grimán <rafagriman@xxxxxxxxx>
  • Date: Sat, 24 Apr 2010 22:51:54 +0200
  • Message-id: <201004242251.54936.rafagriman@xxxxxxxxx>
Hola :)

On Friday 23 April 2010 15:26 Camaleón wrote
El Fri, 23 Apr 2010 14:51:05 +0200, Rafa Grimán escribió:
On Friday 23 April 2010 14:12 Camaleón wrote

Ya, pero hace streaming de video, lo cual tiene unas exigencias
mayores en cuanto a disponibilidad del material por lo que si con un
vídeo lo puedes hacer ... con un correo no te quiero contar lo qu
epuedes hacer ;)

El streaming de vídeo no es de acceso lectura/escritura, que yo sepa

:-)

Eso es que no conoces cómo funciona el mundo media. Toda slas
televisiones y productoras tienen escritura y lectura simultáneamet y

por varios usuarios:
- unos editando contenidos
- otros catalogando
- otros creando
- ...

La NBA, como buena productora y TV que es ... funciona así así que sí,
hay lectura y ecritura al mismo tiempo en tiempo real y por varias
personas.

¿En "streaming"? ¿Todos editando el flujo de datos en tiempo real? caray,
eso sería interesnate de ver...


No Camaleón, nadie ha dicho que estén editando TODOS en tiempo real, te he
puesto 3 tareas que se hace, relee los puntos qu ehe puesto más arriba. Hay
gente que edita, hay gente que cataloga, ... No líes.

Aunque no haya nadie editando en ese momento el contenido del que se está
haciendo streaming (de hecho el contenido que se emite en web es LowRes por lo
que no se edita, se edita el bruto y posteriormente se conforma). El ancho de
banda es importante, al igual que son las latencias. Por eso, al usar HSM en
el mundo de media, se hacen cosas como las que he mencionado y que sigues
ignorando una y otra vez:
- dejar el principio del contenido on-line
- dejar determinadas secuencias on-line y las demás en
near-line u off-line


¿No es habitual? ¿No es habitual ver vídeo en Inet? Podría haber
usado Youtube si quieres.

Hijo, pues no. La NBA no es una empresita del montón, la verdad.

Google tampoco ;)

Claro, pero es que si te digo que cualquier empresa del montón necesita
disponer de esos datos en tiempo real (no archivados) no me crees. Por
eso he puesto como ejemplo es servicio IMAP de Gmail.


No Camaleó, lo que digo es que conozco empresas que lo usan. Te he dicho que
empresas como IBM, EMC y otras tienen muchos clientes que lo usan (en entornos
que tu estás poniendo como ejemplo) y sigues sin creerme. Como no lo conoces,
te resistes a creer que eso funciona. Pues te guste o no, te resistas o no:
eso funciona y hay mucha gente usándolo. Te he puesto ejemplos de TV y
productoras cuyo "tiempo real" es MUY superior al de una oficina que necesita
acceso a un correo o un fax, ejemplos que has puesto tu.

Abre los ojos. El que tu no lo conozcas o no lo hayas probado, no significa que
no existe o que no se pueda uasr. Sale allí afuera y mira por ti misma las
empresas que lo usan y para qué lo usan.

Por cierto, otra cosa: correo, fax, ofimática y similares NO son tiempo real.
Media (broadcast, postproducción, ...) sí es tiempo real, al igual que es el
control de un avión, una central nuclear, ... Yo SÍ te he puesto ejemplo de
uso de HSM en entornos de tiempo real, tu no ;)


Te he puesto como ejemplo cualquier empresa vulgaris pero tú dices que
no, que eso de mantener los correos en línea no era la norma. Ahí es
cuando te he puesto como ejemplo a Gmail. Podría haber dicho cualquier
otra empresa que dé servicio IMAP (o en la nube).

¿Google vulgaris? Eso es nuevo: si mal no recuerdo, tienen más de 1
millón de servidores.

Es más, eGoogle puede que tengas más razón en que no puedan archivar
correo, pero en una empresa pequeña/mediana que los trabajadores se van
a casa ... razón de más para poder archivar, mojer y hacer lo que te da
la gana: no hay nadie usándolo (bueno, siempre hay alguien conectado),
pero reclama el correo, fichero, dato y solucionado. De hecho, te he
puesto ejemplos en los que el usuario no sabe ni que está trabajando
contra cinta.

Sigo sin ver claro eso de acceder a los correos mediante IMAP tirando de
un archivo ubicado en una cinta, de verdad... como no sea un buen sistema
de cinta, rápido y fiable, te echan a perder la copia en pocos días y la
cinta, a la basura. ¿Tiene límites de escritura, no?


¿Qué tecnología de cinta usas? ¿DLT? No me extraña que tengas ese concepto de
las cintas ;)

No digo que la cintas no se estropeen, claro que se estropean, pero sigues sin
entender el concepto. Para empezar, cuando archivas o usas HSM, no estás
accediendo a los datos constantemente, son datos "antiguos" que a lo mejor
accedes una vez al año o al mes. Así que el desgaste de la cinta no es tan
grande, el consumo eléctrico tampoco, el calor producido tampoco, ... Por l
oque no estás constantemente leyendo de cinta.

Segundo, al mover los datos a cinta, lo haces de forma que:
- sea cuando menos uso se le da (de noche, por ejemplo)
- se migren la mayor cantidad de datos posible
- ...

Así que tampoco estás constantemente escribiendo a cinta.

A todo esto, el disco también se estropea y más si no es "enterprise class".


A ver, a ver... 20 GiB son 20 GiB que necesitan espacio físico si
tienes un disco duro de 60 GiB y si no tienes espacio, el sistema se
queda colgado, no puedes iniciar sesión, los correos se rebotan, etc...

Correcto, de ahí que te haya hablado de:
- tecnologías ue te permiten ampliar, archivar, ...

- previsiones

- montar un segundo disco y descargar datos "amanuense"

Eso jamás te lo he negado. Lo que digo es que si crece /var/algo en su
propio sistema de ficheros, /var (que está en SU sistema de ficheors) NO
crece de forma física.

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

Si haces un "du -sh /var", te saldría: 2 GB + 10 Gb + 10 GB = 22 GB

Resulta que en tu empresa se usa mucho el correo y mañana lo vuelves a
ejecutar (df -h) y te sale:
/ 3 GB
/var 2 GB
/var/correo 50 GB
/var/log 30 GB
/home 30 GB

Si ahora vuelves a ejecutar "du -sh /var", te mostrará: 2 GB + 50 GB + 30 GB =
82 GB. Este comando te está sumando todo lo que cuelga de /var, pero si te
fijas en df ... el sistema de ficheros /var NO CRECE, crecen /var/correo y
/var/log. Luego NO tienes que ampliar /var, tienes que ampliar /var/correo y
/var/log. El que crece físicamente es /var/correo y /var/log.

/, /home y /var no crecen físicamente, pero de forma lógica, / y /var sí
crecen porque tienen sistemas de ficheros que cuelgan por debajo.


¡Claro que crecen! Hasta el límite físico que tengas definido (sea el
tamaño del disco o de la partición), pero la cantidad de datos se
incrementa con cada copia de seguridad que hago, o con cada correo o
con cada fax que se envía o se recibe.

A ver, tú has escrito

"Pues eso... para el 85% de las "empresas/usuarios" "/var" crece

y mucho > ;-)"

Y yo he dicho que no, que lo que crece es el sistema de ficheros (mejor
dicho, el volumen de datos de un sistema de ficheros) y que si /var y
/var/algo son dos sistemas de ficheros diferentes y el que crece es
/var/algo ... /var no crece. Y eso mismo le he respondido a Carlos.

Ah, ya, que dabas por hecho que /var/*/ está particionado.

Aún así, está limitado por el tamaño de la partición que lo contiene y
los datos crecen de la misma forma. No en "/var", pero sí en "/var/
mail" (por ejemplo). Estás con el mismo problema.


NO estás con el mismo problema. /var no crece por lo que no tienes que ampliar
/var. De hecho, si amplías /var ... estás desperdiciando espacio. porque /var
no crece, tienes que ampliar /var/algo que es el que crece.

[...]


Eso no es cierto. No me creo que TODOS y me refiero a ABSOLUTAMENTE
TODOS los ficheros que hay en tus sistemas informáticos se usen
SIEMPRE. No me lo creo.

Necesitar != querer.

Ya te dije que sí. Al menos yo necesito tener los faxes recibidos/
enviados de hace 3 años bajo /var/spool/hylafax... o eso o empiezo a
montar el servidor desde cero integrando alguna de esas soluciones que
comentabas -> inviable, al menos de momento.


No es desde cero, estas soluciones se integran en lo que ya tienes ;)

En cuanto a que en tu empresa usan TODOS los ficheros de fax recibidos SIEMPRE
... es físicamente imposible. Tendría que haber tantas personas como ficheros
de fax ... y ya se los sabrían de memoria por lo que no necesitarían acceder a
ellos ;)

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

Camaleón, hay empresas de todo tipo, tamaño y color usando estas herramientas
y funcionan, te guste o no. Para gestionar sus fax, sus correos, sus ficheros
de imágenes, todo lo que se te pueda ocurrir. Hay gente con más o menos
correos, más o menos ficheros, más o menos empleados, ... Pero les funciona. Te
lo vuelvo a repetir: sal allí afuera y habla con ellos. Como siempre, habrá
gente contenta y gente descontenta, eso no te lo va a negar nadie


Eso lo dices porque no has usado sistemas de HSM, si los hubieras usado
verías que no NECESITAS que estén on-line. El usuario no sabe ni dónde
están ni se da cuenta si tarda en venir o no de cinta a disco. Te he
puesto ejemplos de vídeo que es TIEMPO REAL, si pierdes un frame ... al
carajo todo. Y allí funciona. También te he dicho que nosotros y otros
fabricantes lo implementan para todo tipo de ficheros: ofimática,
imágenes, ...

Estás haciendo suposiciones sobre algo que no has usado y no conoces. Yo
lo he visto en clientes grandes y pequeños, con necesidades de tiempo
real y no y el usuario no se da cuenta.

Hay muchas cosas que no conozco, Rafa. Lo que sí se es que implementar
esas soluciones integradas que dices cuestan tiempo y dinero.


Como todo en esta vida, no hay nada gratis. Eso jamás te lo he negado ni
discutido


Que sí, que están muy bien. Sólo te digo que en nuestro caso en concreto
no es una opción justificable. Es más, si me dieran presupuesto,
preferiría actualizar los routers, actualizar los switches de la red2 a
gigabit (pasar de "10/100" a "1000" se nota... y mucho), añadir algún
cortafuegos más o traer una estación de trabajo nueva. Tenemos otras
prioridades antes que el almacenamiento.


Volvemos a lo de antes, es que yo no te he dicho que lo tengas que
implementar. Sólo te he dicho:
- que la tecnología existe
- cómo funciona (a grandes rasgos)
- algunos fabricnates que lo tienen
- que hay clientes contentos
- ejemplos de clientes

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


Ya sé que recibís planos de AutoCAD, alguna vez has comentado el tipo
de empresa en la que trabajas y coincide con el tipo de empresa de
algunos de nuestros clientes. Pero eso no quita que esté mal y no me
vale el que digas: "Es que los usuarios se quejan o no quieren
aprender a usar FTP".

Exacto: no quiere usar el FTP.

A tus usuarios los puedes "domesticar" (quiero decir, intentar hacerles
comprender cómo hacer bien las cosas) pero a los usuarios de empresas
asociadas o con las que trabajas, ah, amigo... esos no son tuyos y
entienden la vida de otra forma... si te gusta vale, y si no, adiós
contrato. Es así.

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.


A eso me refiero, copio y pego un trozo de tu frase: "[...] hasta que
al año siguiente se archivan." Vuelves a darme la razón. Llevo todo
este tiempo diciendo que se establecen políticas basadas en tiempo y
el que establece ese tiempo es el cliente porque es el que sabe cómo
funciona su empresa.

He dicho "un año" por decir... pueden ser 5, o 10... y el /var sigue
creciendo a diario.

Me da igual. El cliente es el que establece las políticas y es el que
las modifica. He comentado en otro correo que los 3 - 4 primeros meses,
el cliente modifica las reglas para irlo tuneando o afinando para sus
necesidades, pero a partir del 6 mes ... eso no lo vuelve a tocar nadie
(a menos que los flujos de trabajo cambien).

Pero es que sigues dando por hecho que se tiene que archivar todo cada
poco tiempo y yo no lo veo así.


NO señor. Yo NO doy por hecho que HAY que archivar TODO CADA POCO TIEMPO. He
dicho que es el CLIENTE el que DECIDE las políticas de archivado y eso incluye
lo que se archiva y cuándo se archiva.

[...]

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 >