JFFS2 es un sistema de ficheros con soporte para transacciones especializado en memorias Flash, nace como sucesor de JFFS y será sucedido por JFFS3.

• Funcionamiento sobre dispositivos NAND. Esto requiere una considerable carga de trabajo debido al acceso secuencial en E/S y que no puede ser mapeado en memoria para lectura.
• Enlaces duros, inexistentes en JFFS1.
• Compresión. 3 algoritmos se utilizan: zlib, rubin y rtime.
• Incremento de prestaciones. Con el cambio de recolector de basura en JFFS2 reduce toda la E/S innecesaria existente en JFFS1.

En el diseño de JFFS2 se han modificado varias cuestiones:

• Sigue habiendo nodos pero se dividen en dos tipos: inodos - una cabecera con metadatos, seguida por una carga de datos (si hay) donde la carga comprimida está limitada a una página. Por otro lado, están los nodos "dirent" - entradas de directorio donde cada una guarda un nombre y un número de inodod. Los enlaces duros se representan como nombre diferentes con el mismo número de inodo. El número de inodo 0 representa un no-enlace.

• No hay un registro circular. En cambio, JFFS2 se maneja en bloques, una unidad del mismo tamaño que el segmento borrado de un medio flash. Los bloques son rellenados de una vez, con nodos de abajo arriba. Un bloque limpio es aquel que contiene sólo nodos válidos. Un bloque sucio contiene al menos un nodo obsoleto (igual significado que en JFFS1). Un bloque libre no contiene nodos.

• El recolector de basura trabaja de fondo, convirtiendo bloques sucios en bloques libres. El mecanismo que sigue es copiar los nodos válidos a la cabeza del registro y se salta los obsoletos. Una vez hecho esto, borra el bloque y etiqueta con un marcador especial (para evitar problemas si la energía se pierde en mitad de una operación de borrado). Para hacer más abstracto y prevenir borrados de ser demasiado concentrado en sistemas de ficheros estáticos, el recolector de basura consumirá de manera ocasional bloques limpios.

• Como en JFFS, el montaje puede ser muy lento, ya que todos los nodos deben ser escaneados. Puede convertirse en un problema grande con los dispositivos de más de un Gigabyte de capacidad.

• El uso de la funcionalidad "Ejecución en el lugar" (eXecution In Place o XIP) en JFFS2, lo que significa que se podrían ejecutar directamente programas desde la memoria Flash a diferencia de la copia a RAM que se hace en la actualidad. Los principales inconvenientes son la compresión y un gran esfuerzo sin mucha recompensa lo que lo hace poco atractivo, únicamente para sistemas sólo lectura se podría pensar en un sistema de ficheros sólo lectura como ROMFS.

• Mejorar la tolerancia a fallos, la necesidad de mejorar la detección de errores de bit. En la actualidad solo hay un CRC de 32-bit que no corrige errores, característica fundamental en NAND flash que tienen menor tolerancia que las NOR.

• Reducir los requerimientos de espacio del recolector de basura. En la actualidad se necesitan 5 bloques limpios para permitir la escritura de un bloque nuevo, sería ideal que fuese de 2 o 3 para NAND y de 1 para NOR.

• Soporte a transacciones. Ideal para aplicaciones de bases de datos, implementar un sistema de transacciones sobre JFFS2 puede ser más ineficiente que si lo hiciese el propio JFFS2.

• JFFS
• YAFFS

• Woodhouse, David. JFFS: The Journalling Flash File System Archivado el 10 de octubre de 2004 en Wayback Machine..
• Página oficial de JFFS2 Archivado el 24 de febrero de 2021 en Wayback Machine. (en inglés)