Verifique el soporte TRIM con BtrFS en SSD


21

Estamos estudiando el uso de BtrFS en una matriz de discos SSD y me han pedido que verifique que BtrFS realmente realice operaciones TRIM al eliminar un archivo. Hasta ahora no he podido verificar que el comando TRIM se envíe a los discos.

Sé que BtrFS no se considera listo para la producción, pero nos gusta la vanguardia, por lo tanto, lo estoy probando. El servidor es Ubuntu 11.04 versión de servidor de 64 bits (mkfs.btrfs versión 0.19). He instalado el kernel de Linux 3.0.0 ya que el registro de cambios de BtrFS indica que el TRIM masivo no está disponible en el kernel que se incluye con Ubuntu 11.04 (2.6.38).

Aquí está mi metodología de prueba (inicialmente adoptada de http://andyduffell.com/techblog/?p=852 , con modificaciones para trabajar con BtrFS):

  • RECORTAR manualmente los discos antes de comenzar: for i in {0..10} ; do let A="$i * 65536" ; hdparm --trim-sector-ranges $A:65535 --please-destroy-my-drive /dev/sda ; done
  • Verifique que la unidad se haya RECORTADO: ./sectors.pl |grep + | tee sectors-$(date +%s)
  • Particionar el disco: fdisk /dev/sda
  • Haz el sistema de archivos: mkfs.btrfs /dev/sda1
  • Montar: sudo mount -t btrfs -o ssd /dev/sda1 /mnt
  • Crea un archivo: dd if=/dev/urandom of=/mnt/testfile bs=1k count=50000 oflag=direct
  • Verifique que el archivo esté en el disco: ./sectors.pl | tee sectors-$(date +%s)
  • Eliminar el archivo de prueba: rm /mnt/testfile
  • Vea que el archivo de prueba se TRIME desde el disco: ./sectors.pl | tee sectors-$(date +%s)
  • Verifique los bloques TRIM'd: difflos dos sectors-*archivos más recientes

En este punto, las verificaciones previas y posteriores a la eliminación aún muestran los mismos bloques de disco en uso. En cambio, debería ver una reducción en el número de bloques en uso. Esperar una hora (en caso de que tarde un tiempo en emitirse el comando TRIM) después de que se elimine el archivo de prueba aún muestra los mismos bloques en uso.

También he intentado montar con las -o ssd,discardopciones, pero eso no parece ayudar en absoluto.

Partición que se creó desde fdiskarriba (mantengo la partición pequeña para que la verificación pueda ir más rápido):

root@ubuntu:~# fdisk -l -u /dev/sda

Disk /dev/sda: 512.1 GB, 512110190592 bytes
255 heads, 63 sectors/track, 62260 cylinders, total 1000215216 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x6bb7542b

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63      546209      273073+  83  Linux

Mi sectors.plscript (sé que esto es ineficiente, pero hace el trabajo):

#!/usr/bin/perl -w

use strict;

my $device = '/dev/sda';
my $start = 0;
my $limit = 655360;

foreach ($start..$limit) {
    printf "\n%6d ", $_ if !($_ % 50);
    my @sector = `/sbin/hdparm --read-sector $_ $device`;
    my $status = '.';
    foreach my $line (@sector) {
            chomp $line;
            next if $line eq '';
            next if $line =~ /$device/;
            next if $line =~ /^reading sector/;
            if ($line !~ /0000 0000 0000 0000 0000 0000 0000 0000/) {
                    $status = '+';
            }
    }
    print $status;
}
print "\n";

¿Mi metodología de prueba es defectuosa? ¿Me estoy perdiendo de algo?

Gracias por la ayuda.


1
Estoy totalmente de acuerdo con probar cosas de vanguardia, pero para que lo sepas, en este momento, btrfs no tiene un fsck que en realidad, ya sabes, arregla las cosas: btrfs.wiki.kernel.org/index.php/Main_Page , así que solo ten cuidado con eso.
Matt Simmons

@ Matt - Buen punto sobre el fsck perdido. Tengo entendido que la primera versión de un fsck debería enviarse dentro de las próximas semanas, por lo que deberíamos estar cubiertos para cuando pasemos a producción. Además, tendremos múltiples copias de nuestros datos, por lo que si perdemos una copia, tenemos al menos dos copias más para restaurar. Pero estoy totalmente de acuerdo en que este no es el sistema de archivos para personas con datos irremplazables por ahora.
Shane Meyers

1
Probablemente no cambie nada, pero también podría intentar ejecutar una syncdespués de ejecutar el archivo.
zebediah49

Quiero decir que intenté ejecutar un syncdespués de eliminar el archivo y los resultados seguían siendo los mismos. Aunque volveré a comprobarlo cuando regrese a la oficina después de que termine el fin de semana.
Shane Meyers

si no te importa sangrar, ¿has considerado zfsonlinux.org ? ZFS nativo (es decir, en el núcleo, no fusible) para Linux. Son cerca de una "liberación" oficial, y tienen centros de referencia disponibles (incluyendo un PPA para Ubuntu - lo suficiente para reconstruir fácil para Debian también)
cas

Respuestas:


4

Entonces, después de muchos días trabajando en esto, pude demostrar que BtrFS sí usa TRIM. No pude hacer que TRIM funcione correctamente en el servidor en el que implementaremos estos SSD. Sin embargo, cuando se prueba con el mismo disco conectado a una computadora portátil, las pruebas tienen éxito.

Hardware utilizado para todas estas pruebas:

  • Crucial m4 SSD 512GB
  • HP DL160se G6
  • LSI LSISAS9200-8e HBA
  • recinto genérico SAS
  • Laptop Dell XPS m1210

Después de muchos intentos fallidos de verificar BtrFS en el servidor, decidí probar esta misma prueba usando una computadora portátil vieja (elimine la capa de la tarjeta RAID). Los intentos iniciales de esta prueba con Ext4 y BtrFS en la computadora portátil fallan (datos no recortados).

Luego actualicé el firmware de la unidad SSD de la versión 0001 (como se entrega de fábrica) a la versión 0009. Las pruebas se repitieron con Ext4 y BtrFS y ambos sistemas de archivos recortaron con éxito los datos.

Para garantizar que el comando TRIM tuviera tiempo de ejecutarse, hice un rm /mnt/testfile && sync && sleep 120antes de realizar la validación.

Una cosa a tener en cuenta si está intentando esta misma prueba: los SSD tienen bloques de borrado en los que operan (no sé el tamaño de los bloques de borrado Crucial m4). Cuando el sistema de archivos envía el comando TRIM a la unidad, la unidad solo borrará un bloque completo; si el comando TRIM se especifica para una parte de un bloque, ese bloque no se TRIM debido a los datos válidos restantes dentro del bloque de borrado.

Entonces, para demostrar de lo que estoy hablando (salida del sectors.plscript anterior). Esto es con el archivo de prueba en el SSD. Los períodos son sectores que solo contienen ceros. Las ventajas tienen uno o más bytes distintos de cero.

Archivo de prueba en la unidad:

24600 .......................................+++++++++++
24650 ++++++++++++++++++++++++++++++++++++++++++++++++++
24700 ++++++++++++++++++++++++++++++++++++++++++++++++++
    -- cut --
34750 ++++++++++++++++++++++++++++++++++++++++++++++++++
34800 ++++++++++++++++++++++++++++++++++++++++++++++++++
34850 +++++++++++++++++++++++++++++.....................

Archivo de prueba eliminado de la unidad (después de a sync && sleep 120):

24600 .......................................+..........
24650 ..................................................
24700 ..................................................
    -- cut --
34750 ..................................................
34800 ..................................................
34850 ......................+++++++.....................

Parece que el primer y el último sector del archivo están dentro de bloques de borrado diferentes del resto del archivo. Por lo tanto, algunos sectores quedaron intactos.

Para llevar esto: algunas instrucciones de prueba Ext4 TRIM le piden al usuario que verifique solo que el primer sector fue TRIM del archivo. El probador debe ver una porción más grande del archivo de prueba para ver realmente si el TRIM fue exitoso o no.

Ahora para descubrir por qué los comandos TRIM emitidos manualmente enviados al SSD a través de la tarjeta RAID funcionan, pero los comandos TRIM automáticos no ...


Pensé que todos los RAID HW comían comandos de recorte, es bueno ver que las cosas están cambiando lentamente. Por otro lado, con buenas unidades modernas, TRIM importa cada vez menos.
Ronald Pottol

4

Según lo que he leído, puede haber una falla en su metodología.

Está suponiendo que TRIM dará como resultado que su SSD ponga a cero los bloques que se han eliminado. Sin embargo, esto no suele ser el caso.

Eso es solo si el SSD implementa TRIM para que ponga a cero los bloques descartados. Puede verificar si el dispositivo al menos sabe lo suficiente como para informar discard_zeroes_data:

cat / sys / block / sda / queue / discard_zeroes_data

Además, incluso si el SSD hace cero, puede llevar algún tiempo, mucho después de que se haya completado el descarte, para que el SSD realmente ponga a cero los bloques (esto es cierto para algunos SSD de menor calidad).

http://www.redhat.com/archives/linux-lvm/2011-April/msg00048.html

Por cierto, estaba buscando una forma confiable de verificar TRIM y aún no he encontrado una. Me encantaría saber si alguien encuentra el camino.


3

Aquí está la metodología de prueba para 10.10 y EXT4. Tal vez te ayude.

/ubuntu/18903/how-to-enable-trim

Ah, y creo que necesita el parámetro de descarte en el montaje fstab. No estoy seguro de si se necesita SSD param ya que creo que debería detectar automáticamente SSD.


2
Intenté seguir las instrucciones de verificación de SSD Ext4, pero no funcionan debido a las diferencias en cómo funciona BtrFS en comparación con otros sistemas de archivos. De ahí el flujo de trabajo que se me ocurrió. Utilicé la ssdopción de montaje para asegurarme de que BtrFS supiera usar su código específico de SSD aunque debería detectarlo automáticamente. También intenté usar discard(como se señaló anteriormente) y no me ayudó.
Shane Meyers

Oh bien. Vale la pena
intentarlo

1

Para btrfs necesita la discardopción para habilitar el soporte TRIM.

Una prueba muy simple pero funcional para TRIM funcional está aquí: http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/2


1
Como mencioné anteriormente, probé mis pruebas con la discardopción y la ssdopción. Los documentos de BtrFS mencionan mucho la ssdopción, por lo que centré mis pruebas allí, pero ninguna de las opciones resultó en el resultado que esperaba. La mayoría de las páginas web que muestran cómo probar TRIM son para Ext4 y similares. BtrFS no se puede probar usando esas metodologías debido a la diferencia en el diseño del sistema de archivos.
Shane Meyers

hdparm --fibmapes FS agnóstico. Un bloque en la dirección LBA dada se pone a cero o no, ya sea extN, btrfs, xfs, jfs ... la ssdopción es irrelevante para el recorte, consulte, por ejemplo, esta discusión en la lista de correo de btrfs : mail-archive.com/linux-btrfs @ vger.kernel.org / msg10932.html .
Paweł Brodacki

Intenté usarlo hdparm --fibmappero no funciona en BtrFS. Si observa el archivo README wiper.sh (distribuido junto con hdparm), declaran explícitamente que "las llamadas FIEMAP / FIBMAP ioctl () son completamente inseguras cuando se usan en un sistema de archivos btrfs". Entonces hdparm está fuera, lo cual es una lástima, ya que esto haría que las pruebas sean mucho más fáciles. No sabía que la ssdopción no tenía nada que ver con TRIM ya que los documentos no tienen muy clara la utilidad de la opción.
Shane Meyers

Gracias por la información adicional sobre ioctls, no lo sabía. Creo que el mejor lugar para pedir información adicional podría ser la lista de correo de btrfs. Obtendrá información de primera mano desde allí.
Paweł Brodacki

1

Algunas cosas para pensar (para ayudar a responder su pregunta "¿Me estoy perdiendo algo?"):

  • ¿Qué es exactamente / dev / sda? un solo SSD? o una matriz RAID (¿hardware?) de SSD?

  • si este último, ¿qué tipo de controlador RAID?

  • y tu controlador de banda soporta TRIM?

y finalmente,

  • ¿su método de prueba le da los resultados que espera si formatea / dev / sda1 con algo diferente a btrfs?

1

Prácticamente todos los SSD con una interfaz SATA ejecutan algún tipo de sistema de archivos de estructura de registro que está completamente oculto para usted. El comando 'recortar' SATA le dice al dispositivo que el bloque ya no está en uso y que el sistema de archivos de la estructura de registro subyacente puede flashearlo / si / el bloque de borrado correspondiente (que podría ser sustancialmente más grande) / solo / contiene bloques marcados con recorte.

No he leído los documentos estándar, que están aquí: http://t13.org/Documents/MinutesDefault.aspx?keyword=trim , pero no estoy seguro de si hay alguna garantía de nivel estándar que pueda ver los resultados de un comando de recorte. Si puede ver que algo cambia, como los primeros bytes que se ponen a cero al comienzo de un bloque de borrado, no creo que haya ninguna garantía de que esto sea aplicable en diferentes dispositivos o incluso en la versión de firmware.

Si piensa en la forma en que se podría implementar la abstracción, debería ser posible hacer que el resultado del comando de recorte sea completamente invisible para el que solo está leyendo / escribiendo bloques. Además, puede ser difícil saber qué bloques están en el mismo bloque de borrado, ya que solo la capa de traducción flash debe saberlo y podría haberlos reordenado lógicamente.

¿Quizás haya un comando SATA (¿quizás un comando OEM?) Para obtener metadatos relacionados con la capa de traducción flash de SSD?

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.