Verifica del supporto TRIM con BtrFS su SSD


21

Stiamo esaminando l'utilizzo di BtrFS su un array di dischi SSD e mi è stato chiesto di verificare che BtrFS esegua effettivamente operazioni TRIM dopo l'eliminazione di un file. Finora non sono stato in grado di verificare che il comando TRIM sia inviato ai dischi.

So che BtrFS non è considerato pronto per la produzione, ma a noi piace il limite, quindi lo sto testando. Il server è Ubuntu 11.04 versione a 64 bit del server (mkfs.btrfs versione 0.19). Ho installato il kernel Linux 3.0.0 poiché il log delle modifiche di BtrFS afferma che il TRIM di massa non è disponibile nel kernel fornito con Ubuntu 11.04 (2.6.38).

Ecco la mia metodologia di test (inizialmente adottata da http://andyduffell.com/techblog/?p=852 , con modifiche per lavorare con BtrFS):

  • TRIM manualmente i dischi prima di iniziare: for i in {0..10} ; do let A="$i * 65536" ; hdparm --trim-sector-ranges $A:65535 --please-destroy-my-drive /dev/sda ; done
  • Verifica che l'unità sia stata TRIMD: ./sectors.pl |grep + | tee sectors-$(date +%s)
  • Partizionare l'unità: fdisk /dev/sda
  • Crea il file system: mkfs.btrfs /dev/sda1
  • Montare: sudo mount -t btrfs -o ssd /dev/sda1 /mnt
  • Crea un file: dd if=/dev/urandom of=/mnt/testfile bs=1k count=50000 oflag=direct
  • Verifica che il file sia sul disco: ./sectors.pl | tee sectors-$(date +%s)
  • Elimina il file di prova: rm /mnt/testfile
  • Verifica che il file di test sia TRIM dal disco: ./sectors.pl | tee sectors-$(date +%s)
  • Verifica i blocchi TRIM: diffi due sectors-*file più recenti

A questo punto, le verifiche pre-cancellazione e post-cancellazione mostrano ancora gli stessi blocchi disco in uso. Dovrei invece vedere una riduzione del numero di blocchi in uso. Attendere un'ora (nel caso in cui occorra un po 'di tempo prima che il comando TRIM venga emesso) dopo l'eliminazione del file di test mostra ancora gli stessi blocchi in uso.

Ho anche provato a montare con le -o ssd,discardopzioni, ma questo non sembra aiutare affatto.

Partizione creata fdiskdall'alto (mantengo piccola la partizione in modo che la verifica possa andare più veloce):

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

La mia sectors.plsceneggiatura (so che è inefficiente, ma fa il lavoro):

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

La mia metodologia di test è difettosa? Mi sto perdendo qualcosa qui?

Grazie per l'aiuto.


1
Sostengo completamente il test di cose sanguinanti, ma solo così sai, a partire da ora, btrfs non ha un fsck che in realtà, sai, risolve le cose: btrfs.wiki.kernel.org/index.php/Main_Page - così stai attento.
Matt Simmons,

@Matt - Buon punto per l'sfck mancante. La mia comprensione è che la prima versione di un fsck dovrebbe essere disponibile entro le prossime settimane, quindi dovremmo essere coperti dal momento in cui passiamo alla produzione. Inoltre, avremo più copie dei nostri dati, quindi se perdiamo una copia, avremo almeno altre due copie da ripristinare. Ma sono pienamente d'accordo sul fatto che questo non è il file system per le persone con dati insostituibili per ora.
Shane Meyers,

1
Probabilmente non cambierà nulla, ma potresti anche provare a eseguire un syncdopo aver rmming il file.
zebediah49,

Voglio dire che ho provato a eseguire un syncdopo aver rimosso il file e i risultati erano sempre gli stessi. Lo ricontrollerò comunque quando tornerò in ufficio dopo il fine settimana.
Shane Meyers,

se non ti dispiace sanguinare, hai considerato zfsonlinux.org ? ZFS nativo (cioè nel kernel, non fusibile) per Linux. sono vicini a una "versione" ufficiale e hanno RC disponibili (incluso un PPA per Ubuntu - abbastanza facile da ricostruire anche per debian)
cas

Risposte:


4

Quindi, dopo molti giorni di lavoro su questo, sono stato in grado di dimostrare che BtrFS utilizza TRIM. Non sono riuscito a far funzionare correttamente TRIM sul server sul quale distribuiremo questi SSD. Tuttavia, quando si esegue il test utilizzando la stessa unità collegata a un laptop, i test hanno esito positivo.

Hardware utilizzato per tutti questi test:

  • SSD Crucial m4 da 512 GB
  • HP DL160se G6
  • LSI LSISAS9200-8e HBA
  • recinzione SAS generica
  • Computer portatile Dell XPS m1210

Dopo molti tentativi falliti di verificare BtrFS sul server, ho deciso di provare questo stesso test usando un vecchio laptop (rimuovere il livello della scheda RAID). I tentativi iniziali di questo test utilizzando sia Ext4 che BtrFS sul laptop falliscono (dati non TRIM'd).

Ho quindi aggiornato il firmware dell'unità SSD dalla versione 0001 (come pronta per l'uso) alla versione 0009. I test sono stati ripetuti con Ext4 e BtrFS ed entrambi i filesystem hanno TRIM correttamente eseguito i dati.

Per assicurarmi che il comando TRIM avesse il tempo di essere eseguito, ho fatto rm /mnt/testfile && sync && sleep 120prima di eseguire la convalida.

Una cosa da notare se stai tentando questo stesso test: gli SSD hanno blocchi di cancellazione su cui operano (non conosco la dimensione dei blocchi di cancellazione Crucial m4). Quando il file system invia il comando TRIM all'unità, l'unità cancellerà solo un blocco completo; se il comando TRIM è specificato per una parte di un blocco, quel blocco non sarà TRIM a causa dei restanti dati validi all'interno del blocco di cancellazione.

Quindi per dimostrare di cosa sto parlando (output dello sectors.plscript sopra). Questo è con il file di test sull'SSD. I periodi sono settori che contengono solo zeri. I vantaggi hanno uno o più byte diversi da zero.

File di prova sull'unità:

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

File di prova eliminato dall'unità (dopo a sync && sleep 120):

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

Sembra che il primo e l'ultimo settore del file si trovino all'interno di blocchi di cancellazione diversi dal resto del file. Pertanto alcuni settori sono rimasti intatti.

Un modulo da asporto: alcune istruzioni di test TRIM Ext4 chiedono all'utente di verificare solo che il primo settore sia stato TRIM dal file. Il tester dovrebbe visualizzare una porzione maggiore del file di test per vedere se il TRIM ha avuto successo o meno.

Ora per capire perché i comandi TRIM emessi manualmente inviati all'unità SSD tramite la scheda RAID funzionano, ma i comandi TRIM automatici non ...


Pensavo che tutti i RAID HW avessero mangiato i comandi di trim, bello vedere che le cose cambiano lentamente. D'altra parte, con buoni drive moderni, TRIM conta sempre meno.
Ronald Pottol,

4

Sulla base di ciò che ho letto, potrebbe esserci un difetto nella tua metodologia.

Si presuppone che TRIM comporti l'azzeramento del SSD dei blocchi che sono stati eliminati. Tuttavia, spesso non è così.

Questo è solo se l'SSD implementa TRIM in modo da azzerare i blocchi scartati. Puoi verificare se il dispositivo almeno conosce abbastanza per segnalare discard_zeroes_data:

cat / sys / block / sda / queue / discard_zeroes_data

Inoltre, anche se l'SSD fa zero, potrebbe volerci un po 'di tempo - ben dopo che lo scarto è stato completato - affinché l'SSD azzeri effettivamente i blocchi (questo è vero per alcuni SSD di qualità inferiore).

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

A proposito, stavo cercando un modo affidabile per verificare TRIM e non ne ho ancora trovato uno. Mi piacerebbe sapere se qualcuno trova un modo.


3

Ecco la metodologia di test per 10.10 ed EXT4. Forse ti aiuterà.

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

Oh e penso che tu abbia bisogno del parametro discard sul mount fstab. Non sono sicuro se il parametro SSD sia necessario in quanto penso che dovrebbe rilevare automaticamente SSD.


2
Ho tentato di seguire le istruzioni di verifica SSD Ext4, ma non funzionano a causa delle differenze nel funzionamento di BtrFS rispetto ad altri file system. Da qui il flusso di lavoro che mi è venuto in mente. Ho usato l' ssdopzione mount per assicurarmi che BtrFS sapesse usare il suo codice specifico SSD anche se avrebbe dovuto rilevare automaticamente. Ho anche provato a usare discard(come notato sopra) e non ha aiutato.
Shane Meyers,

Oh bene. Vale la pena
provare

1

Per btrfs è necessaria l' discardopzione per abilitare il supporto TRIM.

Un test molto semplice ma funzionante per TRIM funzionale è qui: http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/2


1
Come ho detto sopra, ho provato i miei test sia con l' discardopzione che con l' ssdopzione. I documenti di BtrFS menzionano molto l' ssdopzione, quindi ho concentrato i miei test lì, ma nessuna delle due opzioni ha prodotto il risultato che mi aspettavo. La maggior parte delle pagine Web che mostrano come testare TRIM sono per Ext4 e simili. BtrFS non può essere testato usando queste metodologie a causa della differenza nella progettazione del file system.
Shane Meyers,

hdparm --fibmapè agnostico. Un blocco a un determinato indirizzo LBA viene azzerato oppure no, indipendentemente dal fatto che sia extN, btrfs, xfs, jfs ... l' ssdopzione non è rilevante per il trim, vedi ad esempio questa discussione sulla mailing list di btrfs: mail-archive.com/linux-btrfs @ vger.kernel.org / msg10932.html .
Paweł Brodacki,

Ho provato a utilizzare hdparm --fibmapma non funziona su BtrFS. Se guardi il file README di wiper.sh (distribuito insieme a hdparm), dichiarano esplicitamente che "le chiamate ioctl () FIEMAP / FIBMAP sono completamente non sicure se usate su un filesystem btrfs". Quindi hdparm è uscito, il che è un peccato perché questo renderebbe i test molto più facili. Non sapevo che l' ssdopzione non avesse nulla a che fare con TRIM poiché i documenti non sono molto chiari sull'utilità dell'opzione.
Shane Meyers,

Grazie per le informazioni extra su ioctls, non lo sapevo. Penso che il posto migliore per chiedere ulteriori informazioni potrebbe essere la mailing list di btrfs. Riceverai informazioni di prima mano da lì.
Paweł Brodacki,

1

Alcune cose a cui pensare (per aiutarti a rispondere alla tua domanda "mi sto perdendo qualcosa?"):

  • che cosa è esattamente / dev / sda? un singolo SSD? o un array RAID (hardware?) di SSD?

  • se quest'ultimo allora quale tipo di controller RAID?

  • e il tuo controller raid supporta TRIM?

e infine,

  • il tuo metodo di test ti dà i risultati che ti aspetti se formatti / dev / sda1 con qualcosa di diverso da btrfs?

1

Praticamente tutti gli SSD con interfaccia SATA eseguono una sorta di filesystem con struttura di registro che è completamente nascosto da te. Il comando 'trim' SATA dice al dispositivo che il blocco non è più in uso e che il file system della struttura di log sottostante può lampeggiare / se / il blocco di cancellazione corrispondente (che potrebbe essere sostanzialmente più grande) / solo / contiene blocchi contrassegnati con trim.

Non ho letto i documenti standard, che sono qui: http://t13.org/Documents/MinutesDefault.aspx?keyword=trim , ma non sono sicuro che ci sia una garanzia di livello standard che tu sia in grado di vedere i risultati di un comando di taglio. Se riesci a vedere qualcosa che cambia, come se i primi byte venissero azzerati all'inizio di un blocco di cancellazione, non credo che ci sia alcuna garanzia che ciò sia applicabile su diversi dispositivi o forse anche sulla versione del firmware.

Se pensi al modo in cui l'astrazione potrebbe essere implementata, dovrebbe essere possibile rendere il risultato del comando trim completamente invisibile a quello che sta leggendo / scrivendo blocchi. Inoltre, potrebbe essere difficile dire quali blocchi si trovano nello stesso blocco di cancellazione, poiché solo il livello di traduzione flash deve saperlo e potrebbe averli riordinati logicamente.

Forse esiste un comando SATA (forse un comando OEM?) Per il recupero dei metadati relativi al livello di traduzione flash degli SSD?

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.