Wczoraj wdałem się w krótką debatę na temat logiki i / lub prawdziwości mojej odpowiedzi , vis., Że rejestrowanie i utrzymywanie metadanych fs na karcie SD o przyzwoitym rozmiarze (GB +) nigdy nie będzie wystarczająco znaczące, aby ją nosić w rozsądnym czasie (lata i lata). Najpierw zdawało się, że muszę się mylić, ponieważ w Internecie jest tak wiele historii o ludziach, którzy mają na sobie karty SD.

Ponieważ mam urządzenia z kartami SD, które zawierają systemy plików rootkw rw pozostawione 24 godziny na dobę, 7 dni w tygodniu, przetestowałem tę zasadę wcześniej dla własnego zadowolenia. Ulepszyłem nieco ten test, powtórzyłem go (w rzeczywistości przy użyciu tej samej karty) i przedstawiam go tutaj. Dwa główne pytania, które mam, to:

1. Czy metoda, którą podjąłem, próbując zniszczyć kartę, jest wykonalna, pamiętając, że ma ona na celu odtworzenie efektów ciągłego ponownego zapisywania niewielkich ilości danych?
2. Czy metoda, której użyłem do sprawdzenia, czy karta jest nadal w porządku, jest wykonalna?

Zadaję tutaj pytanie zamiast SO lub SuperUser, ponieważ sprzeciw wobec pierwszej części prawdopodobnie musiałby stwierdzić, że mój test tak naprawdę nie zapisał się na karcie w sposób, w jaki jestem pewien, i twierdzenie, że wymagałoby to trochę specjalna znajomość systemu Linux.

[Możliwe też, że karty SD używają pewnego rodzaju inteligentnego buforowania lub pamięci podręcznej, tak że wielokrotne zapisy w tym samym miejscu byłyby buforowane / buforowane w miejscu mniej podatnym na zużycie. Nigdzie nie znalazłem żadnych oznak tego, ale pytam o to na SU]

Ideą testu jest zapisanie tego samego małego bloku na karcie miliony razy. Jest to znacznie ponad twierdzenie, ile cykli zapisu może wytrzymać takie urządzenie, ale zakładając, że poziomowanie zużycia jest skuteczne, jeśli karta ma przyzwoity rozmiar, miliony takich zapisów wciąż nie powinny mieć większego znaczenia, ponieważ „ten sam blok” nie może być dosłownie tym samym fizycznym blokiem. Aby to zrobić, musiałem upewnić się, że każdy zapis był naprawdę zapisany na sprzęcie i w tym samym widocznym miejscu.

W przypadku opróżniania ze sprzętu korzystałem z wywołania biblioteki 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;
}                                 

Pracowałem przez około 8 godzin, aż zgromadziłem 2 miliony + zapisów na początku /dev/sdb1partycji. ¹ Mogłem po prostu łatwo użyć /dev/sdb(surowe urządzenie, a nie partycję), ale nie widzę, jaka to by różnica.

Następnie sprawdziłem kartę, próbując utworzyć i zamontować system plików /dev/sdb1. To zadziałało, wskazując, że konkretny blok, do którego pisałem całą noc, był wykonalny. Nie oznacza to jednak, że niektóre obszary karty nie zostały zużyte i przesunięte przez wyrównanie zużycia, ale pozostawiono dostępne.

Aby to sprawdzić, użyłem badblocks -v -wna partycji. Jest to niszczący test odczytu / zapisu, ale wyrównywanie zużycia, czy nie, powinno być silnym wskaźnikiem wykonalności karty, ponieważ wciąż musi zapewniać miejsce dla każdego ciągłego zapisu. Innymi słowy, jest to dosłowny odpowiednik całkowitego wypełnienia karty, a następnie sprawdzenia, czy wszystko było w porządku. Kilka razy, odkąd pozwalam badblockom działać według kilku wzorców.

[Komentarze Contra Jason C poniżej, nie ma nic złego lub fałszywego w używaniu badblocków w ten sposób. Chociaż nie byłoby przydatne do faktycznej identyfikacji uszkodzonych bloków ze względu na naturę kart SD, jest w porządku do wykonywania destrukcyjnych testów odczytu i zapisu o dowolnej wielkości za pomocą przełączników -bi -c, czyli tam, gdzie poszedł poprawiony test (patrz moja własna odpowiedź ). Żadna ilość magii ani pamięci podręcznej kontrolera karty nie może oszukać testu, w którym kilka megabajtów danych można zapisać na sprzęcie i odczytać ponownie poprawnie. Inne komentarze Jasona wydają się opierać na błędnym odczytaniu - IMO jest celowe , dlatego nie zadałem sobie trudu, aby się kłócić. Z podniesioną głową pozostawiam czytelnikowi decyzję, co ma sens, a co nie .]

¹ Karta była starą kartą Sandisk o pojemności 4 GB (nie ma na niej numeru „klasy”), której prawie nie używałem. Jeszcze raz pamiętajcie, że to nie 2 miliony pisze dosłownie w tym samym fizycznym miejscu; z powodu wyrównywania zużycia „pierwszy blok” będzie stale przesuwany przez kontroler podczas testu, aby, jak to określa termin, wyrównać zużycie.

Myślę, że testowanie karty SD w stresie jest ogólnie problematyczne, biorąc pod uwagę 2 rzeczy:

1. poziomowanie zużycia Nie ma gwarancji, że jeden zapis do drugiego faktycznie wykonuje te same fizyczne lokalizacje na karcie SD. Pamiętaj, że większość istniejących systemów SD aktywnie przejmuje blok, jaki znamy, i przesuwa fizyczną lokalizację, która go popiera, w oparciu o postrzegane „zużycie”, któremu poddano każdą lokalizację.

2. różne technologie (MLC vs. SLC) Innym problemem, który z tym widzę, jest różnica w technologiach. Typy SLC SSD Oczekiwałbym, że będę miał o wiele dłuższą żywotność w porównaniu z odmianą MLC. Poza tym MLC ma o wiele ściślejsze tolerancje, z którymi po prostu nie musisz sobie radzić w SLC, a przynajmniej są o wiele bardziej tolerancyjne w przypadku niepowodzenia w ten sposób.

   • MLC - Multi Level Cell
   • SLC - komórka jednopoziomowa

Problem z MLC polega na tym, że dana komórka może przechowywać wiele wartości, bity są zasadniczo układane w stos przy użyciu napięcia, a nie tylko na przykład fizycznego + 5 V lub 0 V, więc może to prowadzić do znacznie wyższego potencjału awaryjności niż ich SLC odpowiednik.

Długość życia

Znalazłem ten link, który trochę dyskutuje o tym, jak długo może trwać sprzęt. Nosi tytuł: Know Your SSDs - SLC vs. MLC .

SLC

Według najlepszych szacunków SSDS SLC można w większości obliczyć, aby żyć gdziekolwiek od 49 do 149 lat. Testowanie Memoright może potwierdzić, że dysk SSD 128 Gb ma trwałość zapisu ponad 200 lat, przy średnim zapisie 100 Gb dziennie.

MLC

W tym przypadku projekt MLC nie działa. Żadne nie zostały jeszcze wydane. Nikt tak naprawdę nie sprawdził, jaka długość życia jest zapewniona dzięki MLC, poza tym, że będzie znacznie niższa. Otrzymałem kilka różnych przekonań, których średnia długość wynosi od 10 do 1 na korzyść projektu SLC. Konserwatywnym przypuszczeniem jest to, że większość szacunków dotyczących długości życia przyjdzie między 7 a 10 lat, w zależności od zaawansowania „algorytmów wyrównywania zużycia” w kontrolerach każdego producenta.

Porównania

Aby narysować porównanie za pomocą cykli zapisu, żywotność SLC miałaby 100 000 pełnych cykli zapisu w porównaniu z MLC, który ma żywotność 10 000 cykli zapisu. Może to znacznie wzrosnąć w zależności od zastosowanej konstrukcji „wyrównywania zużycia”.

Istnieje wiele problemów z testem, niektóre są rozmyte, niektóre nie. To zależy również od twojego celu. Dwa subtelne, niejasne problemy to:

• Nie czytasz z tego samego obszaru, do którego piszesz, zatem test odczytu skutecznie nic nie robi (chyba że kontroler ma korekcję zakłóceń odczytu, w którym to przypadku może czasami przenieść czytaną stronę w inne miejsce, ale nadal tak jest nie wpływa na twój test).
• Zakładasz (i jest prawdopodobne, ale nie jest to gwarantowane), że sterownik odczytuje / zapisuje do złego bloku i zgłasza go - chcesz zapisać dane, odczytać je z powrotem i porównać w celu sprawdzenia.

Są to jednak zapewne pedantyczne. Poważniejsze jest:

• Nie można używać badblocksdo wyświetlania stron, które uległy awarii w pamięci flash; wszystkie wykrycia awarii i kolejne mapowania stron są wykonywane przez kontroler i są przezroczyste dla systemu operacyjnego. Możesz uzyskać informacje od SMART, jeśli dysk obsługuje tę funkcję (nie znam żadnych kart SD, które ją obsługują, być może są to dyski wyższej klasy).
• Wyrównanie zużycia, skomplikowane przez test, nieuwzględniające wcześniejszych poleceń TRIM, stanu wolnego / zużytego napędu podczas testu oraz zarezerwowanego miejsca.

Wyrównanie zużycia : Głównym problemem jest to, że poziom zużycia jest główną zmienną w teście. Zdarza się to na kontrolerze (zwykle), a w każdym razie jest przezroczysty, nawet dla bezpośredniego wyszukiwania urządzenia + odczytu / zapisu. W twoim przykładzie tak naprawdę nie znasz stanu wyrównywania zużycia (w szczególności, czy ostatnio wydano polecenia TRIM do wolnych bloków?) ...

W przypadku dynamicznego wyrównywania zużycia (obecnego w praktycznie wszystkich urządzeniach pamięci masowej klasy konsumenckiej) urządzenie może być w dowolnym stanie: z jednej strony żadna ze stron nie jest oznaczona jako wolna, a więc tylko te strony muszą działać z są tymi w zarezerwowanym miejscu (jeśli istnieją). Zauważ, że jeśli w urządzeniu jest zarezerwowane miejsce, będzie ono musiało całkowicie zawieść, zanim zaczniesz gwarantować niepowodzenie zapisów stron (zakładając, że nie ma żadnych innych stron oznaczonych jako wolne). Z drugiej strony, każda strona jest oznaczona jako wolna, w takim przypadku teoretycznie musisz spowodować awarię każdej strony w urządzeniu, zanim zaczniesz widzieć błędy zapisu.

W przypadku statycznego wyrównywania zużycia (które zwykle mają dyski SSD, karty SD zwykle nie mają, a dyski USB różnią się): Naprawdę nie można tego obejść, oprócz wielokrotnego pisania na każdej stronie urządzenia.

... Innymi słowy, istnieją szczegóły dotyczące wyrównywania zużycia, o których nie możesz wiedzieć, a na pewno nie ma sposobu kontrolowania - w szczególności, czy jest używane dynamiczne wyrównywanie zużycia, czy jest używane wyrównywanie zużycia statycznego, czy też nie. ilość miejsca zarezerwowanego na urządzeniu do wyrównywania zużycia (które nie jest widoczne poza sterownikiem [lub sterownikiem w niektórych przypadkach, takim jak stary DiskOnChip M-Systems]).

SLC / MLC: W przypadku SLC vs. MLC ma to bardzo bezpośredni wpływ na granice, których można się spodziewać, ale ogólna procedura wyrównywania zużycia i procedura testowania są takie same dla obu. Wielu dostawców nie publikuje, czy ich urządzenia są SLC lub MLC dla ich tańszych produktów konsumenckich, chociaż każdy dysk flash, który twierdzi, że limit cyklu na stronę wynosi 100 000+, jest prawdopodobnie SLC (uproszczony kompromis to SLC = wytrzymałość, MLC = gęstość).

Buforowanie: Jeśli chodzi o buforowanie, jest trochę niepewne. Na poziomie systemu operacyjnego, oczywiście, w ogólnym przypadku fsync / fdatasync nie gwarantuje, że dane są rzeczywiście zapisane. Jednak myślę, że można bezpiecznie założyć, że jest (lub przynajmniej kontroler zobowiązał się do tego, tj. Zapis nie zostanie połknięty w pamięci podręcznej) w tym przypadku, ponieważ dyski wymienne są zwykle zaprojektowane dla wspólnego wzorca „wysunięcie” (odmontowanie> synchronizacja), a następnie usunięcie (odcięcie zasilania). Chociaż nie jesteśmy tego pewni, wyedukowane przypuszczenie mówi, że można bezpiecznie założyć, że synchronizacja gwarantuje, że zapis odbędzie się absolutnie, szczególnie w przypadku zapisu -> synchronizacji -> odczytu (gdyby nie, dyski byłyby zawodne po wysunięciu). Nie ma innego polecenia poza „synchronizacją”, które można wydać po wysunięciu.

U kontrolera wszystko jest możliwe, ale powyższe założenie obejmuje również założenie, że przynajmniej kontroler nie robi niczego „na tyle skomplikowanego”, aby ryzykować utratę danych po synchronizacji. Można sobie wyobrazić, że administrator może, powiedzmy, buforować i grupowo zapisywać lub nie zapisywać danych, jeśli te same dane są przepisywane (w ograniczonym zakresie). W poniższym programie przełączamy się między dwoma różnymi blokami danych i przeprowadzamy synchronizację przed ponownym odczytem, ​​aby pokonać rozsądny mechanizm buforowania kontrolera. Oczywiście nadal nie ma gwarancji i nie ma możliwości poznania, ale możemy przyjąć rozsądne założenia w oparciu o normalne użycie tych urządzeń i rozsądne / powszechne mechanizmy buforowania.

Testowanie:

Niestety prawda jest taka, że ​​jeśli nie wiesz, że urządzenie nie ma zarezerwowanego miejsca i nie wykonuje statycznego poziomowania, nie ma sposobu, aby ostatecznie przetestować limit cyklu określonej strony. Jednak najbliższe, jakie możesz uzyskać, jest następujące (nie zakładaj statycznego wyrównywania zużycia):

Pierwszą rzeczą, którą musisz zrobić, to wypełnić całą kartkę z danymi. Jest to ważne i jest to główna zmienna, która pozostała w oryginalnym teście. Oznacza to tyle bloków, ile jest używanych, poza zarezerwowanym miejscem (do którego nie masz dostępu). Pamiętaj, że pracujemy z całym urządzeniem (na którym to zniszczy wszystkie dane), ponieważ praca z jedną partycją wpływa tylko na jeden określony obszar na urządzeniu:

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

Jeśli jesteś typem paska postępu:

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

Edycja: w przypadku kart z 4 MB blokami wymazywania wypróbuj to, aby przyspieszyć zapis:

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

Następnie możesz napisać cykliczny program testowy w następujący sposób, wykorzystując O_DIRECTi O_SYNC(i prawdopodobnie paranoiczne, nadmiarowe użycie fsync()), aby wyciąć jak najwięcej buforowania systemu operacyjnego i buforować obraz, jak to możliwe, i teoretycznie napisać bezpośrednio do kontrolera i poczekaj, aż zgłosi zakończenie operacji:

#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;

    }

}

Zauważ, że dla O_DIRECTbufory muszą być odpowiednio wyrównane. Na ogół wystarczające są 512-bajtowe granice. Możesz skompilować z:

g++ -O0 test.cpp -o test

Dodaj w -D_POSIX_C_SOURCE=200112Lrazie potrzeby.

Następnie, po napełnieniu urządzenia jak wyżej, po prostu pozostaw go uruchomione przez noc:

./test /dev/sdb

512 bajtów, wyrównane zapisy są w porządku, dzięki czemu jedna cała strona zostanie usunięta i przepisana. Możesz znacznie przyspieszyć test, używając większego rozmiaru bloku, ale wtedy komplikowanie osiąga konkretne wyniki.

Obecnie testuję na raczej oszałamiająco wyglądającym dysku PGB o pojemności 4 GB, który znalazłem wczoraj na chodniku (wyglądało na to, co pozostało z http://www3.pny.com/4GB-Micro-Sleek-Attach-- -Purple-P2990C418.aspx ).

Powyższy program jest w zasadzie ograniczoną wersją badblocksi nie zobaczysz awarii, dopóki cała zarezerwowana przestrzeń nie zostanie wyczerpana. Dlatego oczekuje się (przy zapisaniu 1 strony na iterację), że powyższa procedura powinna zakończyć się niepowodzeniem w iteracjach zastrzeżone_page_count * write_cycle_limit (ponownie, poziom zużycia jest główną zmienną). Szkoda, że ​​pendrive'y i karty SD zwykle nie obsługują SMART, który ma możliwość zgłaszania zarezerwowanego miejsca.

Nawiasem mówiąc, fsyncvs fdatasyncnie robi różnicy, ponieważ urządzenie blokowe pisze, że robisz, na potrzeby tego testu. Twoje open()tryby są ważne.

Jeśli jesteś ciekawy szczegółów technicznych; oto wszystko, co możesz chcieć wiedzieć (i więcej) o wewnętrznym działaniu kart SD: https://www.sdcard.org/downloads/pls/simplified_specs/part1_410.pdf

Edycja: Bajty kontra strony: w kontekście tego typu testów ważne jest, aby myśleć o rzeczach w kategoriach stron, a nie bajtów. Postępowanie odwrotne może być bardzo mylące. Na przykład w przypadku karty SanDisk 8 GB SD rozmiar strony według kontrolera (dostępny przez /sys/classes/mmc_host/mmc?/mmc?:????/preferred_erase_size) wynosi pełne 4 MB. Zapis 16 MB (wyrównany do granic 4 MB), a następnie skasuj / zapisuje 4 strony. Jednak pisanie czterech pojedynczych bajtów, każdy w odstępach 4 MB, powoduje również usunięcie / zapisanie 4 stron.

Mówienie „testowałem z 16 MB zapisów” jest niedokładne, ponieważ oznacza to tyle samo zużycia, co „testowałem z zapisaniem 4 bajtów”. Dokładniej: „Testowałem przy zapisie 4 stron”.

Po prostu dodając kilka punktów do odpowiedzi SLM - pamiętaj, że są one bardziej odpowiednie dla dysków SSD niż dla „głupich” kart SD, ponieważ dyski SSD odgrywają z twoimi danymi znacznie brudniejsze sztuczki (np. Usuwanie duplikatów):

• piszesz 64 KB na początku urządzenia - to ma dwa problemy:

  1. komórki flash zwykle mają bloki kasowania o wielkości od 16 KB w górę (bardziej prawdopodobne w zakresie 128-512 KB). Co oznacza, że ​​potrzebuje pamięci podręcznej przynajmniej tej wielkości. Stąd pisanie 64 KB nie wydaje mi się wystarczające.

  2. w przypadku rozwiązań niskiej klasy (czytaj „nie dla przedsiębiorstw”) (i spodziewałbym się tego jeszcze bardziej w przypadku kart SD / CF niż w przypadku dysków SSD) producenci mogą zdecydować, aby początek urządzenia był bardziej odporny na zużycie niż reszta, ponieważ ważne struktury - tablica partycji i FAT na pojedynczej partycji w urządzeniu (większość kart pamięci korzysta z tej konfiguracji) - znajdują się tam. Dlatego testowanie początku karty może być stronnicze.

• fdatasync() tak naprawdę nie gwarantuje, że dane zostaną zapisane na nośniku fizycznym (chociaż prawdopodobnie robi to najlepiej, co jest pod kontrolą systemu operacyjnego) - zobacz stronę podręcznika:

  Połączenie zostanie zablokowane, dopóki urządzenie nie zgłosi zakończenia przesyłania

  Nie byłbym zbytnio zaskoczony, gdyby okazało się, że istnieje mały kondensator, który jest w stanie zapewnić energię do zapisywania danych w pamięci podręcznej w pamięci flash w przypadku utraty zasilania zewnętrznego.

  W każdym razie, przy założeniu, że na karcie znajduje się pamięć podręczna (patrz moja odpowiedź na twoje pytanie na SU ), pisanie 64 KB i synchronizacja (z fdatasync()) nie wydaje się wystarczająco przekonująca do tego celu. Nawet bez „zasilania awaryjnego” oprogramowanie wewnętrzne może nadal odtwarzać je w sposób niebezpieczny i przechowywać dane niepisane przez nieco dłużej, niż można by się spodziewać (ponieważ w typowych przypadkach użytkowania nie powinno to powodować żadnych problemów).

• możesz przeczytać dane przed napisaniem nowego bloku i porównaniem go, aby upewnić się, że naprawdę działa (i użyj wyczyszczonego bufora do odczytu, jeśli jesteś wystarczająco paranoikiem).

Odpowiedź Peterpha skłoniła mnie do dalszego rozważania kwestii możliwego buforowania. Po przekopaniu wciąż nie jestem pewien, czy są to jakieś, niektóre lub wszystkie karty SD, ale myślę, że jest to możliwe.

Nie sądzę jednak, aby buforowanie wymagało danych większych niż blok wymazywania. Aby być naprawdę pewnym, powtórzyłem test, używając 16 MB fragmentu zamiast 64 kB. To 1/25 całkowitej pojemności karty 4 GB. Wykonanie tego zajęło 10 000 razy około 8 godzin. Jeśli wyrównanie zużycia najlepiej rozłoży obciążenie, oznacza to, że każdy blok fizyczny zostałby wykorzystany 40 razy.

To niewiele, ale pierwotnym punktem testu było wykazanie skuteczności wyrównywania zużycia , pokazując, że nie mogłem łatwo uszkodzić karty poprzez wielokrotne zapisywanie niewielkich ilości danych w tym samym (pozornym) miejscu. IMO poprzedni test 64 kB był prawdopodobnie prawdziwy - ale 16 MB musi być. System opróżnił dane do sprzętu, a sprzęt zgłosił zapis bez błędu. Gdyby to było oszustwo, karta nie byłaby do niczego przydatna i nie mogłaby buforować 16 MB nigdzie indziej niż w podstawowej pamięci, co test ma na celu podkreślić.

Mamy nadzieję, że 10 000 zapisów po 16 MB każdy wystarczy, aby wykazać, że nawet na najniższej karcie marki (wartość: 5 USD CDN), uruchamianie systemu plików rootkw rw 24/7, który zapisuje niewielkie ilości danych dziennie , nie zużyje karty rozsądny okres czasu. 10 000 dni to 27 lat ... a karta jest nadal w porządku ...

Jeśli otrzymywałbym wynagrodzenie za opracowywanie systemów, które działałyby ciężej, chciałbym wykonać co najmniej kilka testów, aby określić, jak długo karta może trwać. Mam przeczucie, że przy takim, który ma niską prędkość zapisu, może zająć tygodnie, miesiące lub lata ciągłego pisania z maksymalną prędkością (fakt, że nie ma zbyt wielu testów porównawczych tego rodzaju w Internecie, mówi do fakt, że byłby to bardzo długotrwały romans).

Jeśli chodzi o potwierdzenie, że karta jest nadal w porządku, nie sądzę, aby używanie badblocksjej w domyślnej konfiguracji było właściwe. Zamiast tego zrobiłem to w ten sposób:

badblocks -v -w -b 524288 -c 8

Co oznacza testowanie przy użyciu bloku 512 kB powtórzonego 8 razy (= 4 MB). Ponieważ jest to niszczycielski test rw, prawdopodobnie byłby dobry jak mój własny, jeśli chodzi o obciążanie urządzenia, gdyby był używany w ciągłej pętli.

Stworzyłem na nim również system plików, skopiowałem go diffdo pliku o wielkości 2 GB, a następnie plik z oryginałem, a następnie - ponieważ plik był plikiem .iso - zamontowałem go jako obraz i przejrzał wewnątrz niego system plików.

Karta jest nadal w porządku. Czego można się spodziewać w końcu ...

;);)