Mailinglist Archive: opensuse-es (1469 mails)

< Previous Next >
Re: [suse-linux-s] OpenSUSE abandona ReiserFS
  • From: Rafa Grimán <rgriman@xxxxxxx>
  • Date: Thu, 5 Oct 2006 15:21:25 +0000 (UTC)
  • Message-id: <200610051721.04041.rgriman@xxxxxxx>
Hola :)

El Jueves, 5 de Octubre de 2006 13:50, Carlos E. R. escribió:

[...]

> > > Lo que no se es porqu los de mythtv no usan una particin raw para
> > > el buffer circular de recepcin/visionado.
> >
> > El usar raw implica "ignorar" las cachs y los buffers y acceder
> > directamente al dispositivo. Esto para vdeo no es tan bueno porque lo
> > que te interesa es que el streaming se haga desde memoria (ms rpido y
> > menos latencia) que desde disco. Adems, si dos procesos estn
> > accediendo a dos sectores diferentes de disco ... el rendimiento (en el
> > caso de raw) caer vertiginosamente porque el cabezal tiene que bascular
> > mucho :(
>
> Pues curiosamente los de xine creo que usan raw precisamente para evitar
> el uso de la cache, porque al ser un fichero enorme que se lee una nica
> vez no tiene sentido guardarlo en memoria que es ms util para otros


Siempre y cuando hablemos de un proceso que accede a disco, ¿qué ocurre si son
muchos usuarios que acceden a vídeo en tiempo real? Pues que no es sostenible
esto. Necesitas cachear todo lo que puedas a memoria porque los cabezales
están como locos saltando de un vídeo a otro para satisfacer las peticiones
del resto de usuarios y procesos.


> ficheros del proceso normal del sistema, que se enlentece globalmente.
> Creo que en esos casos es ms eficaz una cach dedicada al proceso en
> cuestin, o un bufer de lectura grande; es decir, limitar el tamao de
> cach dedicado a ese proceso.


Eso también es interesante, poder gestionar la caché o los buffers en función
de tus necesidades. En el kernel, se pueden retocar mediante proc, pero nunca
he tenido que hacerlo.


> En mis tiempos que me ganaba los garbanzos programando en dos lo not: la
> copia de ficheros era muy rpida si a la funcin de lectura de un fichero
> le asignaba un bufer de 64 KiB (lo normal creo que era menos de un k). En
> el caso de tener un cache de sistema, el fichero es primero leido en un
> golpe grande (o varios) al cach del sistema, y de ah se copia al bufer
> de lectura, y de ah una tercera vez a la memoria del programa (las dos
> ultimas se podran juntar, en teora). Sin cach de sistema te ahorras
> un movimiento de memoria.


Sí, pero si te hacen una segunda petición, el dato está cacheado y se sirve
más deprisa :) Un ejemplo, en un cliente nuestro (una televisión) tienen una
máquina con 32 GB de RAM ... imagínate cómo cachea el SLES ;) Claro, la
segunda vez que se pide el fichero ... la latencia tiende a 0 por lo que el
cliente lo recibe en seguida. Eso sí, si abres dos vídeos ... los tienes los
dos en memoria y al hacer un free ves que libres hay 5 MB xD


> O dicho de otra forma, el programador del proceso conoce el tipo de
> entrada/salida que va a necesitar y se puede optimizar. El programador
> de la cach no: puede orientarla por sectores contiguos de disco, por
> ficheros completos, por peticiones de procesos, mezclas, algoritmos
> inteligentes... y todo porque no sabe realmente que es lo que le van a
> pedir.


Eso es otra historia: hoy en día el desarrollador de aplicaciones se basa ne
lo que hacen los desarrolladores del kernel, pero no piden que se implementen
determinadas cosas. Por ejemplo, en Linux, el tamaño de bloque máximo son 16
KB (si no recuerdo mal), ¿qué ocurre si mi aplicación funciona mejor leyendo
bloques más grandes?


> > > Bueno, en realidad recomendaban JFS, pero prefiero XFS. No iba a
> > > dedicarle una particin gigante a l solito, y slo para probarlo.
> >
> > Yo estuve un tiempo probando JFS y no me gust una cosa: es poco fiable
> > si se compila como mdulo :( Si quieres que sea fiable y no perder datos
> > ... inclyelo en el kernel !!
>
> Lo recuerdo, estuvimos hablando de eso aqu :-)
>
> Y puede dar guerra si a SuSE se le ocurre no ponerlo en el disco de
> rescate.


Cierto.

Rafa

--
"Even paranoids have enemies."

Rafa Grimán
Systems Engineer

Silicon Graphics Spain
Santa Engracia, 120 - Planta Baja
28003 Madrid
Spain

Tel: +34 91 3984200
Tel: +34 91 3984201
Móvil: +34 628 117 940

http://www.sgi.com

OpenWengo: rgriman
Skype: rgriman

< Previous Next >
Follow Ups