Linux - Schede SD per test di stress utilizzando Linux?

Ieri ho avuto un piccolo dibattito con qualcuno in merito alla logica e/o alla veridicità della mia risposta qui, cioè che la registrazione e il mantenimento dei metadati fs su una scheda SD di dimensioni decenti (GB+) non potrebbero mai essere abbastanza significativi da indossare la scheda in un ragionevole lasso di tempo (anni e anni). Il succo della controargomentazione sembrava essere che dovessi sbagliarmi dal momento che ci sono così tante storie online di persone che consumano schede SD.

Dal momento che ho dispositivi con schede SD contenenti filesystem root rw che vengono lasciati attivi 24 ore su 24, 7 giorni su 7, avevo già testato la premessa con mia soddisfazione. Ho modificato un po' questo test, l'ho ripetuto (usando la stessa scheda, in effetti) e lo presento qui. Le due domande centrali che ho sono:

1. Il metodo che ho usato per tentare di rovinare la carta è fattibile, tenendo presente che ha lo scopo di riprodurre gli effetti della riscrittura continua piccolo quantità di dati?
2. Il metodo che ho utilizzato per verificare la carta è ancora valido?

Sto ponendo la domanda qui piuttosto che S.O. o SuperUser perché un'obiezione alla prima parte dovrebbe probabilmente affermare che il mio test non ha scritto davvero sulla scheda nel modo in cui sono sicuro che lo fa, e affermare ciò richiederebbe una conoscenza speciale di Linux.

[Potrebbe anche essere che le schede SD utilizzino una sorta di buffering o cache intelligente, in modo tale che le scritture ripetute nello stesso posto vengano memorizzate nel buffer/cache in un luogo meno soggetto a usura. Non ho trovato alcuna indicazione in merito da nessuna parte, ma te lo sto chiedendo su S.U.]

L'idea alla base del test è di scrivere sullo stesso piccolo blocco sulla scheda milioni di volte. Questo è ben al di là di qualsiasi affermazione su quanti cicli di scrittura possono sostenere tali dispositivi, ma presumendo che il livellamento dell'usura sia efficace, se la scheda è di dimensioni decenti, milioni di tali scritture non dovrebbero comunque importare molto, poiché "lo stesso blocco" farebbe non essere letteralmente lo stesso blocco fisico. Per fare ciò, dovevo assicurarmi che ogni scrittura fosse veramente scaricata sull'hardware e allo stesso apparente luogo.

Per il flushing sull'hardware, mi sono affidato alla chiamata della libreria POSIX fdatasync() :

#include <stdio.h>
#include <string.h>
#include <fcntl.h>
#include <errno.h>
#include <unistd.h>
#include <stdlib.h>

// Compile std=gnu99

#define BLOCK 1 << 16

int main (void) {
    int in = open ("/dev/urandom", O_RDONLY);
    if (in < 0) {
        fprintf(stderr,"open in %s", strerror(errno));
        exit(0);
    }

    int out = open("/dev/sdb1", O_WRONLY);
    if (out < 0) {
        fprintf(stderr,"open out %s", strerror(errno));
        exit(0);
    }

    fprintf(stderr,"BEGINn");

    char buffer[BLOCK];
    unsigned int count = 0;
    int thousands = 0;
    for (unsigned int i = 1; i !=0; i++) {
        ssize_t r = read(in, buffer, BLOCK);
        ssize_t w = write(out, buffer, BLOCK);
        if (r != w) {
            fprintf(stderr, "r %d w %dn", r, w);
            if (errno) {
                fprintf(stderr,"%sn", strerror(errno));
                break;
            }
        }
        if (fdatasync(out) != 0) {
            fprintf(stderr,"Sync failed: %sn", strerror(errno));
            break;
        }
        count++;
        if (!(count % 1000)) {
            thousands++;
            fprintf(stderr,"%d000...n", thousands);
        }
        lseek(out, 0, SEEK_SET);
    }
    fprintf(stderr,"TOTAL %lun", count);
    close(in);
    close(out);

    return 0;
}                                 

L'ho eseguito per circa 8 ore, finché non ho accumulato 2 milioni e più di scritture all'inizio del /dev/sdb1 partizione. Avrei potuto semplicemente usare /dev/sdb (il dispositivo grezzo e non la partizione) ma non riesco a vedere quale differenza farebbe.

Ho quindi controllato la scheda provando a creare e montare un filesystem su /dev/sdb1 . Questo ha funzionato, indicando che il blocco specifico a cui avevo scritto tutta la notte era fattibile. Tuttavia, ciò non significa che alcune regioni della carta non siano state consumate e spostate dal livellamento dell'usura, ma siano state lasciate accessibili.

Per verificarlo, ho usato badblocks -v -w sulla partizione. Questo è un distruttivo test di lettura-scrittura, ma il livellamento dell'usura o meno, dovrebbe essere una forte indicazione della fattibilità della scheda poiché deve comunque fornire spazio per ogni scrittura scorrevole. In altre parole, è l'equivalente letterale di riempire completamente la carta, quindi controllare che tutto fosse a posto. Diverse volte, dal momento che lascio che i badblock funzionino attraverso alcuni schemi.

Correlati:test dell'unità MVC?

[Contra i commenti di Jason C qui sotto, non c'è niente di sbagliato o falso nell'usare i badblock in questo modo. Anche se non sarebbe utile per identificare effettivamente i blocchi danneggiati a causa della natura delle schede SD, va bene per eseguire test di lettura-scrittura distruttivi di dimensioni arbitrarie usando il -b e -c interruttori, che è dove è andato il test rivisto (vedi la mia risposta). Nessuna quantità di magia o memorizzazione nella cache da parte del controller della scheda può ingannare un test in base al quale diversi megabyte di dati possono essere scritti sull'hardware e riletti correttamente. Gli altri commenti di Jason sembrano basati su una lettura errata:l'IMO è intenzionale uno, motivo per cui non mi sono degnato di discutere. Con quella testa alta, lascio al lettore decidere cosa ha senso e cosa non lo fa .]

La scheda era una vecchia scheda Sandisk da 4 GB (non ha un numero di "classe") che ho usato a malapena. Ancora una volta, tieni presente che non si tratta di 2 milioni di scritture letteralmente nello stesso luogo fisico; a causa del livellamento dell'usura, il "primo blocco" sarà stato spostato costantemente dal controller durante il test per, come afferma il termine, livellare l'usura.

Risposta accettata:

Penso che lo stress test di una scheda SD sia in generale problematico date 2 cose:

1. livellamento dell'usura
   Non ci sono garanzie che una scrittura su quella successiva stia effettivamente esercitando le stesse posizioni fisiche sulla SD. Ricorda che la maggior parte dei sistemi SD in atto stanno attivamente prendendo un blocco come lo conosciamo e spostando la posizione fisica che lo supporta in base all'"usura" percepita a cui è stata sottoposta ciascuna posizione.

2. diverse tecnologie (MLC vs. SLC)
   L'altro problema che vedo con questo è la differenza nelle tecnologie. Tipi di SSD SLC Mi aspetterei di avere una vita molto più lunga rispetto alla varietà MLC. Inoltre ci sono tolleranze molto più strette su MLC che semplicemente non devi affrontare su SLC, o almeno sono molto più tolleranti a fallire in questo modo.

   • MLC – Cella multilivello
   • SLC – Cella a livello singolo

Il problema con l'MLC è che una determinata cella può memorizzare più valori, i bit sono essenzialmente impilati utilizzando una tensione, piuttosto che essere solo un +5V o 0V fisico, ad esempio, quindi questo può portare a un potenziale tasso di guasto molto più elevato rispetto al loro SLC equivalente.

Speranza di vita

Ho trovato questo collegamento che discute un po' su quanto tempo può durare l'hardware. Si intitola:Conosci i tuoi SSD:SLC vs. MLC.

SLC

SLC ssds può essere calcolato, per la maggior parte, per vivere ovunque tra 49 anni e 149 anni, in media, secondo le migliori stime. Il test Memoright può convalidare l'SSD da 128 Gb con una durata della resistenza in scrittura superiore a 200 anni con una scrittura media di 100 Gb al giorno.

MLC

È qui che il design mlc non è all'altezza. Nessuno è stato ancora rilasciato. Nessuno ha davvero esaminato quale tipo di aspettativa di vita è assicurata con il mlc, tranne per il fatto che sarà notevolmente inferiore. Ho ricevuto diverse convinzioni che in media si aggirano su una durata di 10 a 1 a favore del design slc. Un'ipotesi prudente è che la maggior parte delle stime della durata della vita sarà compresa tra 7 e 10 anni, a seconda dell'avanzamento degli "algoritmi di livellamento dell'usura" all'interno dei controller di ciascun produttore.

Confronti

Per fare un confronto tramite cicli di scrittura, un slc avrebbe una durata di 100.000 cicli di scrittura completi rispetto al mlc che ha una durata di 10.000 cicli di scrittura. Questo potrebbe aumentare in modo significativo a seconda del design del "livellamento dell'usura" utilizzato.