Verificar o suporte do TRIM com o BtrFS no SSD

Question

Estamos investigando o uso do BtrFS em uma matriz de discos SSD e me pediram para verificar se o BtrFS de fato executa operações TRIM ao excluir um arquivo. Até agora, não consegui verificar se o comando TRIM foi enviado para os discos.

Eu sei que o BtrFS não é considerado pronto para a produção, mas nós gostamos do limite, por isso estou testando. O servidor é uma versão de 64 bits do servidor Ubuntu 11.04 (mkfs.btrfs versão 0.19). Eu instalei o kernel do Linux 3.0.0 como o changelog do BtrFS indica que TRIM em massa não está disponível no kernel enviado com o Ubuntu 11.04 (2.6.38).

Aqui está minha metodologia de testes (inicialmente adotada no link , com modificações para trabalhar com o BtrFS):

• Manualmente, limpe os discos antes de iniciar: for i in {0..10} ; do let A="$i * 65536" ; hdparm --trim-sector-ranges $A:65535 --please-destroy-my-drive /dev/sda ; done
• Verifique se a unidade foi TRIM'd: ./sectors.pl |grep + | tee sectors-$(date +%s)
• Particione a unidade: fdisk /dev/sda
• Crie o sistema de arquivos: mkfs.btrfs /dev/sda1
• Montagem: sudo mount -t btrfs -o ssd /dev/sda1 /mnt
• Crie um arquivo: dd if=/dev/urandom of=/mnt/testfile bs=1k count=50000 oflag=direct
• Verifique se o arquivo está no disco: ./sectors.pl | tee sectors-$(date +%s)
• Excluir o arquivo de teste: rm /mnt/testfile
• Veja se o arquivo de teste é TRIM'd do disco: ./sectors.pl | tee sectors-$(date +%s)
• Verifique os blocos TRIM: diff os dois arquivos sectors-* mais recentes

Neste ponto, as verificações de pré-exclusão e pós-exclusão ainda mostram os mesmos blocos de disco em uso. Eu deveria ver uma redução no número de blocos em uso. Esperar uma hora (no caso de demorar um tempo para o comando TRIM ser emitido) depois que o arquivo de teste for excluído ainda mostrará os mesmos blocos em uso.

Eu também tentei montar com as opções -o ssd,discard , mas isso não parece ajudar em nada.

Partição criada a partir de fdisk acima (mantenho a partição pequena para que a verificação seja mais rápida):

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

Meu script sectors.pl (sei que isso é ineficiente, mas faz o trabalho):

#!/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";

Minha metodologia de teste é falha? Estou faltando alguma coisa aqui?

Obrigado pela ajuda.

    

Answer 1

Então, depois de muitos dias trabalhando nisso, consegui demonstrar que o BtrFS usa o TRIM. Não consegui fazer com que o TRIM funcionasse no servidor para o qual estaremos implantando esses SSDs. No entanto, ao testar usando a mesma unidade conectada a um laptop, os testes são bem-sucedidos.

Hardware usado para todos os testes:

• SSD 512GB Crucial m4
• HP DL160se G6
• LBA LSISAS9200-8e HBA
• gabinete SAS genérico
• laptop Dell XPS m1210

Depois de muitas tentativas fracassadas de verificar o BtrFS no servidor, decidi tentar o mesmo teste usando um laptop antigo (remova a camada da placa RAID). As tentativas iniciais deste teste usando ambos Ext4 e BtrFS no laptop falhar (dados não TRIM'd).

Eu então atualizei o firmware da unidade SSD da versão 0001 (como enviada para uso) para a versão 0009. Os testes foram repetidos com o Ext4 e o BtrFS e ambos os sistemas de arquivos TRIM tiveram sucesso com os dados.

Para garantir que o comando TRIM tenha tempo de ser executado, eu fiz um rm /mnt/testfile && sync && sleep 120 antes de executar a validação.

Uma coisa a ser observada é se você está tentando o mesmo teste: os SSDs possuem blocos de apagamento nos quais operam (não sei o tamanho dos blocos de exclusão do Crucial m4). Quando o sistema de arquivos envia o comando TRIM para a unidade, a unidade só apaga um bloco completo; se o comando TRIM for especificado para uma parte de um bloco, esse bloco não será TRIM'd devido aos dados válidos restantes dentro do bloco de apagamento.

Então, para demonstrar do que estou falando (saída do script sectors.pl acima). Isso é com o arquivo de teste no SSD. Períodos são setores que contêm apenas zeros. Vantagens têm um ou mais bytes diferentes de zero.

Arquivo de teste na unidade:

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

Arquivo de teste excluído da unidade (após sync && sleep 120 ):

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

Parece que o primeiro e o último setores do arquivo estão em blocos de exclusão diferentes do resto do arquivo. Portanto, alguns setores foram deixados intactos.

Uma forma de fazer isso: algumas instruções de teste do Ext4 TRIM pedem ao usuário para verificar apenas se o primeiro setor foi TRIM'd do arquivo. O testador deve visualizar uma parte maior do arquivo de teste para realmente ver se o TRIM foi bem-sucedido ou não.

Agora, descubra por que os comandos TRIM enviados manualmente para o SSD através do trabalho com a placa RAID, mas os comandos TRIM automáticos para não ...

    

Answer 2

Com base no que li, pode haver uma falha na sua metodologia.

Você está assumindo que TRIM resultará em seu SSD zerando os blocos que foram excluídos. No entanto, este não é frequentemente o caso.

That is only if the SSD implements TRIM so that it zeroes the discarded blocks. You can check if the device at least knows enough to report discard_zeroes_data:

cat /sys/block/sda/queue/discard_zeroes_data

Also, even if the SSD does zero, it may take some time -- well after the discard has completed -- for the SSD to actually zero the blocks (this is true of some lesser quality SSDs).

link

BTW Eu estava procurando uma maneira confiável de verificar o TRIM e ainda não encontrei um. Eu adoraria saber se alguém encontrar um caminho.

    

Answer 3

Aqui está a metodologia de teste para 10.10 e EXT4. Talvez ajude.

link

Ah, acho que você precisa do parâmetro discard na montagem fstab. Não tenho certeza se o parâmetro SSD é necessário, pois acho que ele deve detectar automaticamente o SSD.

    

Answer 4

Para o btrfs, você precisa da opção discard para ativar o suporte ao TRIM.

Um teste muito simples, mas prático, para o TRIM funcional está aqui: link

    

Answer 5

Algumas coisas para pensar (para ajudar a responder a sua pergunta "estou sentindo falta de algo?"):

• o que exatamente é / dev / sda? um único SSD? ou uma matriz RAID (hardware?) de SSDs?

• se este último então que tipo de controlador RAID?

• e seu controlador RAID suporta TRIM?

e, finalmente,

• o seu método de teste fornece os resultados esperados se você formata / dev / sda1 com algo diferente de btrfs?

Answer 6

Praticamente todos os SSDs com uma interface SATA executam algum tipo de sistema de arquivos de estrutura de log que é completamente oculto de você. O comando SATA 'trim' diz ao dispositivo que o bloco não está mais em uso e que o sistema de arquivos de estrutura de log subjacente pode piscar / se / o bloco de apagamento correspondente (que pode ser substancialmente maior) / somente / contém blocos marcados com trim.

Eu não li os documentos padrão, que estão aqui: link , mas eu não sou Certifique-se de que existe uma garantia de nível padrão para poder ver os resultados de um comando de compensação. Se você puder ver algo mudar, como o primeiro byte sendo zerado no início de um bloco de apagamento, eu não acho que haja qualquer garantia de que isso seja aplicável em diferentes dispositivos ou talvez até na versão do firmware.

Se você pensar na forma como a abstração pode ser implementada, deve ser possível tornar o resultado do comando trim completamente invisível para aquele que apenas lê / escreve blocos. Além disso, pode ser difícil dizer quais blocos estão no mesmo bloco de apagamento, já que somente a camada de tradução do flash precisa saber disso e pode tê-los reordenado logicamente.

Talvez exista um comando SATA (comando de OEM talvez?) para buscar metadados relacionados à camada de conversão de flash de SSDs?