sobota, 29 stycznia 2022 o 13:36:47 UTC-6 Roman Tyczka napisał(a):
> On 28.01.2022 00:32, ptoki wrote:
> >> 202 Percent_Lifetime_Remain 0x0030 093 093 001 Old_age
> >> Offline - 7
> > Nawet jak naprawisz to juz mu duzo zycia nie zostalo (7%)
> 7% zostało? Czyli 93% zużycia? To chore, dysk ma ze dwa lata, używany w
> lapku dzieciaka, głównie teamsy, yt i gry... zero jakiejś drastycznej
> orki typu bazy danych czy obróbka video, bieda straszna w takim razie z
> Crucialem.

Hehe, widzisz, dzis baza duzo mniej orze dyskiem niz np, glupia przegladarka.
Starczy ze to dziecko na discordzie siedzi i se grupka durne animacje pokazuje w
ilosciach rozrywkowych. Przegladarka niezle poorze dyska wrzucajac te smieci w cache.
Podobnie obrobka wideo. Przerobic film 1GB to z grubsza drugie 2GB zapisow, czesto
mniej.

Zapusc sobie w windowsie perfmona i zajrzyj ile tam zapisow leci na dysk. Zdziwisz
sie ze na serwerach jest tego czesto mniej.

> >> 246 Total_LBAs_Written 0x0032 100 100 000 Old_age Always
> >> - 27158810210
> > Nie wiem czy dobrze licze i mi sie przecinki nie pomotaly ale to jest 12,5TB
> > Nie jest to duzo jak na dysk pol TB ale nie jest tez malo.
> To jest wyrażone w czym? Bajtach? Blokach po 512B?

W TB pisze przeciez. Kawy wincyj :)

> > Ponizsze sugestie zniszcza ci wszystkie dane na tym dysku.
> > Jak sie da to pusc dd z tego dysku na inny czyli zrob sobie jego obraz. Ale jak
jest jak piszesz to nie odzyskasz nic sensownego. To inny aspekt tej awarii.
> >
> > Ponizsze zaklada ze nie zalezy ci na danych z tego dysku:
> >
> > Mozesz sprobowac zrobic dd na ten dysk w pierwsze 100-200MB.
> > To ci wyczysci tablice partycji i ewentualnie zrealokuje zuzyte sektory.
> > Potem sprobuj puscic to co tu kiedys bylo wspominane (trim na caly dysk) w watku
Odswiezenie ssd
> Zapuściłem dd, potem blkdiscard -z, potem z linka:
>
> i=0; while [ $i -lt 937703088 ]; do echo $i:40000; i=$(((i+40000)));
> done | hdparm --please-destroy-my-drive --trim-sector-ranges-stdin /dev/sde
>
> i to ostatnie wywaliło się po jakimś czasie:
>
> [...]
> trimming 20480000 sectors from 512 ranges
> succeeded
> trimming 16120000 sectors from 403 ranges
> SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 04 51 40
> 00 21 04 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> succeeded
>
> Coś jeszcze się da zrobić?
>
>

Sprawdzic czy pomoglo. :)

Ale tak jak ansaj nizej pisze, dziwne te numerki tam sa.

Sprawdz ponownie smarta. Moze ten 202 sie poprawil bo firmware ma wiecej pola do
popisu na wear leveling.

No i na koniec, jak ten dysk pracowal w systemie ktory trima nie obsluguje (jakas
stara ta winda?) to rzeczywiscie po tak krotkim czasie mogl pasc, bo gnebiony byl...