Linux – zátěžové testování SD karet pomocí Linuxu?

Včera jsem se s někým dostal do malé debaty ohledně logiky a/nebo pravdivosti mé odpovědi zde, vis., že logování a udržování fs metadat na slušné SD kartě (GB+) nemůže být nikdy dost významné, aby se karta mohla nosit. v přiměřeném čase (roky a roky). Jistota protiargumentu byla taková, že se musím mýlit, protože na internetu je tolik příběhů lidí, kteří nosí SD karty.

Vzhledem k tomu, že mám zařízení s SD kartami obsahujícími rw kořenové souborové systémy, které jsou ponechány 24/7, otestoval jsem premisu již dříve k mé vlastní spokojenosti. Tento test jsem trochu upravil, zopakoval (ve skutečnosti s použitím stejné karty) a předkládám jej zde. Dvě hlavní otázky, které mám, jsou:

1. Je metoda, kterou jsem použil při pokusu o zničení karty, životaschopná, přičemž je třeba mít na paměti, že jejím účelem je reprodukovat efekty neustálého přepisování malých množství dat?
2. Je metoda, kterou jsem použil k ověření karty, stále v pořádku?

Otázku dávám spíše sem než S.O. nebo SuperUser, protože námitka k první části by pravděpodobně musela tvrdit, že můj test ve skutečnosti nezapsal na kartu tak, jak jsem si jist, a tvrzení, že by to vyžadovalo určité speciální znalosti linuxu.

[Může se také stát, že SD karty používají nějaký druh chytrého ukládání do vyrovnávací paměti nebo mezipaměti, takže opakované zápisy na stejné místo by byly ukládány do vyrovnávací paměti/ukládány do mezipaměti někde méně náchylné k opotřebení. Nikde jsem o tom nenašel žádný náznak, ale ptám se na to na S.U.]

Myšlenkou testu je zapsat do stejného malého bloku na kartě milionkrát. To je daleko za jakýmkoli tvrzením o tom, kolik cyklů zápisu taková zařízení vydrží, ale za předpokladu, že vyrovnávání opotřebení je efektivní, pokud má karta slušnou velikost, miliony takových zápisů by stále neměly příliš záležet, protože „stejný blok“ by ne být doslova stejný fyzický blok. Abych to mohl udělat, potřeboval jsem se ujistit, že každý zápis byl skutečně zapsán do hardwaru a do stejného zjevného místo.

Pro vyprázdnění do hardwaru jsem se spoléhal na volání knihovny 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;
}                                 

Spustil jsem to ~8 hodin, dokud jsem nenasbíral 2 miliony+ zápisů na začátek /dev/sdb1 rozdělit. Mohl jsem jednoduše použít /dev/sdb (surové zařízení a ne oddíl), ale nevidím, jaký by to znamenalo rozdíl.

Poté jsem zkontroloval kartu pokusem o vytvoření a připojení souborového systému na /dev/sdb1 . To fungovalo, což naznačuje, že konkrétní blok, do kterého jsem celou noc psal, byl proveditelný. Neznamená to však, že některé oblasti karty nebyly opotřebené a posunuté vyrovnáváním opotřebení, ale zůstaly přístupné.

Abych to otestoval, použil jsem badblocks -v -w na přepážce. Toto je destruktivní test čtení a zápisu, ale vyrovnávání opotřebení nebo ne, mělo by to být silným ukazatelem proveditelnosti karty, protože musí stále poskytovat prostor pro každý postupný zápis. Jinými slovy, je to doslovný ekvivalent úplného vyplnění karty a následné kontroly, zda je vše v pořádku. Několikrát, protože jsem nechal špatné bloky projít několika vzory.

Související:MVC Unit Testing ?

[Oproti komentářům Jasona C níže, není nic špatného nebo nesprávného na používání badblocks tímto způsobem. I když by to nebylo užitečné pro skutečnou identifikaci špatných bloků kvůli povaze SD karet, je to dobré pro provádění destruktivních testů čtení a zápisu libovolné velikosti pomocí -b a -c přepínačů, což je místo, kde revidovaný test prošel (viz moje vlastní odpověď). Žádné množství magie nebo ukládání do mezipaměti řadičem karty nemůže oklamat test, kdy lze na hardware zapsat několik megabajtů dat a znovu je správně načíst. Zdá se, že Jasonovy další komentáře jsou založeny na nesprávném čtení – IMO záměrně jeden, a proto jsem se neobtěžoval hádat. S touto hlavou vzhůru nechávám na čtenáři, aby se rozhodl, co dává smysl a co ne .]

Karta byla stará 4GB karta Sandisk (nemá na sobě číslo „třídy“), kterou jsem sotva použil. Ještě jednou mějte na paměti, že to nejsou 2 miliony zápisů doslova na stejné fyzické místo; v důsledku vyrovnávání opotřebení se „první blok“ během testu neustále pohybuje ovladačem, aby, jak je uvedeno v termínu, vyrovnal opotřebení.

Přijatá odpověď:

Myslím, že zátěžové testování SD karty je obecně problematické vzhledem ke dvěma věcem:

1. vyrovnávání opotřebení
   Neexistují žádné záruky, že jeden zápis na další skutečně vykonává stejná fyzická umístění na SD. Pamatujte, že většina zavedených systémů SD aktivně přijímá blok, jak jej známe, a přesouvá fyzickou polohu, která jej podporuje, na základě vnímaného „opotřebení“, kterému bylo každé místo vystaveno.

2. různé technologie (MLC vs. SLC)
   Dalším problémem, který v tom vidím, je rozdíl v technologiích. SLC typy SSD Očekával bych, že budou mít mnohem delší životnost v porovnání s odrůdou MLC. Na MLC jsou také mnohem přísnější tolerance, které u SLC prostě nemusíte řešit, nebo jsou alespoň mnohem tolerantnější k selhání tímto způsobem.

   • MLC – Multi Level Cell
   • SLC – Single Level Cell

Problém s MLC je v tom, že daná buňka může ukládat více hodnot, bity jsou v podstatě naskládány pomocí napětí, spíše než aby to byly například fyzické +5V nebo 0V, takže to může vést k mnohem vyššímu potenciálu poruchovosti než jejich SLC. ekvivalentní.

Očekávaná délka života

Našel jsem tento odkaz, který trochu pojednává o tom, jak dlouho může hardware vydržet. Jmenuje se:Poznejte své SSD – SLC vs. MLC.

SLC

SLC ssds lze spočítat, že z větší části budou žít kdekoli mezi 49 lety a 149 lety v průměru, podle nejlepších odhadů. Testování Memoright může ověřit 128Gb SSD s životností zápisu přesahující 200 let s průměrnou rychlostí zápisu 100Gb za den.

MLC

Zde návrh mlc nedosahuje. Dosud nebyly propuštěny žádné. Nikdo skutečně nezkoumal, jaký druh délky života je zajištěn s mlc, kromě toho, že bude podstatně nižší. Obdržel jsem několik různých názorů, jejichž průměrná životnost je 10 ku 1 ve prospěch designu slc. Konzervativní odhad je, že většina odhadů životnosti bude mezi 7 a 10 lety, v závislosti na pokroku „algorytmů vyrovnávání opotřebení“ v ovladačích každého výrobce.

Srovnání

Pro srovnání pomocí cyklů zápisu by měl slc životnost 100 000 úplných cyklů zápisu ve srovnání s mlc, který má životnost 10 000 cyklů zápisu. To by se mohlo výrazně zvýšit v závislosti na použité konstrukci „vyrovnání opotřebení“.