Buenas, 2014-08-04 18:21 GMT+02:00 Emmanuel Brenes <brenillos@hotmail.com>: > El 04/08/2014 08:12, Manolo Díaz escribió: > >> El lunes, 4 ago 2014 a las 15:24 horas (UTC+2), >> Francisco SG escribió: >> >>> El día 4 de agosto de 2014, 14:55, Manolo Díaz <diaz.manolo@gmail.com> >>> escribió: >>>> >>>> El lunes, 4 ago 2014 a las 14:40 horas (UTC+2), >>>> Francisco SG escribió: >>>> >>>>> Yo entiendo que ese comportamiento es el deseable, en un caso así, >>>>> pierdes los últimos cambios (esto es inevitable), luego se reconstruye >>>>> el journal, se aplica si es posible y si no se descarta y a funcionar. >>>> >>>> >>>> Entiendo entonces que la restauración a partir del journal había que >>>> hacerla manualmente y que perdí ese fichero por ignorancia. ¿Es así? >>>> >>> >>> Me temo que no... por defecto, las escrituras se considera "realizada" >>> cuando se escribe a disco, se escriben los metadatos y se elimina del >>> log, esto era una operación de tal modo que la interrupción abrupta no >>> deje una operación a la mitad lo que provoca una inconsistencia en el >>> FS que es lo que hay que evitar a toda costa, así, sólo pierdes los >>> últimos cambios, y te quedas con ficheros quizás con información >>> antigua (unos segundos) pero operativos, lo cual es maravilloso >>> comparado con tener que reconstruir el árbol y buscar bloques etc, >>> etc. Aunque todo este funcionamiento se puede variar con parámetros, >>> incluso puedes poner el journal ¿en un SSD? por ejemplo ;-) pero te >>> tiene que gustar el riesgo o conocer bien lo que se hace, que no es mi >>> caso :-D >>> >>> Por lo tanto, entiendo que lo normal es quedarte con la información >>> del FS consistente y si tienes suerte recuperar el journal... cosa >>> creo que bastante improbable. Pero tampoco me creas del todo que veo >>> que las cosas han mejorado bastante. >>> >>> Un saludo >>> >> >> Gracias por la aclaración. Saludos. >> > > Bastante enriquecedor salió el tema :-D eso es lo que quería ver :-P > > ¡Muchas gracias por contestar, Francisco! > > Ahora, según el entorno de pruebas que pretendo hacer (Máquinas virtuales, > ni loco en mi máquina) tendré las opciones por defecto de cada FS, y les > daré un archivo normal (10 GB) y lo moveré, borraré e incluso veré si puedo > crearlo... el detalle sobre la carga, según he visto, JFS lo maneja mejor > que los demás, un tipo de "menos carga, pero un poco más lento", no > obstante, las pruebas dirán que tanta verdad hay, así como la verdadera > diferencia en entornos un poco más cargados. Claro, tampoco soy experto en > temas de pruebas, así que será "a la mano de Dios" :-P > > Con gusto pondré mis resultados, trabajaré con XFS, JFS y Ext4, a ver qué es > mejor. Al ser máquina virtual, supongo, es más sencillo aunque una prueba > "bare hardware" (obvio, aplicado al contexto de directo sobre un computador, > tipo Phoronix) sería ideal pero es lo que se tiene por ahora. > > ¡Saludos y gracias nuevamente! Me sorprende que nadie hable en este hilo de monitorizar las constantes del sistema mientras haces tu trabajo con esos ficheros de más de 10 GB y también me sorprende que nadie pregunte qué tipo de procesamiento haces con esos ficheros. Ejecuta "vmstat 1", "iostat 1" y iotop, mientras trabajas con el fichero, a ver si te canta algo. No creo que el sistema de ficheros te vaya a influir mucho. ¿Cómo lo tienes de lleno?, dicen que por encima del xx % empieza a empobrecerse el rendimiento. Por otro lado, si tienes espacio libre y tienes lvm, puedes probar el script adjunto (modificando las variables del principio y mirando que no te vaya a destrozar nada .... ), quizás sustituyendo el "cat" por el comando que tú uses para abrir el fichero y trabajar con él, para ver la diferencia entre sistemas de ficheros (eso sí, un sistema de ficheros con un único fichero no es lo mismo ... si tienes mucho espacio podrías incluso duplicar el sistema de ficheros origen). Un saludo
Attachment:
test-fs
Description: Binary data