-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-10-05 a las 10:38 +0200, Rafa Grimán escribió:
No sab[ed]a que MythTV te aconsejaba XFS, es bueno saberlo ;)
Unlike a typical filesystem, a MythTV video partition is usually a very large filesystem filled with a fairly small number of large files. Filesystem I/O is usually not an issue, even in multi-tuner and/or multi-frontend setups.
There is however, one aspect of filesystem performance that can have a bearing on the performance of MythTV. In Linux, deleting a file will utilize I/O bandwidth until the deletion has been completed. If deleting the file takes long enough, the video capture buffer may overrun, thereby resulting in dropped frames. Some filesystems are faster at deleting files than others and, for multi-gigbyte MythTV video files, these differences can be significant.
Lo cual es una cosa que me llama mucho la atención, porque yo el único sistema de ficheros que conozco en profundidad es el fat, y ahí borrar un fichero son dos operaciones de disco: marcar como borrada la entrada del directorio, y alterar la tabla de adjudicación de ficheros (fat), que se calcula en memoria y se escribe de un golpe - bueno, se escribía. Es una lista ligada mantenida en un array de tamaño fijo, o sea, de acceso rápido.
Pues no te sé decir ...
<pensando> ... yo creo que el problema no es borrar un fichero ya que en Linux se marca como borrado, pero no se tocan los bloques de datos. El problema es entrar en los directorios y borrar los miles (o millones) de ficheros que haya en ese directorio. En este último caso, el algoritmo de acceso y lectura de ficheros en un directorio, es el cuello de botella. Si tu filesystem es bueno manejando árboles de directorios, ganarás mucho.
Otra cosa a tener en cuenta es que XFS cachea muchos datos por lo que algunas operaciones se ven mejoradas y otras no. </pensando>
No, se refieren a borrar un único fichero grande. Observa, voy a probar con 4.4 GiB: *** ext3: (disco de 7200 rpm, 160 GB) (rw,noatime,acl,user_xattr) nimrodel:~ # time dd if=/dev/zero of=/bigfile bs=1M count=4482 4482+0 records in 4482+0 records out 4699717632 bytes (4.7 GB) copied, 154.423 seconds, 30.4 MB/s real 2m34.808s user 0m0.052s sys 0m20.909s nimrodel:~ # time rm /bigfile real 0m4.007s <=== user 0m0.004s sys 0m0.700s *** reiserfs: (rw,acl,user_xattr) nimrodel:~ # time dd if=/dev/zero of=/xtr/bigfile bs=1M count=4482 ; time rm /xtr/bigfile 4482+0 records in 4482+0 records out 4699717632 bytes (4.7 GB) copied, 104.318 seconds, 45.1 MB/s real 1m44.433s user 0m0.032s sys 0m20.525s real 0m1.256s <=== user 0m0.000s sys 0m1.044s *** xfs: (rw,noatime) nimrodel:~ # time dd if=/dev/zero of=/other/bigfile bs=1M count=4482 4482+0 records in 4482+0 records out 4699717632 bytes (4.7 GB) copied, 121.025 seconds, 38.8 MB/s real 2m1.054s user 0m0.060s sys 0m19.721s nimrodel:~ # ls -lh /other/bigfile -rw-r--r-- 1 root root 4.4G Oct 5 13:14 /other/bigfile nimrodel:~ # time rm /other/bigfile real 0m0.484s <=== user 0m0.000s sys 0m0.220s Observa que xfs borra en medio segundo los 4.4 GiB y ext3 tarda 4 segundos. El reiserfs es bastante rápido tanto en la creacion como el borrado, pero sigue ganando xfs. (Me he convertido a los iB ;-) ) Si se observa los tiempos de cpu empleados en el borrado (.7 ext3, .22 xfs) se deduce que el tiempo gastado en ext3 es mayormente tiempo de espera al disco, no tiempo de computación.
[...]
Lo que no se es porqué los de mythtv no usan una partición raw para el buffer circular de recepción/visionado.
El usar raw implica "ignorar" las cachés y los buffers y acceder directamente al dispositivo. Esto para vídeo no es tan bueno porque lo que te interesa es que el streaming se haga desde memoria (más rápido y menos latencia) que desde disco. Además, si dos procesos están 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 más util para otros ficheros del proceso normal del sistema, que se enlentece globalmente. Creo que en esos casos es más eficaz una caché dedicada al proceso en cuestión, o un bufer de lectura grande; es decir, limitar el tamaño de caché dedicado a ese proceso. En mis tiempos que me ganaba los garbanzos programando en dos lo noté: la copia de ficheros era muy rápida si a la función 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 podrían juntar, en teoría). Sin caché de sistema te ahorras un movimiento de memoria. 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.
Bueno, en realidad recomendaban JFS, pero prefiero XFS. No iba a dedicarle una partición gigante a él solito, y sólo para probarlo.
Yo estuve un tiempo probando JFS y no me gustó una cosa: es poco fiable si se compila como módulo :( Si quieres que sea fiable y no perder datos ... inclúyelo 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. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFJPGetTMYHG2NR9URAkwIAKCY30mxyBdA/NR9XAImmgQepaIiuACfRWuy K2tkZUUO25ecUlNUrttjniw= =p0Sr -----END PGP SIGNATURE-----