¿Debo usar btrfs o Ext4 para mi SSD?


16

¿Debo usar btrfs (con las opciones descartar, comprimir = lzo y space_cache) o Ext4 (con la opción descartar) para el SSD para mi partición raíz de escritorio amd64 Ubuntu 11.10 (Oneiric) de mi máquina de oficina?

/ home será un HDD, por lo que la fiabilidad de fs afecta al sistema operativo, no a mis datos.

Respuestas:


13

Según las pruebas de phoronix , siempre depende de muchos factores. En un caso, lo Btrfshará mucho mejor que EXT4cuando lee archivos grandes en un SSD. Del mismo modo, al considerar el rendimiento de las transacciones en disco, Ext4puede funcionar mejor que el posterior.

Puede echar un vistazo a estas pruebas aquí , aquí y aquí (ADVERTENCIA: artículos largos).

Pero en resumen, Btrfs en este momento no tiene una ventaja de rendimiento cuantitativa sobre el sistema de archivos EXT4 , incluso cuando se usa en modo SSD.

Entonces puedes elegir más Ext4por ahora.


2
Los artículos son septiembre de 2011, 9 de agosto de 2010 y 29 de mayo de 2009, respectivamente. Centrándome en lo último porque supongo que btrfs estaría evolucionando en los últimos 2 años. El gráfico btrfs + LZO en la página 4 es sorprendente para el rendimiento de lectura y escritura secuenciales, pero btrfs funciona mal con escrituras aleatorias, por lo que definitivamente no es bueno para btrfs para DB e imágenes VM. Supongo que con la partición raíz la carga es en su mayoría lecturas aleatorias, para lo cual no es mucho mejor que ext4.
Graham

Dentro de unos años, Btrfs se convertirá en una mejor opción que EXT4. Es un sistema de archivos más prometedor :)
NBK

7

Para aquellos que tropezaron con esta pregunta en 2016 ... Use ext4. Intenté btrfs y la diferencia es sustancial. Durante un período de 10 días, las IO escritas en ext4 ascendieron a 17.800 sectores. Btrfs? 490,400 sectores. Mismo SSD, sistema de archivos idéntico, particiones diferentes. Básicamente, la misma carga de trabajo.

Tanto ext4 como btrfs quedan "silenciosos" cuando no hay actividad de escritura en la unidad. Eso es bueno.

Ext4 escribirá los datos modificados, más algunos gastos generales. Los gastos generales se refieren a los datos escritos. Una escritura 4K (1 bloque) empuja alrededor de 50-80 bloques de sobrecarga en la próxima confirmación. (El diario ext4 está totalmente habilitado)

Modifique un solo bloque de 4K en btrfs y empujará entre 4000-5000 bloques de sobrecarga en la próxima confirmación. La confirmación predeterminada es de 30 segundos, creo. Yo usé 120.

Ahora, depende de cómo use el SSD. Como root, generalmente hay una secuencia de escrituras bastante constante y de bajo nivel. Archivos de registro, archivos de deriva ntp, reconstrucciones de man db, actualizaciones de topología opensm, etc. Cada evento martillará una unidad btrfs con otras escrituras 4000-5000.

Los números de 10 días anteriores son para mi SSD de "escritura limitada". La mayor parte de esos 17.800 sectores fueron el resultado de una actualización del sistema más pequeña. Uno de los btrfs copia no sufrió. Mis escritores son, exactamente, ntp drift, topología opensm y actualizaciones de db man (todas las noches). Nada más golpea ese disco, excepto cosas iniciadas activamente como actualizaciones del sistema vim /etc/whatever, etc.

En general, los SSD sufrirán muchas escrituras, de verdad. Simplemente no puedo ver el punto de desperdiciarlos solo porque los medios de comunicación están persiguiendo conejitos y arcoiris. Si desea pagar este precio por VACA, hágalo. Para "rendimiento", no tanto. Es un SSD y probablemente podría poner el peor "sistema de archivos" conocido por el hombre, y aún así obtener un cierto nivel de rendimiento, solo por la fuerza bruta. Ext4 no es, de lejos, el peor sistema de archivos conocido por el hombre.

Sin cheque mensual de fs. Prueba el guión a continuación. Es un hack 100%, no funcionará para puntos de montaje md,

#! /bin/bash
dev=`cat /proc/mounts | grep " $1 " | awk '{print $1}'`
x=`basename $dev`
vmnam=`lsblk $dev -o MOUNTPOINT,PKNAME | grep "$1" | awk '{print $2}'`
vmx=`vmstat -d | grep $vmnam | awk '{print $8}'`
lbax=`smartctl -a $dev | grep LBA | awk '{print $10}'`
tmpnam=`mktemp XXX`
echo "Tracking device: $dev, mounted on $1 (vmstat on $vmnam)"
tim=`date +%s`
timx=`date +%s`
while true
do
    vm=`vmstat -d | grep "$vmnam" | awk '{print $8}'`
    lba=`smartctl -a $dev | grep LBA | awk '{print $10}'`
    if [ "$vm" != "$vmx" ]
    then
        tim=`date +%s`
        dif=`dc <<< "$vm $vmx - p"`
        lbad=`dc <<< "$lba $lbax - p"`
        timd=`dc <<< "$tim $timx - p"`
        echo `date` " (sec=$timd) writes=$vm (dif=$dif) (lba=$lbad)"
        vmx="$vm"
        lbax="$lba"
        timx="$tim"
        find "$1" -mount -newer "$tmpnam" -print | grep -v "/tmp"
        touch "$tmpnam" 
    fi
    sleep 1 
done

Le indicará cuántos bloques se escribieron, de acuerdo con la unidad en sí, y exactamente qué archivos se actualizaron. Necesita privs de raíz. Ver por ti mismo. Ejecuto SSD en el sistema de archivos raíz y llamo al script stat.sh. Entonces...sudo ./stat.sh /


No me gusta tu método de comparación. Por ejemplo, el cheque mensual de fs entró en acción y obtuviste esos resultados. Btrfs está predeterminado en casi todas partes ahora, y por una buena razón.
Barafu Albino

Sin cheque mensual de fs. Prueba el siguiente script. Es un hack 100%, no funcionará para puntos de montaje md, etc ...
wkirk

2
¿Por qué una gran sobrecarga de escritura? Usted dijo que 1 bloque creó 50-80 bloques escritos incluso en ext4, es decir, 40 veces más de lo necesario. ¿Por qué?
Golar Ramblar

Me pregunto si esto sigue siendo cierto a fines de 2018. En mi prueba, comparé la cantidad escrita de acuerdo con iotop y smartctl y descubrí que esta última reclamó 3 veces la cantidad que la anterior (ext4).
Michael

2

La última vez que lo probé, y aún no he escuchado algo diferente en ninguna parte, ext4 come medios de estado sólido. (unidades de memoria USB, unidades de estado sólido, etc.) No recomiendo usarlo en dicho dispositivo. Use ext3 en su lugar. Para la mayoría de los casos en SSD, no podrá notar la diferencia de todos modos.

BTRFS aún no es bastante estable. Sin embargo, es lo suficientemente estable para aplicaciones no críticas. Es lo que uso para hacer unidades flash de arranque. Si usa compress = zlib y ssd como sus opciones de montaje, la compresión compensará las velocidades de escritura más bajas de la mayoría de los medios de estado sólido y el ssd cambia el algoritmo de asignación a uno que funcione significativamente mejor en dichos dispositivos y compensará cualquier pobre nivelación de desgaste por parte del hardware. El único área de rendimiento que sigue siendo un problema es que las llamadas de sincronización son lentas. Esto no es un problema para uso general, pero las llamadas dpkg se sincronizan después de cada operación, por lo que la instalación y actualización del software puede ser lenta. BTRFS también ofrece instantáneas y otras características avanzadas que son bastante útiles bajo ciertas circunstancias.

Si decide utilizar BTRFS, asegúrese de utilizar una distribución con el kernel 3.2.0-2 o posterior. 3.1.x es viable si es necesario. Para los núcleos más antiguos, deberá compilar los últimos módulos BTRFS usted mismo. Los incorporados son casi estables, pero la corrección de errores no funciona en las versiones anteriores, lo que puede dejarlo en un riachuelo si algo sale mal. Las últimas versiones tienen fsck que en realidad puede reparar las fallas más comunes.

Una advertencia final, he escuchado informes de que los archivos de intercambio en un sistema de archivos BTRFS lo corromperán. Es posible que este problema se haya solucionado, pero asegúrese de verificarlo cuidadosamente antes de implementar uno.

Si necesita ayuda para configurar BTRFS de la forma que desee, avíseme. He hecho un par de locos que funcionan bastante bien para cosas específicas.


2

No usaría ext4 en una unidad de estado sólido basada en evidencia anecdótica y mi propia experiencia que sugiere que ext4 puede disminuir en gran medida la vida útil de un SSD debido a la cantidad de lecturas y escrituras asociadas con el sistema de archivos. Un artículo que leí recientemente sugirió que ext4 no optimizado (teniendo en cuenta el tamaño de página, etc.) en un SSD puede reducir la vida útil del disco a la mitad. Después de una semana de problemas, he llegado a la conclusión de que mis propios SSD solo han durado ocho meses debido a este problema. Si usa un SSD, lea mucho sobre cómo optimizar el sistema de archivos en función de cosas como el tamaño de página flash que puede ser diferente del tamaño de cilindro típico para el que está configurado el sistema de archivos.


2
¿Puede proporcionar un enlace u otra información de identificación para el artículo que lee?
Eliah Kagan

Trataré de encontrar ese artículo específicamente. Recuerde que esa declaración se encontró en Internet mientras navegaba en la tienda de cigarros. En pocas palabras, lea y haga la tarea antes de usar ext4 en un SSD. Mire los artículos sobre cosas como TRIMM y optimización. Hagas lo que hagas, no seas como yo y comienza a recibir errores de E / S en comandos como "reinicio de sudo" después de ocho meses.
user75153
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.