On 11/05/2023 05:00, ptoki (ptoki) wrote:
>> Będę puszczał jeszcze jakieś testy w postaci dd if=/dev/urandom
>> of=temp.bin na wolną przestrzeń i zobaczymy, czy rośnie coś po stronie
>> smarta.
> zeby roslo musisz czytac.
> zeby spadalo trzeba zapisac.

W sensie, że zapis powoduje spadek ilosci badblocków ;)? Tej sztuczki
nie znałem ;)

do góry

On Thursday, May 11, 2023 at 3:50:57 a.m. UTC-5, heby wrote:
> On 11/05/2023 05:00, ptoki (ptoki) wrote:
> >> Będę puszczał jeszcze jakieś testy w postaci dd if=/dev/urandom
> >> of=temp.bin na wolną przestrzeń i zobaczymy, czy rośnie coś po stronie
> >> smarta.
> > zeby roslo musisz czytac.
> > zeby spadalo trzeba zapisac.
> W sensie, że zapis powoduje spadek ilosci badblocków ;)? Tej sztuczki
> nie znałem ;)
Tak

dziala to tak ze zdrowy sektor/blok/czy jak se to tam nazwiesz daje sie czytac bez
problemu.
Jak jakosc odczytu spada - kontroler sobie analizuje czy sygnal z glowicy jest czysty
czy "zaszumiony" albo brakuje w nim czytelnych bitow to inicjalnie podaje dane bez
ostrzezenia ale sobie zapamietuje dany blok jako niestabilny. Po przekroczeniu progu
akceptowalnosci jakosci odczytu zaznacza go do relokacji.
Nie znam dyskow co same relokuja sektory. Moze takie sa ale zazwyczaj taka degradacja
dla usera jest niewidoczna poza zajrzeniem w smarta. A i wtedy nie jest prosto dostac
liste tych sektorow i zamapowac na plik. Niby sie da bo gdzies tam ten sektor jest i
mozna narzedziamu sprawdzic ktory plik go okupuje ale to nieco dlubanina i zalezy od
systemu plikow, rozkladu partycji itp. Przy jakims LVM to wogole trudniej itp...

Normalnie taki stan z niestabilnym odczytem sie utrzymuje az albo plik przestanie
sie czytac - wtedy user sie wkurza albo jak user nadpisze ten sektor bo przekopiowal
plik albo go nadpisal czyms innym.

W takim momencie kontroler nie nadpisuje takiego oznaczonego sektora tylko zaznacza
go jako zrelokowany i zapisuje se go gdzies indziej, pamietajac gdzie on oryginalnie
byl.

Wiec jak chcesz przetestowac dyska to czytasz. Bo bez czytania smartowa liczba
sektorow do zrelokowania sie nie zmieni.
To powoduje ze obszary dysku ktory wygladal na zdrowy przed takim skanem sa czytane i
odkrywa sie ze jednak niektore sektory sa slabe. Niektorzy mysla ze ktos ich oszukal
bo wyzerowal smart-a a jak zrobili skan to sie pokazaly bledy i mysl sie pojawia ze
nie bylo ale sa to znaczy ze pewnie byly ale ktos wyzerowal.
Wiec podczas skanu kontroler znajdzie takie slabe ale ich nie zrelokuje.

Zeby liczba sektorow do zrelokowania spadla to trza je zrelokowac. Czyli zapisac
ponownie. I wtedy liczba tych bad sektorow jak niektorzy mowia spada ale podnosi sie
tych zrelokowanych.

I tu niektorzy narzekaja ze maja dysk z duza iloscia takich relokacji i znowu, ze
ktos im barachlo sprzedal. I to moze ale nie musi byc prawda.

Fabrycznie takie dyski sa puszczane raz czy dwa razy na skanowanie (to trwa dlugo
wiec czasem producent po prostu zaznacza zeby sie zrobilo juz u klienta i jak dysk
bedzie pasciak to sie mu wymieni na gwarancji) i wtedy jak klient sobie zacznie dane
zapisywac to sie od razu pewna ilosc sektorow zrelokuje.

Zeby ocenic czy dysk jest dobry trzeba sledzic ilosc pending for relocation
okazjonalnie skanujac cala powierzchnie i zrelokowac (tu jest trudniej) jak liczba
wzrosla.

W praktyce te liczby zmieniaja sie o niewiele. 10-50-100-1000 sektorow.

Jak chcesz dbac o dyska to pusc mu smart test full w tle albo raz na miesiac skan
calej powierzchni i sprawdz wynik smarta.
Wiecej dlubac imho nie ma sensu.

Jak masz backupy to starczy i nie trzeba wiele wiecej cudowac

do góry

On 11/05/2023 18:40, ptoki (ptoki) wrote:
>> W sensie, że zapis powoduje spadek ilosci badblocków ;)? Tej sztuczki
>> nie znałem ;)
> Tak
> dziala to tak ze zdrowy sektor/blok/czy jak se to tam nazwiesz daje sie czytac bez
problemu.
> Jak jakosc odczytu spada - kontroler sobie analizuje czy sygnal z glowicy jest
czysty czy "zaszumiony" albo brakuje w nim czytelnych bitow to inicjalnie podaje dane
bez ostrzezenia ale sobie zapamietuje dany blok jako niestabilny. Po przekroczeniu
progu akceptowalnosci jakosci odczytu zaznacza go do relokacji.

No wiec własnie po to patrzę w smarta - aby znaleźć *rosnącą* ilość
relokacji podczas zapisu dd.

do góry

On Thursday, May 11, 2023 at 12:25:10 p.m. UTC-5, heby wrote:
> On 11/05/2023 18:40, ptoki (ptoki) wrote:
> >> W sensie, że zapis powoduje spadek ilosci badblocków ;)? Tej sztuczki
> >> nie znałem ;)
> > Tak
> > dziala to tak ze zdrowy sektor/blok/czy jak se to tam nazwiesz daje sie czytac
bez problemu.
> > Jak jakosc odczytu spada - kontroler sobie analizuje czy sygnal z glowicy jest
czysty czy "zaszumiony" albo brakuje w nim czytelnych bitow to inicjalnie podaje dane
bez ostrzezenia ale sobie zapamietuje dany blok jako niestabilny. Po przekroczeniu
progu akceptowalnosci jakosci odczytu zaznacza go do relokacji.
> No wiec własnie po to patrzę w smarta - aby znaleźć *rosnącą* ilość
> relokacji podczas zapisu dd.

ah no to git.

do góry