¿Qué sistema de archivos Linux funciona mejor con SSD?

Pregunta:

De wiki:

La función TRIM vital es compatible con el sistema operativo Linux a partir del kernel 2.6.33 (disponible a principios de 2010). Sin embargo, el soporte entre varios sistemas de archivos sigue siendo inconsistente o no está presente. El software de instalación tampoco lleva a cabo una alineación adecuada de las particiones.

Entonces, ¿qué sistema de archivos funciona mejor para SSD y admite la alineación de partición TRIM + durante la instalación y está disponible en Ubuntu?

Respuesta:

Respuesta corta

  • Elija ext4 y móntelo con la opción de discard para compatibilidad con TRIM , o use FITRIM (ver más abajo). Utilice también la opción noatime si teme "desgaste de SSD".

  • No cambie su programador de E / S (CFQ) predeterminado en servidores de aplicaciones múltiples , ya que proporciona equidad entre los procesos y tiene soporte SSD automático. Sin embargo, use Deadline en computadoras de escritorio para obtener una mejor capacidad de respuesta bajo carga.

  • Para garantizar fácilmente la alineación adecuada de los datos, el sector inicial de cada partición debe ser un múltiplo de 2048 (= 1 MiB). Puede usar fdisk -cu /dev/sdX para crearlos. En distribuciones recientes, se encargará automáticamente de esto.

  • Piense dos veces antes de usar swap en SSD. Probablemente será mucho más rápido en comparación con el intercambio en HDD, pero también desgastará el disco más rápido (lo que puede no ser relevante, ver más abajo).

Respuesta larga

  • Sistemas de archivos:

Ext4 es el sistema de archivos de Linux más común (bien mantenido). Proporciona un buen rendimiento con SSD y admite la función TRIM (y FITRIM) para mantener un buen rendimiento de SSD a lo largo del tiempo (esto borra los bloques de memoria no utilizados para un rápido acceso de escritura posterior). NILFS está especialmente diseñado para unidades de memoria flash, pero enrealidad no funciona mejor que ext4 en los puntos de referencia. Btrfs todavía se considera experimental (y realmente no funcionan mejor , ya sea ).

  • Rendimiento SSD y TRIM:

La función TRIM borra los bloques SSD que el sistema de archivos ya no utiliza. Esto optimizará el rendimiento de escritura a largo plazo y se recomienda en SSD debido a su diseño. Significa que el sistema de archivos debe poder informar a la unidad sobre esos bloques. La opción de montaje de discard de ext4 emitirá dichos comandos TRIM cuando se liberen los bloques del sistema de archivos. Este es un descarte en línea .

Sin embargo, este comportamiento implica una pequeña sobrecarga de rendimiento. Desde Linux 2.6.37, puede evitar el uso de discard y optar por descartar por lotes ocasionalmente con FITRIM (por ejemplo, desde el crontab). La utilidad fstrim hace esto (en línea), así como la opción -E discard de fsck.ext4 . Sin embargo, necesitará una versión "reciente" de estas herramientas.

  • Desgaste SSD:

Es posible que desee limitar las escrituras en su unidad, ya que las SSD tienen una vida útil limitada a este respecto. Sin embargo , no se preocupe demasiado , el peor SSD de 128 GB de la actualidad puede admitir al menos 20 GB de datos escritos por día durante más de 5 años (1000 ciclos de escritura por celda). Los mejores (y también los más grandes) pueden durar mucho más: es muy probable que para entonces los hayas reemplazado.

Si desea usar swap en SSD, el kernel notará un disco no rotacional y aleatorizará el uso de swap (nivelación de desgaste a nivel del kernel): verá un SS (estado sólido) en el mensaje del kernel cuando el swap esté habilitado:

Añadiendo el intercambio 2097148k en / dev / sda1. Prioridad: -1 extensiones: 1 a través: 2097148k SS

  • Programadores de E / S:

Además, estoy de acuerdo con la mayor parte de la respuesta de aliasgar (incluso si la mayor parte se ha copiado ilegalmente de este sitio web ), pero debo estar parcialmente en desacuerdo con la parte del planificador . De forma predeterminada, el programador de fechas límite está optimizado para discos rotativos, ya que implementa el algoritmo del elevador . Entonces, aclaremos esta parte.

Respuesta larga en programadores

A partir del kernel 2.6.29, los discos SSD se detectan automáticamente y puede verificar esto con:

cat /sys/block/sda/queue/rotational

Debería obtener 1 para discos duros y 0 para SSD.

Ahora, el programador CFQ puede adaptar su comportamiento basándose en esta información. Desde linux 3.1, el archivo cfq-iosched.txt documentación del kernel dice :

CFQ tiene algunas optimizaciones para SSD y si detecta un medio no rotacional que puede soportar una mayor profundidad de cola (múltiples solicitudes en vuelo a la vez), […].

Además, el programador Deadline intenta limitar los movimientos de cabeza desordenados en discos rotacionales, según el número de sector. Citando el documento del kernel deadline-iosched.txt , descripción de la opción fifo_batch :

Las solicitudes se agrupan en “ lotes '' de una dirección de datos particular (lectura o escritura) que se atienden en orden creciente de sector.

Sin embargo, ajustar este parámetro a 1 cuando se usa un SSD puede ser interesante:

Este parámetro ajusta el equilibrio entre la latencia por solicitud y el rendimiento agregado. Cuando la baja latencia es la preocupación principal, cuanto más pequeño, mejor (donde un valor de 1 da como resultado un comportamiento por orden de llegada). El aumento de Fifo_batch generalmente mejora el rendimiento, a costa de la variación de latencia.

Algunos puntos de referencia sugieren que hay poca diferencia de rendimiento entre los diferentes programadores. Entonces, ¿por qué no recomendar la equidad ? cuando CFQ rara vez es malo en el banco . Sin embargo, en las configuraciones de escritorio, generalmente experimentará una mejor capacidad de respuesta utilizando Deadline bajo carga, debido a su diseño (aunque probablemente a un costo de rendimiento más bajo).

Dicho esto, un mejor punto de referencia intentaría usar Deadline con fifo_batch=1 .

Para usar Deadline en SSD de forma predeterminada, puede crear un archivo, digamos /etc/udev.d/99-ssd.rules siguiente manera:

# all non-rotational block devices use 'deadline' scheduler
# mostly useful for SSDs on desktops systems
SUBSYSTEM=="block", ATTR{queue/rotational}=="0", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/scheduler}="deadline"

Leave a Comment

Your email address will not be published.

Scroll to Top

istanbul avukat

-

web tasarım