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:
- 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?
- 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/sdb1
partycji. 1 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 -w
na 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 -b
i -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 .]
1 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.
badblocks
do wyświetlania błędów strony na dysku flash (i twierdzenie, że jest to bardzo mylące). Są one obsługiwane przez kontroler i mapowane w celu zarezerwowania miejsca po wykryciu. Fizyczny układ danych na dysku nie jest taki sam jak fizyczny układ, który widzisz podczas wykonywania operacji we / wy, w ten sposób wyrównanie zużycia zachowuje przejrzystość. Nic z tego nie jest dla ciebie widoczne podczas operacji we / wy. Co najwyżej, jeśli dysk obsługuje SMART, możesz uzyskać trochę informacji o awariach i pozostałym zarezerwowanym miejscu z kontrolera./dev/sdb1
vs,/dev/sdb
to nie ma znaczenia dla twojego programu, ale to, co robi różnicę (jak opisano poniżej), to to, że stan nieużywanych bloków na twoim urządzeniu jest nieznany i nie został uwzględniony w teście, i dopóki nie wypełnisz całego urządzenia (np./dev/sdb
), w pierwszej kolejności danych, stopień wyrównywania zużycia przestrzeni musi być znaczącą zmienną. Tak więc, podczas gdy urządzenie vs. partycja nie ma znaczenia dla twojego testu, jest to głównie konsekwencja wadliwego testu, ponieważ po prawidłowym wypełnieniu urządzenia danymi, na partycję nie będzie dostępna opcja (chyba że sformatujesz później).Odpowiedzi:
Myślę, że testowanie karty SD w stresie jest ogólnie problematyczne, biorąc pod uwagę 2 rzeczy:
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ę.
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.
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
MLC
Porównania
źródło
fstrim
potem nie możesz / nie możesz, całkowicie wyłączyłeś dynamiczne wyrównywanie zużycia [trudno byłoby znaleźć kartę SD klasy konsumenckiej ze statycznym wyrównywaniem zużycia] przez oznaczanie każdej strony jako użytej.)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:
Są to jednak zapewne pedantyczne. Poważniejsze jest:
badblocks
do 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 : 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:
Jeśli jesteś typem paska postępu:
Edycja: w przypadku kart z 4 MB blokami wymazywania wypróbuj to, aby przyspieszyć zapis:
Następnie możesz napisać cykliczny program testowy w następujący sposób, wykorzystując
O_DIRECT
iO_SYNC
(i prawdopodobnie paranoiczne, nadmiarowe użyciefsync()
), 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:Zauważ, że dla
O_DIRECT
bufory muszą być odpowiednio wyrównane. Na ogół wystarczające są 512-bajtowe granice. Możesz skompilować z:Dodaj w
-D_POSIX_C_SOURCE=200112L
razie potrzeby.Następnie, po napełnieniu urządzenia jak wyżej, po prostu pozostaw go uruchomione przez noc:
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ą
badblocks
i 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,
fsync
vsfdatasync
nie robi różnicy, ponieważ urządzenie blokowe pisze, że robisz, na potrzeby tego testu. Twojeopen()
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”.
źródło
dd
po zapisaniu 250 MB nie działa. . Uszkodzenie pojawiło się dopiero po zakończeniu cyklu zasilania. Napęd kciuka PNY pozostaje niezmieniony po iteracjach ~ 30 mil. Zmodyfikowałem powyższy program (nie odzwierciedlony w powyższym kodzie), aby za każdym razem zapisywać w losowych lokalizacjach wyrównanych do 16kB zamiast tego samego, ale zrobiłem to po iteracjach ~ 4 mil na SD. Ponownie przetestuje przy użyciu nowej karty.dd
na tej karcie przekroczyła granicę 250 MB, a wydajność zapisu ponownie wzrosła do pełnych 4 MB / s do obszarów po tym punkcie. Oczekuję jednak, że wydajność będzie nieprzewidywalna, ponieważ bloki są nadal tasowane. Nie powiedziałbym, że karta jest zniszczona, ale na pewno nie jest w 100%.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:
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.
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: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).
źródło
read
w teście jest konieczne, dodaje żadnych informacji i nie ma znaczenia dla badania cyklu zapisu. Dla prawdziwego testu będziesz chciał odczytać właśnie napisany blok i zatwierdzić go, chyba że masz pewność, że kontroler może wykryć i zgłosić wszystkie tryby awarii.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
badblocks
jej w domyślnej konfiguracji było właściwe. Zamiast tego zrobiłem to w ten sposób: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
diff
do 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 ...
;);)
źródło
badblocks
nie wyświetli stron , które uległy awarii w pamięci flash. Nie jest to odpowiednie narzędzie do tego zadania i nie można go używać do wyszukiwania stron flashowanych. Gdy kontroler wykryje awarię, wewnętrznie oznaczy stronę jako złą i ponownie przypisze ją do strony w zarezerwowanym miejscu. Wszystko to dzieje się za kontrolerem i nie jest dla ciebie widoczne, nawet na zrzucie surowego urządzenia . Możesz uzyskać informacje z kontrolera, jeśli SMART jest obsługiwany. Fizyczna kolejność danych na urządzeniu nie zgadza się z kolejnością bajtów widoczną podczas wykonywania operacji we / wy na urządzeniu.dd
nie udało się zapisać około 250 MB znak. Przy trzeciejdd
próbie przekroczył 250 MB, a kiedy to zrobił, wydajność zapisu ponownie wzrosła w tych obszarach. Nie powiedziałbym, że karta jest zniszczona, ale na pewno nie jest w 100%.