[pyar] [Aporte] Para los que estan escribiendo proyectos.

QliX=D! [aka EHB] qlixed en gmail.com
Jue Oct 21 18:39:35 ART 2010


2010/10/21 Juan Carlos Ojeda <juancarlospaco en gmail.com>:
>
>
[...]

> Correcto!, eso es lo que queria decir.
> Por eso en realidad hacer un file.close() con os.fsync() no sirve hoy dia
> con EXT4 o superior.

Que????. - No nada q ver segun tengo entendido :)

A ver.
Hay 3 capas en el cacheo de disco si mal no recuerdo, y se agrega una
"semi cuarta" capa en los journals FS:
1) Aplicacion (digamos q con fflush de C lo salvas)
2) VFS o FS (Con un Sync le indcas que baje todo a disco)
2.b) Journal FS: El sync solo asegura que el Journal se guarde, no que
se modifique el bloque fisico del disco real.
3) Disk Buffer - Buffer de disco Hardware (en controladora digamos).

So, el fflush de C (llamado desde fd.close() de python, o sea desde
close() de C), se encarga de bajar la data del buffer de FDs
(UserSpace) al buffer del VFS (KernelSpace  - Page Cache), ahora el
kernel tiene su tiempo (ej los 5 o 15 segundos que dicen x ahi del vm
write),  en este momento si tenes un Journal FS, el Journal guarda la
data en su log, luego de los 5 o 15 segundos el journal se graba en la
posicion de disco real donde se aloja el archivo. Peeeero tambien se
baja a disco si el buffer de kernelspace se llena.
O sea, en cuanto le diste Flush, en un Journal FS ya tenes tus datos
asegurados, AUNQUE APAGUES la maquina, deberia poder restaurarse desde
el Journal las operaciones que fallaron y no se confirmaron.

Igual estoy buscando mi copia de understanding linux kernel para
chequear unos datos mas...

Saludos

EHB



More information about the pyar mailing list