Hola :) On Tuesday 08 September 2009 21:19:33 Carlos E. R. wrote:
El 2009-09-08 a las 18:07 +0200, Rafa Griman escribió:
Todo sistema de ficheros se fragmenta, nos guste o no y especialmente los sistemas de ficheros que: - gestionan/guardan ficheros grandes - escriben y borran muchos ficheros
Otra cosa es que haya técnicas para mitigar la fragmentación (como el delayed allocation u otras).
La prueba se puede hacer fácilmente con una partición de de por ejemplo 10 GB y creando y borrando ficheros de 1 a 3 GB aleatoriamente. Llega un momento en el que el sistema de ficheros se fragmenta y los ficheros también.
Eso es cierto, pero es que en este caso los ficheros no son "grandes", no superan los ochenta megas, y muchos de ellos. Las grabaciones de varios gigas están partidas en docenas o cientos de ficheros de ochenta megas, y estos ficheros a su vez están fragmentados. Y cada grabación está en un directorio aparte.
Luego está fragmentado el fichero: si pillamos un vídeo/película (¿~800 MB?) y lo partimos en trozos de 80 MB ... está fragmentado ya que ext3 (y los demás sistemas de ficheros en Linux o por lo menos los más actuales) hacen un delayed allocation de ese fichero que mide 80 MB. Es decir, para el sistema de ficheros el fichero mide/pesa 80 MB y no los 800 MB, pero a nivel lógico (para la aplicación), el fichero mide/pesa 800 MB. Cada 80 MB se escribirán donde quepan dando lugar a fragmentación interna del fichero (no necesariamente del sistema de ficheros) y, en el momento que borres el fichero ... dará lugar a una gran fragmentación del sistema de ficheros (tanto del espacio ocupado como del espacio vacío). Si cada vídeo se almacena en un directorio propio, lo que se está intentando es tener los i-nodos cercanos (esto lo hace XFS también). Esto es muy útil para evitar que los IOPS se desperdiguen por todo el disco duro (mover el cabezal para una lectura/escritura mínima), pero: - el streaming de un vídeo no es el óptimo - se producen muchos IOPS para un único vídeo En todo caso la definición de "grande" depende de muchas cosas: tamaño de la partición, tamaño de los bloques que se están usando, ...
Lo que digo es que sospecho que están usando un algoritmo para minimizar el tiempo de escritura (que necesita ser en tiempo real), escribiendo en algún sector que encuentra antes o que reduce el movimiento del cabezal, en vez de esperar a meterlo en un sitio óptimo.
Lo del movimiento del cabezal sería lo de meter en un directorio todos los ficheros asociados, pero al mismo tiempo, por el hecho de hacer trozos de 80 MB ... aumentas los IOPS, lo cual es negativo. IMHO, lo que han hecho es buscar un tamaño de "bloque"/unidad mínima de datos ideal que son los 80 MB para cargar datos en buffer, caché, RAM, ... como lo quieras llamar. Es un tamaño suficientemente grande como para no agobiar al disco duro (no tener un IO wait eterno porque escribe a disco, que es lo que realmente mata el rendimiento de las aplicaciones). Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.0 :) -- 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