_jta_ wrote: zrobić kopię ze 3 razy, potem porównać.
- jest to jakaś metoda, aczkolwiek można wykorzystać dziennik, zrobić jedną kopię i potem uzupełniać błędnie odczytane obszary. Przy błędnych/niestabilnych odczytach można tę metodę wykorzystać do statystycznego poprawienia rezultatu odczytu (niestabilnie czytające się bity powinny statystycznie częściej przeczytać się poprawnie, niż błędnie, więc kilkukrotny odczyt powinien poprawić rezultat. Wprawdzie nie do ideału, ale przynajmniej ograniczyć liczbę błędów do poziomu pozwalającego skorygowanie ich kodami ECC. Tyle, że to już by trzeba było robić na poziomie bitów, a nie sektorów, a robienie tego manualnie będzie zbyt czaso/pracochłonne. Trzeba by się podeprzeć narzędziami, jakich Autorka zapewne nie ma. Dysponując takimi narzędziami można też się podeprzeć read-retry, co pozwala na zmiany progów napięć odniesienia na komparatorze i daje szansę na trafienie w taką wartość, przy jakiej odczyt stron będzie wystarczająco poprawny, by resztę skorygowało ECC. Ale to też nie na domowe warunki. Dlatego zacząłbym od jednej kopii, oceny rezultatu i wtedy zastanowił się nad dalszymi krokami.
_jta_ wrote: Dobrze byłoby rozpoznać rozmiar klastra i gdzie się zaczynają
- informacja o tym powinna być w boot-rekordzie - o ile nie jest uszkodzony. Jeśli jest uszkodzony, da się to wyliczyć np. na podstawie rozmiaru tablic alokacji plików. To pendrive, więc zakładam, że najprawdopodobniej to FAT. Przy tym rozmiarze pendriva, spodziewam się, że FAT32, ale to trzeba sprawdzić = potrzebujemy więcej informacji od Autorki. W każdym razie ustalenie rozmiaru klastra nie powinno być dla nas poważną przeszkodą.
ken-wawa wrote: To, że czegoś nie wiesz
- to akurat wiem.
ken-wawa wrote: komputery uczą pokory i tego, że nigdy nie wie się wszystkiego.
- tak, właśnie Ci wskazałem jedną z rzeczy, o jakich nie masz elementarnego pojęcia, a Ty, zamiast wyciągnąć z tego naukę, masz jakieś żale.
ken-wawa wrote: to ma być rozwiązanie na drugi rzut,
- to nie rozwiązanie, tylko sabotaż obarczony wysokim ryzykiem zniszczenia zawartości. W dodatku bez cienia nadziei, że w tym konkretnym przypadku w czymkolwiek może pomóc.
ken-wawa wrote: musi to robić osoba, która wie, co robi.
- taka osoba nigdy tego nie zrobi, bo jak ktoś wie, co robi, to też rozumie, jak pendrive działa i rozumie, dlaczego to nie jest rozwiązanie, tylko sabotaż. Wystarczy, że cokolwiek się nie zgodzi i możesz mieć po danych. Nawet nie będziesz wiedział, kiedy kontroler zainicjalizuje Ci pamięć ze skutkami, jak przy użyciu MP-Toola. A potem jest "ja już pendriva naprawiłem..." (w domyśle - zrobiłem za ciebie najważniejszą część roboty) "...a teraz tylko odzyskaj mi z niego dane". "nie dasz rady? - to ty głupi jesteś".
ken-wawa wrote: pendrive będzie widoczny dla specjalistycznego softu,
- zwróć uwagę, że pendrive jest widoczny i dla systemu operacyjnego. Kontroler odpowiada. Nie mamy informacji o odcięciu dostępu do pamięci, a jedynie o śmieceniu przy odczycie -> Twój pomysł ewidentnie nie ma sensu. Swoją drogą elektroniczne uszkodzenia kontrolera należą do rzadkości. Jako uszkodzenia kontrolera często opisywane są uszkodzenia oprogramowania układowego, bo klient - laik wie, co to jest kontroler i można mu go pokazać palcem, a co to jest oprogramowanie układowe na ogół już nie wie.. W dodatku oprogramowanie układowe w nośnikach danych (nie tylko półprzewodnikowych, ale i w dyskach twardych) składa się z dwóch części. Jedna jest w EEPROMie, druga w NANDzie (lub w przypadku dysków twardych na talerzu w strefie serwisowej). I najczęściej uszkodzeniu ulega ta druga część, czyli w przypadku pendriva - w pamięci. A więc w przypadku typowej usterki, przenosząc pamieć do innego nośnika, razem z nią przenosisz i problem, Nie zyskujesz niczego, prócz ryzyka zniszczenia zawartości.
Przy tym w tym konkretnym przypadku opis problemu daje wskazanie w kierunku problemu ze strukturami logicznymi/zaśmiecenia ich/błędów bitowych. Tu też przeniesienie pamięci gdziekolwiek, oznacza równoczesne przeniesienie problemu + ryzyko zniszczenia zawartości + ryzyko pogorszenia stanu związane z grzaniem układu podczas lutowania. -> Twoja propozycja, nawet, gdyby nie była obciążona ryzykiem, i tak byłaby bez sensu.
ken-wawa wrote: chyba lepiej przelutowywać pamięć
- dlaczego tak sądzisz? A może to lepiej pamięci oszczędzić grzania?
ken-wawa wrote: nowy dobry mikrokontroler poradzi sobie z przeniesioną pamięcią.
- tak, np. zainicjalizuje ją, wykasuje wszystkie bloki, sprawdzi, czy są sprawne, stworzy nową listę defektów i nowe tablice translacji. Czy muszę pisać, że przy okazji zniszczy dane? Dlatego jest to wyjątkowo szkodliwa porada i kretyński sabotaż, a nie rozwiązanie problemu.
Dlatego w przypadkach utraty danych pamięć odczytuje się na programatorze i składa się obraz struktury logicznej na podstawie binarki. Widziałeś może filmiki propagujące piekarnikowe naprawy laptopów? To mniej więcej ten sam poziom. Swoją drogą, gdyby koleś z pierwszego filmiku miał ciut więcej pomyślunku, to przyłapałby się do laminatu kablem USB i zgrał dane bez ryzyka i bez zbędnego grzania pamięci.
ken-wawa wrote: Jak dla mnie to podwójna antyreklama firmy.
- nie jestem tu po to, by się prezentować, jak kobyła na Pride of Poland, a jak komuś przeszkadza mój krytyczny stosunek do bezmyślnego powielania bzdur z internetu, nie musi do mnie przychodzić. Nie sądzę, bym od tego schudł.
_jta_ wrote: może być tak, że on ma mniej pamięci, niż zadeklarowano
- Chipgenius może dać na to odpowiedź, aczkolwiek stawiam, że NAND zdegradował i zaczął sypać błędami bitowymi w liczbie przekraczającej możliwości korekcji.
