On 2022-11-10, ptoki (ptoki) <s...@g...com> wrote:
> 2. Musisz wiedziec ze kontroler sledzi caly dysk i liczy sobie jak
> mocno uzyte sa poszczegolne bloki komorek.

Wierzę, a nawet wiem.

> 3. Uzycie tych blokow jest zazwyczaj bardzo nierownomierne.

W to też wierzę, a czego mi brakuje to zrozumienia dlaczego nieużywany
obszar dysku dostał zdechłych bloków. Kontroler rozlokował sobie te
zajechane na słąbo używany obszar (skoro nie teoria wielobitowości)?

> 4. Sa sposoby aby dac mu troche zycia.

To bardziej żeby się nauczyć, bo wymienić i tak raczej trzeba.

>> mieć to coś wspólnego z faktem, że pojedyncza komórka mieści tu, zdaje
>> się 2 bity i może jak jedna warstwa pójdzie się paść to ta druga, nawet
>> nie używana, również. Ale tak se spekuluje bo się nie znam.
>>
>> Dla porządku zwracam też uwagę, że ten dysk ma gwarancje na 150TWB a smart
>> pokazuje, że zaliczył 3500TWB.
>>
> 5. Nie jestem pewien czy dobrze policzyles ale to detal.

Wydaje się, że dobrze. Potwierdzone również eksperymentalnie.

> 6 - najistotniejsze dla ciebie: Dla przykladu. Masz dyska z 100
> komorkami. Kazda ma 10 zapisow zywotnosci. Czyli tak jakby
> 100*10=1000 zapisow. I teraz dwa warianty: 1. Zapisujesz caly dysk
> raz i tracisz 10% jego zywotnosci - 100zapisow. Kasujesz wszystko,
> dajesz dyskowi znac zeby wykonal trim, on sie orientuje ze nadal ma 9
> zapisow na kazdej komorce. Zapisujesz ponownie caly i masz 20%
> zuzycia. W ten sposob uzyskasz 1000 zapisow i dysk padnie* 2.
> Zapisujesz caly dysk w 70%. Zuzyles 7% jego trwalosci. Ale teraz
> piszesz ciagle te 30% pojemnosci i po 300 zapisach dysk zdycha.
> Dlaczego? Bo zapisywales te same przestrzenie wiele razy I mimo ze
> TBW jest/moze byc nieduze to kazda komorka z tych 30% zostanie
> zapisana wielokrotnie wiecej.

To jakby rozumiem, ale to nie wyjaśnia dlaczego nietykane 70% ma błędy.

> W twoim scenariuszu te 30% niespartycjonowane bylo uzywane przez dysk
> do rozpraszania zapisow. I w praktyce yo co zapisywales na tych 70%
> trafialo na te pozostale 30% bo dysk wiedzial ze sa nie uzyte.
> Wiedzial o tym bo ich nie zapisal wczesniej a nie dlatego ze tam nie
> bylo partycji.

Dobrze, to teraz jeszcze takie coś. Podmontowałem tą nieużywaną
partycję i zapuściłem ręcznie fstrima. Ztrimował 165GB/175GB
dostępnych. Zapuściłem ponownie badblock i liczba bb spadła z 5140 na
770. O ile dobrze rozumiem to fstrim nie zdąrzył się dorwać do tej
partycji jak jeszcze przed laty była zamontowana, czyli de facto
kontroler myślał, że są to zajęte bloki, czyli pewnie było grubo
poniżej 10% wolnych. W takim razie tym dziwniejsze, że on jeszcze żyje
i w sumie cały czas bryka. Zapisałem 1-7GB na sda2 i sda1 i prędkości
powyżej 250MB/s.

Na partycji systemowaj ztrimowało się ręcznue ok 1.5GB/55GB. Tu wygląda
trim chodził. Błedy zleciały z 91 na 85.

Teraz wziąłem tę od swapa, sformatowałem jak ext4, podmontowałem i
fstrimowałem. Ztrimował jak można się spodziewać wszystko, ale
najciekawsze jest, że błędy spadły z ok 2000 na 0. Jak to wyjaśnić
biorąc pod uwagę, że ta duża nieużywana była trimowana jako pierwsza?

Poniżej smart po (góra) i przed (dół) trimowaniem. Widać zmianę w "5" i
"187". Widać też, że "5"<-"179". Jak dużo taki dysk ma bloków
rezerwowych?

(po)
5 Reallocated_Sector_Ct 0x0033 038 038 010 : 440
9 Power_On_Hours 0x0032 094 094 000 : 27262
12 Power_Cycle_Count 0x0032 099 099 000 : 27
177 Wear_Leveling_Count 0x0013 001 001 000 : 2038
179 Used_Rsvd_Blk_Cnt_Tot 0x0013 038 038 010 : 440
181 Program_Fail_Cnt_Total 0x0032 100 100 010 : 0
182 Erase_Fail_Count_Total 0x0032 100 100 010 : 0
183 Runtime_Bad_Block 0x0013 038 038 010 : 440
187 Uncorrectable_Error_Cnt 0x0032 097 097 000 : 28095
190 Airflow_Temperature_Cel 0x0032 045 027 000 : 55
195 ECC_Error_Rate 0x001a 001 001 000 : 28095
199 CRC_Error_Count 0x003e 100 100 000 : 0
235 POR_Recovery_Count 0x0012 099 099 000 : 20
241 Total_LBAs_Written 0x0032 097 097 000 : 6830206817482

(przed)
5 Reallocated_Sector_Ct 0x0033 081 081 010 : 135
9 Power_On_Hours 0x0032 094 094 000 : 27240
12 Power_Cycle_Count 0x0032 099 099 000 : 27
177 Wear_Leveling_Count 0x0013 001 001 000 : 2038
179 Used_Rsvd_Blk_Cnt_Tot 0x0013 081 081 010 : 135
181 Program_Fail_Cnt_Total 0x0032 100 100 010 : 0
182 Erase_Fail_Count_Total 0x0032 100 100 010 : 0
183 Runtime_Bad_Block 0x0013 081 081 010 : 135
187 Uncorrectable_Error_Cnt 0x0032 099 099 000 : 1796
190 Airflow_Temperature_Cel 0x0032 044 027 000 : 56
195 ECC_Error_Rate 0x001a 199 199 000 : 1796
199 CRC_Error_Count 0x003e 100 100 000 : 0
235 POR_Recovery_Count 0x0012 099 099 000 : 20
241 Total_LBAs_Written 0x0032 097 097 000 : 6830178404602

> ad4. Jak skasujesz wszystko z dysku to mozesz miec szczescie i
> jeszcze nieco danych zapiszesz zanim padnie. Kontroler moze zaczac
> chetniej uzywac komorki mniej zuzyte (zakladamy ze te 30% teraz jest
> mocno zuzyte a te 70% tylko czesciowo i powiedzmy 50% tych 70% jest
> zapisane tylko pare razy) wiec jakbys zmniejszyl te partycje do
> powiedzmy (z dupy estymacja) do 100GB to ten dysk nadal podziala. Ale
> trzeba zrobic pelnego trim-a. Ja tak robi pod linuksem. Wysyla sie
> dyskowi info zeby trimowal wszystkie bloki i on ma szanse zaczac
> uzywac te co sa najmniej zuzyte.
>
> Ale feler jest taki ze jak przekroczysz bariere (ilosciowa) za ktora
> sa zuzyte bloki i je zaczniesz ponownie nadpisywac (jakies logi czy
> baza danych) to dysk padnie na twardo.
>
> To tak zgrubsza. Mysle ze nieco wyjasnia sytuacje.

Do końca nadal nie chwytam tych błędów na nieużywanej partycji, tym
bardziej jeśli kontroler myślał, że jest zajęta. Ale może to tak, że te
kilka GB co myślał, że ma tam wolne to używał dużo intensywniej i
dlatego też poleciały, i tam właśnie są te błędy. Trzyma się kupy?

Druga rzecz to ten kosmiczny przebieg. Coś najwyraźniej jednak tam
musiało tyle pisać. Adam poprawnie zgadł, że to serwer, więc może tak
wygląda rzeźbienie różnych typowych procesów po ssd? Nb. to już drugi
ssd w tej maszynie. Poprzedni, jakiś Lexar, padł po chyba 2ch latach i
OIDP padł trupem niediagnostycznym, więc nie mam jak sprawdzić
przebiegu.

--
Marcin