Verifique el soporte TRIM con BtrFS en SSD

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.

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 ...

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.

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.

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

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?

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?