Usar la memoria RAM para montar sistemas de archivos
A veces es muy conveniente montar un sistema de archivos en RAM. Algunos motivos comunes:
- Estamos usando un entorno live cd o similar y necesitamos una zona de lectura y escritura.
- Queremos que los cambios en un sistema de archivos sean temporales, que se puedan deshacer con facilidad. Un ejemplo de esto sería unionFS o mergeFS.
- Queremos una zona de trabajo no persistente de alta velocidad. Por ejemplo, para alojar los ficheros intermedios creados durante un proceso de compilación. Son ficheros de usar y tirar que no necesitan ser persistentes, pero cuyo rendimiento de acceso debería ser lo más elevado posible.
- Podemos necesitar almacenar datos en un sistema de archivos, pero no queremos que esos datos se almacenen de forma persistente en ningún sitio, que no dejen rastro ni siquiera accidental. Por ejemplo, por contener claves criptográficas.
- Necesitamos espacio temporal y tenemos RAM más que suficiente para albergar ese contenido.
En todos estos casos es muy importante que no nos importe que el sistema de archivos desaparezca si se reinicia el ordenador, ya que se almacena en RAM.
Veamos algunas formas de utilizar RAM para montar un sistema de archivos no persistente en entornos Linux:
-
ZRAM:
ZRAM nos permite crear un dispositivo de bloques con compresión transparente utilizando la memoria RAM del ordenador. Si los datos que metemos en ese dispositivo se pueden comprimir con facilidad, ocuparán mucha menos RAM que su tamaño.
En artículos previos ya he explicado con detalle qué es ZRAM y cómo utilizarlo para almacenar el espacio de intercambio del ordenador. Por ejemplo:
- Cómo y por qué utilizar ZRAM como "espacio de intercambio" o SWAP.
- Comparación de algoritmos de compresión ZRAM en Raspberry PI.
No voy a repetir los detalles aquí.
El proceso sería algo así:
root@jcea:~# zramctl -f -s 10G -a zstd /dev/zram4 root@jcea:~# mkfs.ext4 /dev/zram4 mke2fs 1.45.5 (07-Jan-2020) Discarding device blocks: done Creating filesystem with 2621440 4k blocks and 655360 inodes Filesystem UUID: 07ca5983-89c5-485b-9c34-7c55b59882c1 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632 Allocating group tables: done Writing inode tables: done Creating journal (16384 blocks): done Writing superblocks and filesystem accounting information: done root@jcea:~# mount /dev/zram4 /tmp/ram/ root@jcea:~# df -k /tmp/ram/ Filesystem 1K-blocks Used Available Use% Mounted on /dev/zram4 10255636 36888 9678076 1% /tmp/ram
Una vez que hemos terminado con ese sistema de archivos, podemos destruirlo con facilidad:
root@jcea:~# umount /tmp/ram root@jcea:~# zramctl -r /dev/zram4
-
Ventajas:
-
Compresión transparente: la ocupación real de memoria depende de lo fácil que sea comprimir los datos. Dependiendo de los datos, podríamos guardar más contenido que RAM disponible.
-
Se puede crear un sistema de archivos muy grande porque la memoria RAM se va consumiendo a medida que hace falta, no se asigna de forma estática al crear el ZRAM. De hecho, si borramos ficheros, se liberará memoria de forma dinámica.
-
Los datos guardados en una ZRAM nunca tocarán el disco duro del ordenador. Se almacenan solo en memoria aunque nos quedemos sin espacio.
Esto es importante si, por ejemplo, estamos guardando temporalmente (se perderán si se reinicia el ordenador) claves criptográficas u otros ficheros confidenciales.
Advertencia
Esto es cierto SOLO si no se está empleando el mecanismo de backend storage de ZRAM. Esto es lo habitual, ya que ese mecanismo hay que configurarlo explícitamente y de forma manual.
-
-
Inconvenientes:
-
Si los datos no se pueden comprimir, se pierde rendimiento intentándolo. En esos casos se puede configurar el ZRAM para usar un algoritmo de compresión simple pero rápido, para que pierda el menor tiempo posible intentando comprimir algo que no se puede comprimir.
No se puede configurar ZRAM para que no comprima en absoluto. Siempre lo va a intentar, aunque podemos elegir el algoritmo que usa.
-
Es un módulo opcional del kernel de Linux. Podría no estar disponible en la máquina donde lo necesitamos.
-
Una vez creado el dispositivo ZRAM, no podemos cambiar su tamaño, aunque podemos crear otros.
Este puede ser un buen motivo para crear dispositivos ZRAM más grandes de lo aparentemente necesario, ya que el espacio ocupado realmente apenas se nota si no se utiliza.
-
Si necesitamos más espacio que la RAM disponible, contando también con la compresión de los datos, no podremos usar este mecanismo, ni siquiera aunque tengamos definidos mecanismos de espacio de intercambio adicionales en el disco duro.
-
Aparte de la sobrecarga de la compresión, existen varias capas intermedias. ZRAM proporciona un dispositivo de bloques sobre el que se formatea un sistema de archivos. Existen otras posibilidades con menos capas.
-
-
RAMFS es un sistema de archivos extremadamente ligero. Básicamente, los ficheros que se meten ahí se mantienen bloqueados en la caché de ficheros de Linux, de forma que siempre están disponibles de forma inmediata. El rendimiento es excepcional, porque los ficheros siempre están en la caché.
Ejemplo:
root@jcea:~# mount -t ramfs - /tmp/ram root@jcea:~# df -k /tmp/ram Filesystem 1K-blocks Used Available Use% Mounted on none 0 0 0 - /tmp/ram
Aunque el espacio disponible se marca como "0", en realidad se puede meter tanto como memoria RAM tengamos.
La destrucción del sistema de archivos es trivial:
root@jcea:~# umount /tmp/ram
- Ventajas:
- El espacio usado crece y decrece de forma dinámica en función de lo que grabamos y borramos en el sistema de archivos.
- No hay un tamaño prefijado. No hay que preveer para no quedarnos cortos, aunque hay que tener precaución para no utilizar tanta RAM que bloquee el ordenador.
- El rendimiento es excepcional.
- El código es pequeño y simple.
- Debido a lo anterior, se trata de una funcionalidad estándar del kernel de Linux. Siempre estará disponible.
- Los datos guardados en una ZRAM nunca tocarán el disco duro del ordenador, se almacenan solo en memoria aunque nos quedemos sin espacio.
- Inconvenientes:
- Los datos ocupan su tamaño. No hay compresión transparente.
- No se puede limitar el tamaño máximo asignado. Si nos pasamos y nos quedamos sin RAM, el ordenador fallará.
- Ventajas:
-
TMPFS es similar a RAMFS, pero permite fijarle un tamaño máximo y utilizará el espacio de intercambio disponible si el ordenador empieza a ir corto de RAM.
El uso es también bastante simple:
root@jcea:~# mount -t tmpfs -o size=0 - /tmp/ram root@jcea:~# df -k /tmp/ram Filesystem 1K-blocks Used Available Use% Mounted on - 0 0 0 - /tmp/ram
Aquí estoy indicando un tamaño de "0", que implica "sin límites". Si no, por defecto el tamaño estaría limitado a la mitad de la RAM del ordenador. Echa un vistazo a la documentación de TMPFS para ver qué otros parámetros se pueden configurar.
La destrucción del sistema de archivos es trivial:
root@jcea:~# umount /tmp/ram
-
Ventajas:
-
Se puede limitar el tamaño máximo, para evitar pasarnos y bloquear el ordenador.
-
Si vamos escasos de RAM y existe espacio de intercambio, lo utilizará.
Esto es interesante, por ejemplo, si el espacio de intercambio es un dispositivo ZRAM. Con esta configuración tenemos lo mejor de ambos mundos: los ficheros "calientes" permanecen en la caché del sistema operativo y, si vamos cortos de RAM, los datos que hace más tiempo que no se usan se comprimen de forma transparente usando la ZRAM.
Esta es una configuración que yo uso con frecuencia.
-
-
Inconvenientes:
- Es un módulo opcional del kernel de Linux. Podría no estar disponible en la máquina donde lo necesitamos.
- Si el ordenador tiene definido espacio de intercambio, algunos datos pueden acabar en el disco duro. No debería usarse TMPFS en una máquina configurada con espacio de intercambio en disco duro, si queremos usarlo para contener ficheros confidenciales.
-