Ieri ho avuto un piccolo dibattito con qualcuno riguardo alla logica e / o alla veridicità della mia risposta qui , vis., Che registrare e mantenere i metadati dei fs su una scheda SD di dimensioni decenti (GB +) non potrebbe mai essere abbastanza significativo da indossare la scheda in un ragionevole lasso di tempo (anni e anni). La scia della contro-argomentazione sembrava essere che dovevo sbagliarmi dal momento che ci sono così tante storie online di persone che indossano schede SD.

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

1. Il metodo che ho usato per tentare di distruggere la carta è praticabile, tenendo presente che è destinato a riprodurre gli effetti della riscrittura continua di piccole quantità di dati?
2. Il metodo che ho usato per verificare che la scheda fosse ancora accettabile?

Sto ponendo la domanda qui piuttosto che SO o SuperUser perché un'obiezione alla prima parte dovrebbe probabilmente affermare che il mio test non ha davvero scritto sulla scheda nel modo in cui sono sicuro, e affermando che richiederebbe un po ' conoscenza speciale di linux.

[Potrebbe anche essere che le schede SD utilizzino un qualche tipo di buffer o cache intelligente, in modo tale che le scritture ripetute nello stesso posto vengano memorizzate / memorizzate nella cache in un luogo meno soggetto a usura. Non ho trovato alcuna indicazione di questo da nessuna parte, ma me lo sto chiedendo su SU]

L'idea alla base del test è di scrivere sullo stesso piccolo blocco sulla scheda milioni di volte. Questo va ben oltre ogni pretesa di quanti cicli di scrittura possono sostenere tali dispositivi, ma presumendo che il livellamento dell'usura sia efficace, se la carta è di dimensioni decenti, milioni di tali scritture non dovrebbero comunque importare molto, come farebbe "lo stesso blocco" non è letteralmente lo stesso blocco fisico. Per fare ciò, dovevo assicurarmi che ogni scrittura fosse realmente scaricata sull'hardware e nello stesso posto apparente .

Per scaricare l'hardware, ho fatto affidamento sulla chiamata alla 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,"BEGIN\n");

    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 %d\n", r, w);
            if (errno) {
                fprintf(stderr,"%s\n", strerror(errno));
                break;
            }
        }
        if (fdatasync(out) != 0) {
            fprintf(stderr,"Sync failed: %s\n", strerror(errno));
            break;
        }
        count++;
        if (!(count % 1000)) {
            thousands++;
            fprintf(stderr,"%d000...\n", thousands);
        }
        lseek(out, 0, SEEK_SET);
    }
    fprintf(stderr,"TOTAL %lu\n", count);
    close(in);
    close(out);

    return 0;
}                                 

L'ho eseguito per ~ 8 ore, fino a quando non avevo accumulato 2 milioni + di scritture all'inizio della /dev/sdb1partizione. ¹ Avrei potuto facilmente usare /dev/sdb(il dispositivo grezzo e non la partizione) ma non riesco a vedere che differenza farebbe.

Ho quindi controllato la scheda provando a creare e montare un filesystem su /dev/sdb1. Funzionava, 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 lasciate accessibili.

Per provarlo, ho usato badblocks -v -wsulla partizione. Questo è un test distruttivo in lettura e scrittura, ma si consuma il livellamento o meno, dovrebbe essere una forte indicazione della fattibilità della scheda poiché deve comunque fornire spazio per ogni scrittura continua. In altre parole, è letteralmente l'equivalente di riempire completamente la carta, quindi verificare che tutto fosse a posto. Diverse volte, poiché ho lasciato che i badblock funzionassero attraverso alcuni schemi.

[Contro i commenti di Jason C di seguito, non c'è niente di sbagliato o di 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 fare test distruttivi di lettura e scrittura di dimensioni arbitrarie usando gli switch -be -c, 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 su hardware e riletti correttamente. Gli altri commenti di Jason sembrano basati su una lettura errata: l'IMO è intenzionale , motivo per cui non mi sono preoccupato di discutere. Con quella testa in su, lascio al lettore la decisione su cosa abbia senso e cosa no .]

¹ La scheda era una vecchia scheda Sandisk da 4 GB (non contiene un numero "di classe") che ho appena usato. Ancora una volta, tieni presente che questo non è 2 milioni di scritture 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.

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

1. livellamento dell'usura Non vi è alcuna garanzia che uno scrivendo al successivo stia effettivamente esercitando le stesse posizioni fisiche sulla SD. Ricorda che la maggior parte dei sistemi SD in atto sta attivamente bloccando un blocco come lo conosciamo e spostando la posizione fisica che lo sostiene in base alla "usura" percepita a cui ogni posizione è stata sottoposta.

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

   • MLC - Cella multi livello
   • SLC - Cella a livello singolo

Il problema con MLC è che una determinata cella può memorizzare più valori, i bit sono essenzialmente impilati usando una tensione, anziché essere semplicemente un + 5V o 0V fisico, ad esempio, quindi questo può portare a un potenziale di tasso di fallimento molto più alto rispetto al loro SLC equivalente.

Aspettativa di vita

Ho trovato questo link che discute un po 'su quanto può durare l'hardware. Si intitola: Know Your SSDs - SLC vs. MLC .

SLC

Gli ssds SLC possono essere calcolati, per la maggior parte, per vivere in qualsiasi luogo tra 49 e 149 anni, in media, dalle migliori stime. Il test Memoright può convalidare l'SSD da 128 GB con una durata di durata in scrittura superiore a 200 anni con una scrittura media di 100 GB al giorno.

MLC

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

confronti

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

Ci sono una serie di problemi con il tuo test, alcuni sfocati, altri no. Dipende anche dal tuo obiettivo. Due problemi delicati e di tipo sfocato sono:

• Non stai leggendo dalla stessa area in cui stai scrivendo, il tuo test di lettura in modo efficace, quindi, non fa nulla (a meno che il controller non abbia letto la correzione del disturbo, nel qual caso potrebbe occasionalmente spostare la pagina da leggere da qualche altra parte, ma continua a farlo non influisce sul test).
• Supponete (ed è probabile, ma non garantito) che una lettura / scrittura su un blocco errato venga rilevata e segnalata dal controller - vorreste scrivere dati, rileggerli e confrontarli per un controllo garantito.

Tuttavia, quelli sono probabilmente pedanti. Più grave è:

• Non è possibile utilizzare badblocksper mostrare pagine non riuscite nella memoria flash; tutti i rilevamenti di errori e le successive mappature delle pagine vengono eseguiti dal controller e sono trasparenti per il sistema operativo. È possibile ottenere alcune informazioni da SMART se l'unità lo supporta (non conosco schede SD che lo supportano, forse ci sono pen drive di fascia più alta che lo fanno).
• Indossare il livellamento, complicato dal test che non tiene conto dei precedenti comandi TRIM, dallo stato libero / usato dell'unità durante il test e dallo spazio riservato.

Livellamento dell'usura: il problema principale è che il livellamento dell'usura è una delle principali variabili del test. Succede sul controller (di solito) e in ogni caso è trasparente + persino diretto cerca + leggi / scrivi sul dispositivo. Nel tuo esempio, in realtà non conosci lo stato di livellamento dell'usura (in particolare, i comandi TRIM sono stati emessi di recente sui blocchi liberi?) ...

Per un livellamento dinamico dell'usura (presente in quasi tutti i dispositivi di archiviazione di fascia consumer) sul tuo dispositivo, quindi, potrebbe essere in qualsiasi stato: ad un estremo, nessuna delle pagine è contrassegnata come libera, quindi le uniche pagine che il controller deve funzionare con sono quelli nello spazio riservato (se presente). Se lo spazio sul dispositivo è riservato, dovrà fallire completamente prima di iniziare a ottenere errori garantiti nelle scritture di pagine (presumendo che non vi siano altre pagine contrassegnate come rimanenti libere). All'altro estremo, ogni pagina è contrassegnata come libera, nel qual caso in teoria devi far fallire ogni pagina sul dispositivo prima di iniziare a vedere errori di scrittura.

Per il livellamento dell'usura statica (che gli SSD tendono ad avere, le schede SD tendono a non avere e le chiavette USB variano): non c'è davvero modo di aggirarlo, a parte scrivere ripetutamente su ogni pagina del dispositivo.

... In altre parole, ci sono dettagli sul livellamento dell'usura che non si ha modo di conoscere e certamente non c'è modo di controllare, in particolare se si utilizza o meno il livellamento dinamico dell'usura, se è in uso il livellamento dell'usura statica e quantità di spazio riservato sul dispositivo per il livellamento dell'usura (che non è visibile oltre il controller [o il driver in alcuni casi, come il vecchio DiskOnChip di M-Systems]).

SLC / MLC: quanto a SLC vs. MLC, questo ha un impatto molto diretto sui limiti che ci si aspetterebbe di vedere, ma la procedura generale di livellamento dell'usura e la procedura di test sono le stesse per entrambi. Molti fornitori non pubblicano se i loro dispositivi sono SLC o MLC per i loro prodotti di consumo più economici, sebbene qualsiasi unità flash che richieda un limite di ciclo di 100k + per pagina sia probabilmente SLC (il compromesso semplificato è SLC = resistenza, MLC = densità).

Memorizzazione nella cache: per quanto riguarda la memorizzazione nella cache, è un po 'incerta. A livello di sistema operativo, nel caso generale, ovviamente, fsync / fdatasync non garantisce che i dati siano effettivamente scritti. Tuttavia, penso che sia sicuro presumere che sia (o almeno il controller si è impegnato a farlo, cioè la scrittura non verrà ingoiata nella cache) in questo caso, poiché le unità rimovibili sono generalmente progettate per il modello di uso comune di "espulsione" (smonta> sincronizzazione) quindi rimuovi (interruzione di corrente). Anche se non lo sappiamo per certo, un'ipotesi istruita afferma che è sicuro presumere che la sincronizzazione garantisca che la scrittura avrà luogo, soprattutto in scrittura -> sincronizzazione -> rilettura (se non lo fosse, le unità non sarebbero affidabili dopo l'espulsione). Non esiste altro comando oltre a "sync" che può essere emesso all'espulsione.

Al controller tutto è possibile, ma il presupposto sopra include anche il presupposto che almeno il controller non stia facendo nulla di "abbastanza complicato" da rischiare la perdita di dati dopo una sincronizzazione. È ipotizzabile che il controllore possa, per esempio, scrivere in buffer e in gruppo o non scrivere dati se gli stessi dati vengono riscritti (in misura limitata). Nel programma seguente, alterniamo due diversi blocchi di dati ed eseguiamo una sincronizzazione prima della rilettura specifica per annullare un ragionevole meccanismo di memorizzazione nella cache del controller. Tuttavia, ovviamente, non ci sono garanzie e non c'è modo di saperlo, ma possiamo fare ipotesi ragionevoli basate sull'uso normale di questi dispositivi e su meccanismi di cache sani / comuni.

test:

Sfortunatamente, la verità è che, a meno che tu non sappia che il dispositivo non ha spazio riservato e non sta eseguendo il livellamento statico, non c'è modo di testare definitivamente il limite di ciclo di una pagina specifica. Tuttavia, il più vicino che puoi ottenere è il seguente (presumi che non ci siano livelli di usura statica):

La prima cosa che devi fare è riempire l'intera scheda di dati. Questo è importante ed è la variabile principale rimasta nel test originale. Questo segna il maggior numero possibile di blocchi utilizzati, a parte qualsiasi spazio riservato (al quale non si ha accesso). Si noti che stiamo lavorando con un intero dispositivo (che distruggerà tutti i dati), poiché lavorare con una singola partizione influisce solo su un'area specifica del dispositivo:

dd if=/dev/urandom bs=512k of=/dev/sdb conv=fsync oflag=sync

Se sei il tipo di barra di avanzamento:

pv -pterb -s <device_size> /dev/urandom | dd bs=512k of=/dev/sdb conv=fsync oflag=sync

Modifica: per le schede con blocchi da 4 MB di cancellazione, prova questo per una scrittura più veloce:

dd if=/dev/urandom bs=4M of=/dev/sdb conv=fsync oflag=direct,sync iflag=fullblock

Successivamente, è possibile scrivere un programma di test del ciclo come segue, usando O_DIRECTe O_SYNC(e possibilmente paranoico, uso ridondante di fsync()) per tagliare quanto più buffer di sistema operativo e memorizzazione nella cache dall'immagine possibile e, teoricamente, scrivere direttamente sul controller e attendi fino a quando segnala che l'operazione è terminata:

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <cstdlib>
#include <cstdio>
#include <cstring>

using namespace std;

static const int BLOCK_SIZE = 512;
static const int ALIGNMENT = 512;
static const int OFFSET = 1024 * ALIGNMENT; // 1024 is arbitrary


int main (int argc, char **argv) {

    if (argc != 2) {
        fprintf(stderr, "usage: %s device\n", argv[0]);
        return 1;
    }

    int d = open(argv[1], O_RDWR | O_DIRECT | O_SYNC);
    if (d == -1) {
        perror(argv[1]);
        return 1;
    }

    char *block[2], *buffer;
    int index = 0, count = -1;

    // buffers must be aligned for O_DIRECT.
    posix_memalign((void **)&(block[0]), ALIGNMENT, BLOCK_SIZE);
    posix_memalign((void **)&(block[1]), ALIGNMENT, BLOCK_SIZE);
    posix_memalign((void **)&buffer, ALIGNMENT, BLOCK_SIZE);

    // different contents in each buffer
    memset(block[0], 0x55, BLOCK_SIZE);
    memset(block[1], 0xAA, BLOCK_SIZE);

    while (true) {

        // alternate buffers
        index = 1 - index;

        if (!((++ count) % 100)) {
            printf("%i\n", count);
            fflush(stdout);
        }

        // write -> sync -> read back -> compare
        if (lseek(d, OFFSET, SEEK_SET) == (off_t)-1)
            perror("lseek(w)");
        else if (write(d, block[index], BLOCK_SIZE) != BLOCK_SIZE)
            perror("write");
        else if (fsync(d))
            perror("fsync");
        else if (lseek(d, OFFSET, SEEK_SET) == (off_t)-1)
            perror("lseek(r)");
        else if (read(d, buffer, BLOCK_SIZE) != BLOCK_SIZE)
            perror("read");
        else if (memcmp(block[index], buffer, BLOCK_SIZE))
            fprintf(stderr, "memcmp: test failed\n");
        else
            continue;

        printf("failed after %i successful cycles.\n", count);
        break;

    }

}

Si noti che per O_DIRECT, i buffer devono essere opportunamente allineati. I confini da 512 byte sono generalmente sufficienti. Puoi compilare con:

g++ -O0 test.cpp -o test

Aggiungi -D_POSIX_C_SOURCE=200112Lse necessario.

Quindi, dopo aver riempito il dispositivo completamente come sopra, lascialo correre per tutta la notte:

./test /dev/sdb

512 byte, le scritture allineate vanno bene, che ti darà un'intera pagina cancellata e riscritta. È possibile velocizzare significativamente il test utilizzando una dimensione del blocco più grande, ma diventa complicato arrivare a risultati concreti.

Attualmente sto testando su una chiavetta PNY da 4 GB piuttosto malconcia che ho trovato ieri sul marciapiede (sembrava essere ciò che era rimasto di un http://www3.pny.com/4GB-Micro-Sleek-Attach-- -Purple-P2990C418.aspx ).

Il programma sopra è essenzialmente una versione limitata di badblockse non vedresti errori fino a quando tutto lo spazio riservato non è stato esaurito. Pertanto, l'aspettativa (con 1 pagina scritta per iterazione) è che la procedura di cui sopra, in media, dovrebbe fallire nelle iterazioni riservate_page_count * write_cycle_limit (di nuovo, il livellamento dell'usura è una variabile principale). È un problema con le chiavette USB e le schede SD di solito non supportano SMART, che ha la capacità di segnalare le dimensioni dello spazio riservato.

A proposito, fsyncvs fdatasyncnon fa alcuna differenza per il dispositivo a blocchi che stai scrivendo, ai fini di questo test. Le tue open()modalità sono importanti.

Se sei curioso di conoscere i dettagli tecnici; ecco tutto ciò che potresti voler sapere (e altro ancora) sul funzionamento interno delle schede SD: https://www.sdcard.org/downloads/pls/simplified_specs/part1_410.pdf

Modifica: byte vs pagine: nel contesto di questi tipi di test, è importante pensare alle cose in termini di pagine, non di byte. Può essere molto fuorviante fare il contrario. Ad esempio, su una SD SanDisk da 8 GB, la dimensione della pagina in base al controller (accessibile tramite /sys/classes/mmc_host/mmc?/mmc?:????/preferred_erase_size) è di 4 MB. Scrivere 16 MB (allineato ai limiti di 4 MB), quindi cancellare / scrivere 4 pagine. Tuttavia, la scrittura di quattro byte singoli ciascuno a offset di 4 MB l'uno dall'altro cancella / scrive 4 pagine.

Non è accurato, quindi dire "Ho testato con scritture da 16 MB", poiché è la stessa quantità di usura di "Ho testato con scritture da 4 byte". Più precisamente, "Ho provato con 4 scritture di pagine".

Aggiungendo solo alcuni punti alla risposta di slm - nota che sono più adatti agli SSD che alle schede SD "stupide", dal momento che gli SSD giocano trucchi molto più sporchi con i tuoi dati (es. De-duplicazione):

• stai scrivendo 64 KB all'inizio del dispositivo - questo stesso ha due problemi:

  1. le celle flash di solito hanno dimensioni di blocchi di dimensioni da 16 KB in su (più probabilmente nell'intervallo 128-512 KB). Ciò significa che necessita di cache di almeno questa dimensione. Quindi scrivere 64 KB non mi sembra sufficiente.

  2. per soluzioni di fascia bassa (leggi "non enterprise") (e me lo aspetterei ancora di più per le schede SD / CF che per gli SSD) i produttori possono scegliere di rendere l'inizio del dispositivo più resistente all'usura rispetto al resto dal strutture importanti - la tabella delle partizioni e FAT sulla singola partizione sul dispositivo (la maggior parte delle schede di memoria utilizzano questa configurazione) - si trovano lì. Pertanto, testare l'inizio della carta potrebbe essere distorto.

• fdatasync() in realtà non garantisce che i dati vengano scritti sul supporto fisico (anche se probabilmente fa il meglio di ciò che è sotto il controllo del sistema operativo) - vedi la pagina man:

  La chiamata si blocca fino a quando il dispositivo segnala che il trasferimento è stato completato

  Non sarei troppo sorpreso se si scoprisse che esiste un piccolo condensatore, in grado di fornire energia per scrivere i dati memorizzati nella memoria flash in caso di perdita di energia esterna.

  In ogni caso, supponendo che sia presente una cache sulla scheda (vedi la mia risposta alla tua domanda su SU ), scrivere 64 KB e sincronizzare (con fdatasync()) non sembra essere abbastanza convincente per questo scopo. Anche senza alcun "backup di potenza", il firmware potrebbe comunque non essere sicuro e mantenere i dati non scritti per un po 'più a lungo di quanto ci si aspetterebbe (poiché in casi d'uso tipici non dovrebbe creare alcun problema).

• potresti voler leggere i dati prima di scrivere un nuovo blocco e confrontarlo, solo per assicurarti che funzioni davvero (e usa un buffer cancellato per la lettura, se sei abbastanza paranoico).

La risposta di Peterph mi ha fatto riflettere ulteriormente sulla questione della possibile memorizzazione nella cache. Dopo aver scavato, non posso ancora dire con certezza se alcune, alcune o tutte le schede SD lo fanno, ma penso che sia possibile.

Tuttavia, non credo che la memorizzazione nella cache comporterebbe dati più grandi del blocco di cancellazione. A dire il vero, ho ripetuto il test usando un pezzo da 16 MB invece di 64 kB. Questo è 1 / 250th il volume totale della scheda da 4 GB. Ci sono volute ~ 8 ore per farlo 10.000 volte. Se il livellamento dell'usura fa del suo meglio per distribuire il carico, ciò significa che ogni blocco fisico sarebbe stato usato 40 volte.

Non è molto, ma il punto originale del test era dimostrare l'efficacia del livellamento dell'usura mostrando che non potevo facilmente danneggiare la scheda attraverso ripetute scritture di modeste quantità di dati nella stessa posizione (apparente). IMO il precedente test da 64 kB era probabilmente reale - ma quello da 16 MB deve essere. Il sistema ha scaricato i dati sull'hardware e l'hardware ha segnalato la scrittura senza errori. Se si trattasse di un inganno, la scheda non sarebbe adatta a nulla e non può memorizzare nella cache 16 MB ovunque, ma nella memoria principale, che è ciò che il test intende stressare.

Si spera che 10.000 scritture da 16 MB ciascuna siano sufficienti per dimostrare che anche su una carta di marca di nome di fascia bassa (valore: $ 5 CDN), eseguire un file system radice rw 24/7 che scrive quotidianamente modeste quantità di dati non consumerà la scheda in un periodo di tempo ragionevole. 10.000 giorni sono 27 anni ... e la carta va ancora bene ...

Se venissi pagato per sviluppare sistemi che svolgevano un lavoro più pesante di quello, vorrei fare almeno alcuni test per determinare quanto può durare una carta . Il mio sospetto è che con uno come questo, che ha una bassa velocità di scrittura, potrebbero volerci settimane, mesi o anni di scrittura continua alla massima velocità (il fatto che non ci siano una gran quantità di test comparativi di questo tipo online parla al fatto che sarebbe un affare molto prolungato).

Per quanto riguarda la conferma che la scheda va ancora bene, non penso più che l'uso badblocksnella sua configurazione predefinita sia appropriato. Invece, l'ho fatto in questo modo:

badblocks -v -w -b 524288 -c 8

Il che significa testare usando un blocco da 512 kB ripetuto 8 volte (= 4 MB). Dal momento che si tratta di un test rw distruttivo, probabilmente sarebbe buono come il mio homespun per quanto riguarda lo stress del dispositivo se utilizzato in un ciclo continuo.

Ho anche creato un filesystem su di esso, copiato in un file da 2 GB, diffil file rispetto all'originale e poi - dato che il file era un .iso - lo ha montato come immagine e ho sfogliato il filesystem al suo interno.

La carta va ancora bene. Che probabilmente ci si aspetta, dopo tutto ...

;);)