21 votos

Compruebe la compatibilidad con TRIM con BtrFS en SSD

Estamos buscando a usar BtrFS en una matriz de discos SSD y me ha pedido para comprobar que BtrFS no en el hecho de realizar el RECORTE de las operaciones después de borrar un archivo. Hasta ahora he sido incapaz de verificar que el comando TRIM se envía a los discos.

Sé que BtrFS no se considera la producción de listo, pero nos gusta el filo, por lo tanto lo estoy probando. El servidor de Ubuntu 11.04 server de 64 bits de liberación (mkfs.btrfs versión 0.19). He instalado el Linux kernel 3.0.0 como BtrFS changelog estados que el grueso de RECORTE no está disponible en el kernel que viene con Ubuntu 11.04 (2.6.38).

Aquí está mi metodología de pruebas (inicialmente adoptado de http://andyduffell.com/techblog/?p=852con las modificaciones a trabajar con BtrFS):

  • Manualmente RECORTE de 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
  • Compruebe que la unidad está TRIM d: ./sectors.pl |grep + | tee sectors-$(date +%s)
  • Partición de la unidad: fdisk /dev/sda
  • Hacer que el sistema de archivos: mkfs.btrfs /dev/sda1
  • Montaje: sudo mount -t btrfs -o ssd /dev/sda1 /mnt
  • Crear un archivo: dd if=/dev/urandom of=/mnt/testfile bs=1k count=50000 oflag=direct
  • Compruebe que el archivo está en el disco: ./sectors.pl | tee sectors-$(date +%s)
  • Eliminar el archivo de prueba: rm /mnt/testfile
  • Ver que el archivo de prueba es RECORTAR había en el disco: ./sectors.pl | tee sectors-$(date +%s)
  • Verificar el RECORTE había bloques: diff los dos más recientes, sectors-* archivos

En este punto, la pre-eliminar y post eliminar las verificaciones todavía muestran el mismo de los bloques de disco en uso. Yo en su lugar, debe ver una reducción en el número de en el uso de los bloques. A la espera de una hora (en caso de que se necesita un tiempo para que el comando TRIM para ser emitido) después de que el archivo de prueba es eliminado todavía muestra los mismos bloques en uso.

También he tratado de montaje con el -o ssd,discard opciones, pero que no parece ayudar en todo.

La partición que fue creado a partir de fdisk por encima de (I mantener la partición pequeña para la verificación puede 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.pl script (sé que esto es ineficiente, pero se 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";

Es mi metodología de las pruebas de defectos? Me estoy perdiendo algo aquí?

Gracias por la ayuda.

4voto

aaron sacker Puntos 1

Basado en lo que he leído, no puede ser un fallo en su metodología.

Usted está asumiendo que RECORTAR resultará en un SSD de puesta a cero de los bloques que han sido eliminados. Sin embargo, este no es siempre el caso.

Eso es sólo si el SSD implementa el borde de forma que los ceros de la descartados los bloques. Se puede comprobar si el dispositivo al menos sabe lo suficiente informe discard_zeroes_data:

cat /sys/block/sda/queue/discard_zeroes_data

Además, incluso si el SSD hace cero, puede tomar algún tiempo ... bueno después de el descarte ha completado -- para el SSD realmente cero los bloques (este es el caso de algunos de menor calidad Ssd).

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

Por CIERTO yo estaba buscando una manera confiable para verificar RECORTAR y no he encontrado aún. Me encantaría saber si alguien encuentra una manera.

3voto

Dave Veffer Puntos 121

Aquí está una metodología de prueba para 10.10 y EXT4. Tal vez voy a ayudar.

http://askubuntu.com/questions/18903/how-to-enable-trim

Ah, y creo que sí es necesario que el descarte de parámetros en el fstab de montaje. No estoy seguro si SSD param es necesario, como creo que debería detectar automáticamente SSD.

2voto

Shane Meyers Puntos 583

Así que después de muchos días de trabajo en este, que fue capaz de demostrar que BtrFS hace uso de TRIM. Yo era incapaz de éxito, el trabajo del ajuste en el servidor que vamos a ser la implementación de estas unidades Ssd. Sin embargo, cuando se prueba utilizando la misma unidad conectada a un portátil, las pruebas tienen éxito.

El Hardware utilizado para todos los de esta prueba:

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

Después de muchos intentos fallidos en la verificación de BtrFS en el servidor, me decidí a probar esta misma prueba utilizando un viejo portátil (quitar la tarjeta RAID capa). Los intentos iniciales de esta prueba utilizando tanto el sistema de archivos Ext4 y BtrFS en la computadora portátil fallar (datos no TRIM d).

Luego he actualizado a la unidad SSD firmware de la versión 0001 (como sacado de la caja) a la versión 0009. Las pruebas se repitieron con Ext4 y BtrFS y ambos sistemas de archivos con éxito RECORTAR tenía los datos.

Para asegurarse de que el comando TRIM había tiempo para correr, hice un rm /mnt/testfile && sync && sleep 120 antes de realizar la validación.

Una cosa a tener en cuenta si usted está tratando de esta misma prueba: las unidades Ssd han borrar bloques que operan sobre la (no sé el tamaño de los Crucial m4 borrar bloques). Cuando el sistema de archivos envía el comando TRIM para la unidad, la unidad sólo borrar un bloque completo; si el comando TRIM está especificado para una parte de un bloque, bloque no será RECORTAR había debido a que el resto de los datos válidos dentro de borrar bloque.

Así que para demostrar de qué estoy hablando (salida de la sectors.pl script de arriba). Esto es con el archivo de prueba en el SSD. Los períodos son los sectores que sólo contienen ceros. Ventajas de tener uno o más distinto de cero bytes.

Archivo de prueba en la unidad:

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

Prueba de archivos borrados de la unidad (después de un sync && sleep 120):

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

Parece que la primera y la última sectores del archivo están dentro de las diferentes borrar bloques del resto del archivo. Por lo que en algunos sectores se mantuvieron intactos.

Para llevar esta forma: algunos Ext4 RECORTE de instrucciones de las pruebas de pedir al usuario que sólo comprobar que el primer sector fue RECORTAR había desde el archivo. El probador debe ver una porción mayor del archivo de prueba para ver realmente si el RECORTE fue exitosa o no.

Ahora, para comprender por qué manualmente emitido RECORTE de los comandos que se envían a la unidad SSD a través de la tarjeta RAID trabajo pero automático de los comandos TRIM para que no se...

1voto

Paweł Brodacki Puntos 4635

Para btrfs necesita discard opción para habilitar el soporte TRIM.

Un muy simple, pero prueba de trabajo para el funcionamiento de RECORTE está aquí: http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/2

1voto

Joshua Hoblitt Puntos 615

Prácticamente todas las unidades Ssd con interfaz SATA ejecutar algún tipo de registro de la estructura del sistema de ficheros que está completamente oculto. El SATA 'recorte' comando indica al dispositivo que el bloque ya no está en uso y que la subyacente estructura de registro de sistema de ficheros puede flash es /si/ la correspondiente borrar bloque (que podría ser considerablemente mayor) /solo/ contiene los bloques marcados con el recorte.

No he leído el estándar de google docs, que está aquí: http://t13.org/Documents/MinutesDefault.aspx?keyword=trim, pero no estoy seguro de si hay cualquier nivel de garantía de que usted sería capaz de ver los resultados de un comando trim. Si se puede ver algo a cambio, como los primeros byte cero había al inicio de borrar un bloque, no creo que haya ninguna garantía de que sea aplicable a través de diferentes dispositivos o tal vez incluso la versión de firmware.

Si usted piensa acerca de la forma en que la abstracción puede ser aplicada, debe ser posible para que el resultado del comando trim completamente invisible a la que se acaba de lectura/escritura de los bloques. Además, podría ser difícil de distinguir de los bloques que están en la misma borrar bloque, ya que sólo el flash de la capa de traducción tiene que saber que y podría haber reorganizado ellos lógicamente.

Tal vez hay un SATA de comandos (OEM comando tal vez?) para obtener los metadatos asociados a las unidades Ssd flash capa de traducción?

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: