Paweł Pawłowicz <pawel.pawlowicz13@gmailDOTcom> writes:

> Zwróć uwagę na fakt, że format jpg zmieniał się w czasie. Jeśli masz
> ponad dwudziestoletnie pliki, to mogą one być niezgodne z Twoim
> programem.

Jest to nieprawdopodobne.
--
Krzysztof Hałasa

do góry

Marcin Debowski <a...@I...zoho.com> writes:

> Co więcej, znalazłem również
> zdjęcia wolne od uszkodzeń, które w archiwum mają uszkodzenia. Więc to
> też nie karty.

O, super - łatwo więc je porównać.
--
Krzysztof Hałasa

do góry

On 2021-06-12, Krzysztof Halasa <k...@p...waw.pl> wrote:
> Marcin Debowski <a...@I...zoho.com> writes:
>
>> W sumie o tym nie pomyślałem, a to dobry pomysł, choć trwałość podaje się
>> rzędu 10 lat. Wciąż lepsze to niż mechniczny dysk twardy, szczególnie, że
>> to dodatkowa kopia.
>
> To raczej nie jest lepsze niż mechaniczny dysk twardy, ani nawet SSD,
> aczkolwiek oczywiście każda dodatkowa kopia jest plusem.

Ciekawe jak wygląda z kartami większej gęstości, bo prawdę mówiąc jestem
pozytywnie zaskoczony, że te prawie 20letnie karty są nadal bezproblemowo
czytane. Jedna tylko wywaliła błędy i/o.

> Dobrze byłoby przyjrzeć się tym uszkodzonym plikom - nie w sensie
> ratowania ich, ale w sensie zbadania typu błędu. Czy to np. jest cały
> zepsuty sektor (jakiej wielkości?), czy jakieś pojedyncze błędy bitowe,
> bajtowe, albo jeszcze inne - często można z tego sporo wywnioskować.
> Z tym że oczywiście najłatwiej znaleźć błędy przez porównanie z "dobrą"
> kopią, tu to nie zadziała.

$cmp -bl EOS40D_01772.jpg EOS40D_01772-CF.jpg
1687370 256 M-. 356 M-n

Nie mogłem ogarnąć jak to interpretować skoro to jeden bajt a tu mi jakby
wyświetla min 2, ale wziąłem edytor hex i różniaca jest A vs E, czyli
1010 vs 1110.

> Dobrym rozwiązaniem jest przechowywanie istotnych dokumentów w kilku
> kopiach, z okresowym sprawdzaniem sum kontrolnych (haszy typu MD5 albo
> lepiej SHA256+ jeśli ktoś chce tam trzymać dowolne pliki - np. znane
> kolizje słabszych haszy). Wtedy mamy "wczesne ostrzeganie", zwykle
> wskazujące na problemy ze sprzętem.

No już to mam, nawet z redundacją geograficzną, ale w kwestii tego typu
błędów mądry zacząłem być dopiero parę lat temu.

--
Marcin

do góry

Marcin Debowski <a...@I...zoho.com> writes:

> $cmp -bl EOS40D_01772.jpg EOS40D_01772-CF.jpg
> 1687370 256 M-. 356 M-n
>
> Nie mogłem ogarnąć jak to interpretować skoro to jeden bajt a tu mi jakby
> wyświetla min 2, ale wziąłem edytor hex i różniaca jest A vs E, czyli
> 1010 vs 1110.

To jest "meta-." i "meta-n":
https://en.wikipedia.org/wiki/Meta_key

0xAE vs 0xEE, czyli różnica na 6 bicie. Tylko jeden błąd w pliku? Przy
takiej gęstości błędów pliki można odzyskać, wystarczy "wypróbować" je
po zmianie każdego potencjalnie zepsutego bitu. JPEGi składają się
z małych makrobloków (MCU - max 16x16), można nawet wzrokowo sprawdzać
efekt zmiany bitu.

Dodatkowo sprawdziłbym (np. na innych plikach, w miarę możliwości), czy
zmiana wartości jest tylko w jednym kierunku (np. 1 -> 0, nigdy
odwrotnie) - to zmniejsza liczbę potencjalnie zepsutych bitów o połowę.

Oczywiście wszystko pod warunkiem, że tych błędów nie będzie (znacznie)
więcej, albo że nie będą innego typu (np. całe skasowane sektory).

Takie pojedyncze bit-flipy wskazują na problemy z pamięcią RAM
(np. w NAS lub PC), ew. na jakieś marginalny projekt jakiejś części
urządzenia (elementy pracujące na granicy np. czasów dostępu,
częstotliwości itp). Może to być także jakiś overclocking.

Teoretycznie takie błędy mogą być wynikiem uderzeń cząstek alfa
(w pamięciach DRAM przez parzystości/ECC). Aczkolwiek nigdy takiego
przypadku nie wykryłem, mimo nie wiadomo ilu TB danych (np. skopiowanych
i sprawdzonych).
--
Krzysztof Hałasa

do góry

On 2021-06-14, Krzysztof Halasa <k...@p...waw.pl> wrote:
> Marcin Debowski <a...@I...zoho.com> writes:
>
>> $cmp -bl EOS40D_01772.jpg EOS40D_01772-CF.jpg
>> 1687370 256 M-. 356 M-n
>>
>> Nie mogłem ogarnąć jak to interpretować skoro to jeden bajt a tu mi jakby
>> wyświetla min 2, ale wziąłem edytor hex i różniaca jest A vs E, czyli
>> 1010 vs 1110.
>
> To jest "meta-." i "meta-n":
> https://en.wikipedia.org/wiki/Meta_key

Ale po co tak i co to robi pod Linuxem?

> 0xAE vs 0xEE, czyli różnica na 6 bicie. Tylko jeden błąd w pliku? Przy

Tak.

> takiej gęstości błędów pliki można odzyskać, wystarczy "wypróbować" je
> po zmianie każdego potencjalnie zepsutego bitu. JPEGi składają się
> z małych makrobloków (MCU - max 16x16), można nawet wzrokowo sprawdzać
> efekt zmiany bitu.

Tylko żeby wiedzieć gdzie jest ten bit to muszę mieć nieuszkodzony wzorzec,
a jak go mam to nie potrzebuję modyfikować.

> Dodatkowo sprawdziłbym (np. na innych plikach, w miarę możliwości), czy
> zmiana wartości jest tylko w jednym kierunku (np. 1 -> 0, nigdy
> odwrotnie) - to zmniejsza liczbę potencjalnie zepsutych bitów o połowę.

Popatrzę jeszcze.

> Takie pojedyncze bit-flipy wskazują na problemy z pamięcią RAM
> (np. w NAS lub PC), ew. na jakieś marginalny projekt jakiejś części
> urządzenia (elementy pracujące na granicy np. czasów dostępu,
> częstotliwości itp). Może to być także jakiś overclocking.

To wszystko dziwnie wygląda bo te błędy są tylko w zdjęciach z niektórych
aparatów, a w innych z tego samego okresu już nie. Zwykle archiwum
kopiowałem w całości, więc albo jakiś zbieg okoliczności, albo to jeszcze
coś innego.

> Teoretycznie takie błędy mogą być wynikiem uderzeń cząstek alfa
> (w pamięciach DRAM przez parzystości/ECC). Aczkolwiek nigdy takiego
> przypadku nie wykryłem, mimo nie wiadomo ilu TB danych (np. skopiowanych
> i sprawdzonych).

Na pewno alfa? Alfa ma bardzo słabą przenikalność.

--
Marcin

do góry

Marcin Debowski <a...@I...zoho.com> writes:

>> To jest "meta-." i "meta-n":
>> https://en.wikipedia.org/wiki/Meta_key
>
> Ale po co tak i co to robi pod Linuxem?

Tak zostało od niepamiętnych czasów, Linuksa jeszcze nie było nawet
w planach.

>> takiej gęstości błędów pliki można odzyskać, wystarczy "wypróbować" je
>> po zmianie każdego potencjalnie zepsutego bitu. JPEGi składają się
>> z małych makrobloków (MCU - max 16x16), można nawet wzrokowo sprawdzać
>> efekt zmiany bitu.
>
> Tylko żeby wiedzieć gdzie jest ten bit to muszę mieć nieuszkodzony wzorzec,
> a jak go mam to nie potrzebuję modyfikować.

Nie, wystarczy zmieniać każdy bit (np. w uszkodzonym makrobloku)
i sprawdzać, czy się poprawiło. Przy 1 bicie/plik to jest prosta sprawa.

> To wszystko dziwnie wygląda bo te błędy są tylko w zdjęciach z niektórych
> aparatów, a w innych z tego samego okresu już nie. Zwykle archiwum
> kopiowałem w całości, więc albo jakiś zbieg okoliczności, albo to jeszcze
> coś innego.

Potrzebne śledztwo :-)

>> Teoretycznie takie błędy mogą być wynikiem uderzeń cząstek alfa
>> (w pamięciach DRAM przez parzystości/ECC). Aczkolwiek nigdy takiego
>> przypadku nie wykryłem, mimo nie wiadomo ilu TB danych (np. skopiowanych
>> i sprawdzonych).
>
> Na pewno alfa? Alfa ma bardzo słabą przenikalność.

Tak twierdzą: np. https://ieeexplore.ieee.org/document/510798
Soft errors induced by alpha particles can be a reliability concern for
microelectronics, especially semiconductor memory devices packaged in
ceramic. In dynamic random-access memory devices (DRAM), the data are
stored as the presence or absence of minority carrier charges on storage
capacitors.

Kiedyś pamięci miały parzystość (system wysypywał się z NMI po takiej
lub podobnej akcji), później było ECC (błędy były korygowane),
a jeszcze później w typowym sprzęcie usunięto wszelką nadmiarowość - od
tamtego czasu nigdy nie spotkałem się z takimi problemami. Może kwestia
"packaged in ceramic"? Ceramika też może być źródłem cząstek ?.
--
Krzysztof Hałasa

do góry

On 2021-06-17, Krzysztof Halasa <k...@p...waw.pl> wrote:
> Marcin Debowski <a...@I...zoho.com> writes:
>>
>> Tylko żeby wiedzieć gdzie jest ten bit to muszę mieć nieuszkodzony wzorzec,
>> a jak go mam to nie potrzebuję modyfikować.
>
> Nie, wystarczy zmieniać każdy bit (np. w uszkodzonym makrobloku)
> i sprawdzać, czy się poprawiło. Przy 1 bicie/plik to jest prosta sprawa.

Nie rozumiem. Zmieniony jest gdzieś jeden bit a my nie znamy nawet jego
lokalizacji, to skąd wiadomo, który to makroblok? Jeśli byłoby jakieś
narzędzie pozwalające na wizualną korelacje konkretnego piksela z pozycją
w pliku, to owszem, ale są takie narzędzia?

>> To wszystko dziwnie wygląda bo te błędy są tylko w zdjęciach z niektórych
>> aparatów, a w innych z tego samego okresu już nie. Zwykle archiwum
>> kopiowałem w całości, więc albo jakiś zbieg okoliczności, albo to jeszcze
>> coś innego.
>
> Potrzebne śledztwo :-)

Nie mam dostępnych zasobów ludzkich :(

>>> Teoretycznie takie błędy mogą być wynikiem uderzeń cząstek alfa
>>> (w pamięciach DRAM przez parzystości/ECC). Aczkolwiek nigdy takiego
>>> przypadku nie wykryłem, mimo nie wiadomo ilu TB danych (np. skopiowanych
>>> i sprawdzonych).
>>
>> Na pewno alfa? Alfa ma bardzo słabą przenikalność.
>
> Tak twierdzą: np. https://ieeexplore.ieee.org/document/510798
> Soft errors induced by alpha particles can be a reliability concern for
> microelectronics, especially semiconductor memory devices packaged in
> ceramic. In dynamic random-access memory devices (DRAM), the data are
> stored as the presence or absence of minority carrier charges on storage
> capacitors.

Ciekawe.

> Kiedyś pamięci miały parzystość (system wysypywał się z NMI po takiej
> lub podobnej akcji), później było ECC (błędy były korygowane),
> a jeszcze później w typowym sprzęcie usunięto wszelką nadmiarowość - od
> tamtego czasu nigdy nie spotkałem się z takimi problemami. Może kwestia
> "packaged in ceramic"? Ceramika też może być źródłem cząstek ?.

Tak, zdecydowanie.

"Alpha particles emitted from trace levels of uranium and thorium in the
packaging materials can penetrate the surface of the semiconductor die."

W takim trybie to wierzę bo tor i parę innych radioaktywnych pierwiastków
spotyka się w materiałach do produkcji ceramiki.
Ale to jest art. z AD 1996, a w tej chwili to raczej nie pakuje się takich
pamięci w ceramikę, a prędzej np. w epoksydy.

Z trzeciej strony, to się mogło uszkodzić koło 2003 :)

--
Marcin

do góry

Dnia Fri, 11 Jun 2021 08:07:21 GMT, Marcin Debowski napisał(a):
> Robię właśnie większy porządek na NAS'ie gdzie trzymam bieżącą kopię m.in.
> archium zdjęć. To archiwum jest trzymane na dyskach od jakiś 20 lat,
> oczywiście nie wszystkie zdjęcia z tego samego okresu, ale taki z grubsza
> zakres czasowy. Archiwum było od czasu do czasu przemieszczane na nowe
> dyski, czy nowy NAS, słowem normalna ekspolatacja czy migracja zasobów.
>
> No więc jest tak: z grubsza 1% zdjęć jest uszkodzonych. Manifestuje się to
> w ten spob, że zdjęcie do pewnego momentu jest ok, a potem zmienia się
> zwykle np. jasność i zwykle też barwa.
>
> https://betanews.com/wp-content/uploads/2015/03/corr
upt-jpeg.jpg

I zauwaz, ze przesuniecie nastapilo.

Jest to charakterystyczne dla kodowania o zmiennej dlugosci slowa,
wystepujacej w JPG - wystarczy jeden bit zmienic, aby dlugosc
odtworzonego fragmentu sie zmienila, i nastapilo takie przestawienie.

Ale widze, ze musze cos doczytac o kodowaniu JPG, bo tej zmiany koloru
i jasnosci nie bardzo rozumiem.

Tak czy inaczej - moze to byc przeklamany jeden bit, a moze byc np
wyzerowany caly sektor, bo z tego zdjecia to trudno ustalic.

Twarde dyski maja sumy kontrolne, beda probowaly wielokrotnie odczytac
sektor az moze sie kiedys uda.
Mialem kiedys uszkodzony HDD, odczyt niektorych sektorow trwal
sekundy, ale takich naprawde nieodczytywalnych bylo bardzo malo,
a bledow w tych, co sie odczytaly, to chyba nie bylo.

Ale skoro to NAS, to przyczyn moze byc wiecej - przeklamania w
transmisji sieciowej, czy np miedzy karta/chipem ethernet a pamiecia,
czy miedzy pamiecia a dyskiem. Bo zakladam, ze to juz przez procesor
nie przechodzi, ma jakies DMA.

Dobrze byloby ustalic, jakiego rodzaju sa roznice - pojedyncze bity,
czy cale sektory 512 bajtow. I czy to przypadkowe bledy przy odczycie,
czy blednie zapisane dane, ewentualnie - pozniej zmienione.

Tylko ... czy mi sie wydaje, czy ona mialaby tu dwa nosy?
Bo w gornej czesci jakby widac podstawe lewej czesci, a prawa w dolnej
czesci zdecydowanie nizej.
Cos sie zgubilo, czy wrecz odwrotnie - cos sie zduplikowalo?

J.

do góry

Dnia Sun, 13 Jun 2021 01:44:45 GMT, Marcin Debowski napisał(a):
> On 2021-06-12, Krzysztof Halasa <k...@p...waw.pl> wrote:
> $cmp -bl EOS40D_01772.jpg EOS40D_01772-CF.jpg
> 1687370 256 M-. 356 M-n
>
> Nie mogłem ogarnąć jak to interpretować skoro to jeden bajt a tu mi jakby
> wyświetla min 2, ale wziąłem edytor hex i różniaca jest A vs E, czyli
> 1010 vs 1110.

To chyba nawet tu napisane - 256/356 ... osemkowo.

J.

do góry

Dnia Thu, 17 Jun 2021 16:00:21 +0200, Krzysztof Halasa napisał(a):
> Marcin Debowski <a...@I...zoho.com> writes:
>>> takiej gęstości błędów pliki można odzyskać, wystarczy "wypróbować" je
>>> po zmianie każdego potencjalnie zepsutego bitu. JPEGi składają się
>>> z małych makrobloków (MCU - max 16x16), można nawet wzrokowo sprawdzać
>>> efekt zmiany bitu.
>>
>> Tylko żeby wiedzieć gdzie jest ten bit to muszę mieć nieuszkodzony wzorzec,
>> a jak go mam to nie potrzebuję modyfikować.
>
> Nie, wystarczy zmieniać każdy bit (np. w uszkodzonym makrobloku)
> i sprawdzać, czy się poprawiło. Przy 1 bicie/plik to jest prosta sprawa.

Owszem, ale nie bardzo wiadomo, gdzie ten bit.
Bitow w zdjeciu duzo, a kontrola tylko naoczna - uciazliwe bedzie.

>> To wszystko dziwnie wygląda bo te błędy są tylko w zdjęciach z niektórych
>> aparatów, a w innych z tego samego okresu już nie. Zwykle archiwum
>> kopiowałem w całości, więc albo jakiś zbieg okoliczności, albo to jeszcze
>> coś innego.
>
> Potrzebne śledztwo :-)

A patrzyles na archiwum po skopiowaniu z aparatu?
Pewnie tak ... ale moze jednak nie ?

J.

do góry