Mailinglist Archive: opensuse-es (614 mails)

< Previous Next >
Re: [opensuse-es] Re: lvm o particiones extendidas
  • From: Rafa Grimán <rafagriman@xxxxxxxxx>
  • Date: Fri, 23 Apr 2010 14:51:05 +0200
  • Message-id: <201004231451.05652.rafagriman@xxxxxxxxx>
Hola :)


On Friday 23 April 2010 14:12 Camaleón wrote
El Fri, 23 Apr 2010 13:32:35 +0200, Rafa Grimán escribió:
On Friday 23 April 2010 12:09 Camaleón wrote

La NBA no usa un servicio como Gmail :-)

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.


El correo, sí. Y por parte de varios usuarios al mismo tiempo.

A ver, que tú pones como ejemplo un tipo de industria/usuario que no es
el habitual,

¿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 ;)


el volumen de datos que tiene que manejar la NBA no es el volumen de
datos que tiene que manejar cualquier empresa ni las estrategias que
tienen definidas, tampoco se ajustan a una empresa media.

Eso te lo he puesto más abajo. Entonces también tienes que reconocer que
el ejemplo que has puesto tu (Google) tampoco "se ajustan a una empresa
media.", como bien dices ;)

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.


¿Lo hace Gmail? Ya te digo que no lo creo. El acceso desde el webmail a
los correos que tengo desde de la lista el año 2.003 es instantáneo,
dudo mucho que los tengan almacenados como archivo.

(...)

Yo te he puesto ejemplos reales que sí conozco, puedes ponerme ejemplos
reales que tu sí conoces.

Pero eso no es justo. Que yo no conozca ninguna empresa de primera mano
que siga una política determina no significa que no las haya. No es mi
campo (servicios a terceras empresas), no lo puedo saber.


Yo sí, y ya te he dicho que tenemos clientes grandes y pequeños que lo hacen.
Lo cual no quiere decir que todo el mundo lo deba hacer. Sólo digo que sí
pueden y de hecho lo hacen.


"Nada" es relativo. El "tiempo" es relativo, y lo que una empresa
archiva en un día otra no lo llega a archivar en 5 años (debido a la
diferencia entre la cantidad de datos que genera una y otra).

De ahí que hable tanto en los correos anteriores como ahora mismo de las
reglas o políticas que cada empresa pone en función de sus flujos de
trabajo (y órdenes/decisiones dle jefe). Me estás dando la razón, es lo
que he dicho en correos anteriores: depende de la empresa, es la propia
empresa la uqe tiene que decidir/definir sus políticas.

Vale, pues te doy la razón en lo del "factor tiempo" :-)

Pues eso... para el 85% de las "empresas/usuarios" "/var" crece y mucho
;-)

Volvemos a lo de antes: desde un punto de vista lógico, no físico y, te
guste o no, tu almacenamiento y el de todo ser vivo, es físico. Luego si

tienes:
/dev/sdc1 -> /var
/dev/sdd1 -> /var/log
/dev/sde1 -> /var/BBDD
/dev/sdf1 -> /var/correo_electronico_del_jefe ...

Y crece /var/correo_electronico_del_jefe y /var/log ... /var/ crece de
forma lógica, pero NO crece de forma física.

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.


Lo mismo ocurre si sólo

tienes los siguientes 3 sistemas de ficheros:
/
/home
/var

y /var y /home crecen 100 TB ... / NO crece, seguirá teniendo el mismo
tamaño que tuvo ayer a las 16:30 cuando lo instalaste. Crecimiento desde
un punto de vista lógico NO implica crecimiento desde un punto de vista
físico y a ti lo que te interesa es el crecimiento físico, el lógico te
da igual.

¡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.

En cuanto a que:

"¡Claro que crecen! Hasta el límite físico que tengas definido
(sea el tamaño del disco o de la partición)"

tampoco es cierto ya que si usas LVM o una solución de HSM, el crecimiento es
hatsa que te dé el bolsillo ;) No depende del disco físico que haya debajo. Tu
disco puede ser de 1 TB, pero con LVM puedes ir añadiendo discos de 1 TB hasta
que te quedes sin dinero.


porque no uso volúmenes "expandibles" ni cabinas de discos enganchadas.
Con 1.2 TiB para espacio compartido de archivos y backup de momento nos
sobra :-P

¿Y? Eso no significa que no lo vayas a necesitar. Pero ... volvemos a lo

que he dicho en todos mis correos de este thread:
- la empresa es la que decide así que si te funciona así,

por mi bien, sigue así :D

- yo no estoy intentando convencer a nadie de que use una

determinada tecnología, me limito a contar la tecnología que

existe

La tecnología existe, por supuesto. Pero no siempre merece la pena
implementarlas.


Yo no he dicho que merezca la pena, ni que sea obligatorio ni necesario. He
dicho que es interesante tenerlas en cuenta y conocerlas, que es diferente.

[...]


Pero es que necesito que estén en disco y accesibles, no en cinta y
archivados.

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.


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.


y para los afortunados que pueden
comprarlo y ampliar el espacio, tienen además que tener una
configuración que admita la gestión de volumen dinámicos (el LVM que
estábamos comentando)

Para la solución que yo he dado (montar un disco nuevo bajo
/var/disco_nuevo) NO hace falta tener LVM.

Entonces te encontrarás con el mismo problema de limitación de espacio.


No digo que no te encuentres de nuevo con el problema, sólo he dicho que no es
necesario tener LVM. Depende de cómo quieras solucionar el problema. También
te podía haber puesto como solución el comprar una cabina de discos externa.
(cabina de discos de SGI, claro está ;)


y hay quien sencillamente no quiere usar ese tipo de soluciones porque
no les compensa.

O a lo mejor no lo necesita porque montando el nuevo disco como he dicho
en el ejemplo les vale. Te repito que NO estoy obligando a nadie a usar

ninguna tecnología:
Ya sabemos que no obligas a nadie...

(¿qué hace esta argolla con pinchos alrededor de mi cuello?)


No es de pinchos, son explosivos ... Mira que les tengo dicho a los de
marketing que los explosivos en forma de pincho crean confusión. Nada, que no
hay manera ...

x"D


Eso no depende de ti, y nosotros podemos recibir planos completos en
AutoCAD por correo electrónico (no preguntes...). Tengo que relajar
esas normas o podemos perder mucho, no sólo tiempo sino dinero.

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.


Como siempre: otro consejo. Hago esta aclaración porque vas a volver a
interpretar que te quiero obligar o convencer a usar una tecnología. Ya
que estamos con este tema de AutoCAD (y lo que conlleva: múltiples
ficheros, desde docs, PDFs, fotos de terrenos, planos, ...) os vendría
de perlas un DAM porque evitarías que la gente enviase tanto plano por
correo ;)

¡¡¡Argghhh, más siglas...!!! X-)


Ya lo puse en un corre anterior ;)


No se trata de que esté o no archivada, se trata de que te ocupa
espacio en disco... hasta que llegue a su destino. Y su destino puede
ser "/var/ mail", donde la persona que se encargue de consultar esos
correos lo haga mediante IMAP y ahí se quedan los correos hasta que al
año siguiente se archivan.

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).

[...]


Por eso evito particionar pero me encargo de tener siempre los backups
al día :-P

Buena práctica :D

Hasta que algún día tenga problemas con "la" partición, claro :-P


Hmmmm, para ese tipo de problemas se me ocurre:
LVM
Archivado
HSM

x"D

Es una broma. Lo que sí recomiendo es que no tengas datos y backups en el
mismo sitio: si pierdes uno ... pierdes el otro :(

[...]

... a mi personalmente me importa un bledo*, a mi lo que me gusta es el
skate y el snow ;)

Y los caracoles...


Que no falten !!! x"D

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 >
Follow Ups