[intronauta]

 Cita: Originalmente Escrito por gembol

Uy, a ver si te puedo aclarar algo, pero la verdad es que lo mejor que podrías hacer es buscarlo en el hilo de recopilación de tutoriales. Para llegar a entender lo que muchos saben aquí hay que leer mucho (yo sigo en ello, jajaja). Mira, el hilo es éste:

IMPORTANTISIMO <<<<:::Recopilación de tutoriales:::>>>>

Básicamente y ya que trabajo de informático, te respondo a algo:

El kernel es el núcleo del sistema operativo (Android en este caso) y se encarga de relacionar el resto del sistema con el hardware del equipo (memoria interna, externa, RAM, cámara, wifi, bluetooth,...). Además, permite hacer algunas modificaciones para que toda esta comunicación hardware - software sea más veloz.

En el caso de nuestro móvil, Samsung decidió utilizar como base para la memoria un sistema de archivos que no es el más comunmente usado en linux. Samsung utiliza RFS cuando lo normal en linux es cualquier variante de EXT (2,3,4) o JFS. La verdad es que no sé por qué hicieron eso, pero bueno, así fue. La cuestión es que cada vez que el móvil quiere leer/escribir algo en memoria tiene que hacer la conversión ext-rfs o similar, por lo que se pierde un poco de tiempo por parte del procesador. Esto es lo que llamamos LAG (tiempo perdido).

El lagfix son medidas que se implementan en los kernel modificados para convertir las particiones a un sistema de archivos ext o jfs y así quitarnos esa pérdida de tiempo de encima.

Y para finalizar, la ROM es el conjunto de Kernel + Modem + Resto de sistema Android + Programas + Optimizaciones que preparan los cocineros queridos por todos para que tengamos lo mejor de lo mejor.

Espero haberte ayudado!!!!

Saludos!

No estoy del todo de acuerdo.

No hay conversión de ext a rfs por defecto, ya que el sistema de archivos es el que el programador implemente. El kernel de linux viene con soporte nativo para varios filesystem y aunque las distribuciones linux tradicionalmente trabajen con EXT, no quiere decir que esté siempre activo. Puedes tener un kernel con btrfs, xfs, reiserfs,... para tu sistema sin necesidad de EXT.

Samsung decidió usar RFS porque para escribir sobre una memoria NAND necesitas un sistema de archivos que sea capaz de hacerlo, y la mayoría de los existentes están adaptados para discos rígidos y los que funcionan para memorias NAND aun están verdes (excepto yaffs). Entonces no le quedó otra que crear una capa FTL (wear level) que se encargase de adaptar como escribe el sistema de archivos tradicional a como se necesita escribir en una memoria NAND por su arquitectura.

RFS al final no es más que un sistema FAT avanzado con journaling, posix y alguna cosa más para darle más seguridad, integridad de datos y adaptarlo a las NAND a través de la capa FTL, y lo mismo pasa con ext4, jfs o cualquier otro sistema de archivos que utilicemos y para los que tenemos soporte en los custom kernel, todos pasan por FTL.

HTC apostó por YAFFS/YAFFS2 para trabajar sobre la NAND, que está creado específicamente para trabajar sobre ellas y hace de filesystem y wear leveling a la vez.

Algunos dicen que yaffs elimina cuellos de botella que supuestamente se producen en algunos buffers en los terminales de samsung, pero no son más que especulaciones. Parece ser que el mayor problema con RFS y el famoso lag que produce viene de algunas características exageradamente implantadas con fsync, que obliga a escribir continuamente sin cachear e incluso escribe en el journaling para notificar que ha leído , y opciones de montaje como "atime", pero parece que han sido mayormente corregidas o suavizadas en los últimos kernel jpx y superiores. Hay bastantes usuarios que ya no utilizan lagfix.

El lagfix al final no es más que sustituir rfs por otro sistema de archivos más "amable", capaz de cachear datos para no estar continuamente escribiendo y que implemente suficiente seguridad e integridad a los datos a la vez de ofrecer buenos ratios de I/O, como por ejemplo EXT4 con opciones de montaje específicas para adaptarlo a un smartphone.

El que google apueste por ext4 en futuras versiones plantea varias incógnitas, como por ejemplo si será una nueva revisión del ext4 tradicional para adaptarlo a la arquitectura nand pero con las bondades de ext4 o necesitará igualmente de una capa (wear level).

Ya veremos.