Wcale nie przypadkiem, dnia Fri, 11 Nov 2022 01:01:11 GMT
doszła do mnie wiadomość <r9hbL.2369207$%q2.1730743@fx15.ams1>
od Marcin Debowski <a...@I...zoho.com> :
>On 2022-11-10, Szwambuł Trantiputl <t...@d...com> wrote:
>> Wcale nie przypadkiem, dnia Thu, 10 Nov 2022 06:59:39 GMT
>> doszła do mnie wiadomość <vj1bL.852273$qD%2.456333@fx08.ams1>
>> od Marcin Debowski <a...@I...zoho.com> :
>>>Mam taki oto dysk:
>>>Model Family: Samsung based SSDs
>>>Device Model: Samsung SSD 860 EVO mSATA 250GB
>>
>>>
>>>Vendor Specific SMART Attributes with Thresholds:
>>>ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED
WHEN_FAILED RAW_VALUE
>>> 5 Reallocated_Sector_Ct 0x0033 058 058 010 Pre-fail Always -
295
>>> 9 Power_On_Hours 0x0032 094 094 000 Old_age Always -
27242
>>> 12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always -
27
>>>177 Wear_Leveling_Count 0x0013 001 001 000 Pre-fail Always -
2038
>>>179 Used_Rsvd_Blk_Cnt_Tot 0x0013 058 058 010 Pre-fail Always -
295
>>>181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always -
0
>>>182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always -
0
>>>183 Runtime_Bad_Block 0x0013 058 058 010 Pre-fail Always -
295
>>>187 Uncorrectable_Error_Cnt 0x0032 099 099 000 Old_age Always -
5310
>>>190 Airflow_Temperature_Cel 0x0032 035 027 000 Old_age Always -
65
>>>195 ECC_Error_Rate 0x001a 199 199 000 Old_age Always -
5310
>>>199 CRC_Error_Count 0x003e 100 100 000 Old_age Always -
0
>>>235 POR_Recovery_Count 0x0012 099 099 000 Old_age Always -
20
>>>241 Total_LBAs_Written 0x0032 097 097 000 Old_age Always -
6830194150602
>>
>> Przepraszam za niedyskretne pytanie, w czym ten dysk siedział?
>> Z atrybutu 241 wychodzi, że zapisów ogółem było 3180.56 TB, co daje
>> 2869 GB dziennie.
>
>No dziwne, zgadzam się, ale robiłem testy przyrostowe i 1GB zapisu
>faktycznie dodaje ca 1GB do "241" (to są 512 bajtowe bloki). To to
>siedzi w domowym serwerku pod debianem. Poczta, sql, www głownie. Mały
>ruch, małe obciążenie. Początkowo myślałem, że ten swap tyle nawrzucał
>(fizycznej 4GB, swap, partycja, tyle samo), ale zaczynam trochę wątpić.
>
>W tej chwili jak patrzę na przyrosty to są w granicach 0.5-2MB/min.
>Kiedyś tam jeszcze chodził openvpn, ale nie wiem czymu miałby akurat on
>tak nabić. Chodził też emby, ale biblioteka była na innym dysku.

Jak na domowy serwer, to gigantyczne wartości, nurtuje mnie to, może
to błąd firmware dysku(jakieś kosmicznie wielkie write amplification
lub błędne dane), może jakiś proces w Linuksie cyklicznie powodował
wypełnianie i zwalnianie swapa czy sranie do katalogów tymczasowych,
coś to musiało być, może stare logi się zachowały i są w stanie coś
powiedzieć?
To musiało być średnio 33 MB/s zapisu na dysk.

>Dzięki tez za pozostałe uwagi.

Już wiem, co to za chipy flash:
https://www.techpowerup.com/ssd-specs/samsung-860-ev
o-250-gb.d6
Teraz wystarczy jakoś poszukać specyfikacji z podanym TBW dla tych
chipów, może jeszcze jest szansa, że jednak mają zapas, czyli po
secure erase dysk jeszcze popracuje.
--
Pójdziesz Pleśniowy
Legniesz Ciekliwy
Nakarmisz osty
Najesz pokrzywy
Stanisław Grochowiak.

do góry

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

do góry

Wcale nie przypadkiem, dnia Fri, 11 Nov 2022 03:33:59 GMT
doszła do mnie wiadomość <HojbL.1572752$%fx6.1407141@fx14.ams1>
od Marcin Debowski <a...@I...zoho.com> :
>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)?

Tu trzeba by wniknąć trochę głębiej w mechanizm działania FTL(flash
translation layer, punkt 4):
https://codecapsule.com/2014/02/12/coding-for-ssds-p
art-3-pages-blocks-and-the-flash-translation-layer/
Może tablice FTL są popsute (secure erase je najprawdopodobniej
wyzeruje), może poprostu firmware trafił na coś, z czym nie daje sobie
rady(reflash firmware na nowszy nie zaszkodzi).
--
Pójdziesz Pleśniowy
Legniesz Ciekliwy
Nakarmisz osty
Najesz pokrzywy
Stanisław Grochowiak.

do góry

czwartek, 10 listopada 2022 o 21:34:02 UTC-6 Marcin Debowski napisał(a):
> On 2022-11-10, ptoki (ptoki) <s...@g...com> wrote:

> > 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.
fstrim dziala dziwnie. Kiedys pisalem se z autorem i jego tlumaczenie co i jak bylo
tak metne ze odpuscilem konwersacje.

Mialem wtedy do niego pytanie jakim cudem fstrim puszczony raz zwalnia 56GB, puszony
natychmiast drugi raz zwalnia 0 bajtow, kolejne puszczenie i znowu 0 bajtow i na
kolejnym zwolnione 0.8GB podczas gdy iostat pokaywal ledwo 20MB zapisane.

Nie dowiedzialem sie dlaczego tak jest i mam silne przeczucie ze fstrim odpierdala
jakas maniane.
Dodatkowo ten dysk byl ztrymowany a jego wydajnosc byla pod psem.

I dodatkowo, nie jestem pewien czy podczas formatowania filesystemu na wejsciu fstrim
jest puszczany zeby "zainicjalizowac" wolna przestrzen. Bo kontroler pamieta co tam
na dysku bylo wczesniej a filesystem zalozony pod np. linuxem albo windowsem nie
martwi sie tym ze wczesniej tam cos bylo zapisane i nie wiem czy to jest zwalniane.
Obstawiam ze nie poniewaz:

Mialem dyska na ktorym fstrim chodzil caly czas i po paru latach wydajnosc jego
spadla do jakichs smiesznych wartosci na poziomie 50MB/sek.
Pokasowalem wszystko z niego, puscilem fstrima i wydajnosc byla nadal do dupy.
Testowalem zwyklym gnomowym disks-em. Tam ladnie widac jaka czesc dysku ma jaka
wydajnosc.

No i stwierdzilem jak gary oldman w 5elemencie: trza samemu zeby dobrze bylo i
puscilem ten baszowy skrypt z dolu tego posta
https://superuser.com/questions/308251/how-to-trim-d
iscard-a-whole-ssd-partition-on-linux
Albo podobny.
Puscilem to na dysku, skonczylo sie w pare chwil.
A potem puszczalem benchmarka z disks i na bierzaco widzialem jak sie wydajnosc
podnosi na tych obszarach gdzie jest konkretnie trim robiony.
Literalnie widzialem jak wydajnosc skacze z tych 50-60MB/sek do 250 podczas paru rund
benchmarkowania.

To tyle na temat fstrima. Niby jest, niby cos robi ale IMHO nie robi tego dobrze albo
nawet jakby robil dobrze to sa sytuacje gdzie moze sie pomotac (formatowanie juz
uzytego dysku).

> 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.
>

Tak, to dosyc podobny scenariusz jaki mi sie w glowie poukladal.
Jak mozesz to pusc se blkdiscardy albo te hdparmy i zobacz jaka ma wydajnosc
odczytow. Jak ma bardzo nierowna to znaczy ze trim pokpil temat. Jak caly ma rowno
szybkie odczyty to nie jest zle (ale nie wiem czy dobrze jest)

> 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?
>

Obstawiam ze ten fstrim jest po prostu dziurawy albo byly sytuacje ze dane byly
kasowane ale trim na nich nie byl wykonany. Nie wiem, pad zasilania, inny komp
kasowal a inny trimowal, nie wiem.
Ale mysle ze tam gdzie ci zostaly bad blocki trim nie byl zrobiony.

> 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?
>

Az mu zabraknie :) Nie mam pojecia ile. Ale kiedys czytalem ze do ssd dawali nawet
+20% (kostki flasz o tyle wieksze od tego co dysk pokazywal.
Dzis bym zakladal ze jak dysk jest 240GB to w praktyce ma kostek na 256GB. Ale tylko
gdybam...

> (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?
>
Tak, to wlasnie tlumaczylem.
Kontroler nie rozumie gdzie sa partycje.
Jak gdzies zapis byl to se notowal. Jak nie bylo trima na tym to nie uzywal do wear
levelingu. Jak gdzies nie miales wogole zapisu (czy to na nieuzytej partycji czy na
koncu partycji uzytej (nieco upraszczajac) to to bylo uzywane do wearlevelingu. No i
to co sie ztrymowalo tez bylo uzyte. Jak nie bylo trima miedzy zapisem a chwila
obecna to kontroler nie wie ze mozna nadpisac.

Jak np. zalozysz partycje pod winda (albo na kompie #1) I zaniesiesz dyska do
drugiego kompa albo podepniesz do linuxa i zalozysz partycje od nowa to nie sadze aby
linux/windows powiedzial dyskowi ze teraz caly obszar partycji ma byc uznany za
pusty. W efekcie mimo nawet dobrze dzialajacego trima dysk sie nie dowie o tym ze
spora jego czesc jest nieuzywana i moze robic za wear leveling.


> 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.
>
>

Pusc sobie iostat-a albo zajrzyj w statsy w /proc albo /sys 30MB stalego zapisu to
nie byle co i nawet na serwerze ktory robi za baze danych tyle zazwyczaj nie ma.
Tam cos innego sie musialo dziac. Albo te numerki sa niepoprawne z jakiegos powodu.
Albo inaczej:
Moze nie masz pod linuxem ustawionego noatime?
Wtedy kazdy odczyt powoduje malenki zapis. Bo access time trzeba dodac. Wtedy zapis
tych 4 bajtow (czy ile tam ta data zajmie) spowoduje zapis calego bloku na ssd.
I jak masz duzo odczytow to moze dojsc do sytuacji gdzie te 4bajty spuchna do 512
czy ile tam sektor na ssd teraz jest. a to jest jakies 100x wiecej...

do góry

On 2022-11-10, ToMasz <t...@p...fm.com.pl> wrote:
>> Widać, że swoje już odsłużył, pada, ale ciekawi mnie taka rzecz:
>> Ostatnia partycja nie była w ogóle w użyciu, a teraz jak ją przemiatam
>> badblockiem to równeż sypie błędami odczytu. Dlaczego?
>>
>
> który z dziesiątek parametrów wzkazuje na zbliżającą katastrofę? Bo old
> age, i prefail widziałem na 3 miesięczynych dyskach. JAk linuks
> (desktop) informuje o błędach odczytu/zapisu. logów na dobranoc nie
> czytam :(

Np. te (i inne w zależności od producenta):
5 Reallocated_Sector_Ct 0x0033 038 038 010 : 440
177 Wear_Leveling_Count 0x0013 001 001 000 : 2038
179 Used_Rsvd_Blk_Cnt_Tot 0x0013 038 038 010 : 440
183 Runtime_Bad_Block 0x0013 038 038 010 : 440
241 Total_LBAs_Written 0x0032 097 097 000 : 6830206817482

1-2038/3000(MLC) -> coś ze 32% życia zostało, chyba, że źle liczę.

Co do tych mam wątpliwości, ale się za specjalnie nie znam.
187 Uncorrectable_Error_Cnt 0x0032 097 097 000 : 28095
195 ECC_Error_Rate 0x001a 001 001 000 : 28095

--
Marcin

do góry

On 2022-11-11, Szwambuł Trantiputl <t...@d...com> wrote:
> Wcale nie przypadkiem, dnia Fri, 11 Nov 2022 01:01:11 GMT
> doszła do mnie wiadomość <r9hbL.2369207$%q2.1730743@fx15.ams1>
> od Marcin Debowski <a...@I...zoho.com> :
>>On 2022-11-10, Szwambuł Trantiputl <t...@d...com> wrote:
>>> Wcale nie przypadkiem, dnia Thu, 10 Nov 2022 06:59:39 GMT
>>> doszła do mnie wiadomość <vj1bL.852273$qD%2.456333@fx08.ams1>
>>> od Marcin Debowski <a...@I...zoho.com> :
>>>>Mam taki oto dysk:
>>>>Model Family: Samsung based SSDs
>>>>Device Model: Samsung SSD 860 EVO mSATA 250GB
>>>
>>>>
>>>>Vendor Specific SMART Attributes with Thresholds:
>>>>ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED
WHEN_FAILED RAW_VALUE
>>>> 5 Reallocated_Sector_Ct 0x0033 058 058 010 Pre-fail Always -
295
>>>> 9 Power_On_Hours 0x0032 094 094 000 Old_age Always -
27242
>>>> 12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always -
27
>>>>177 Wear_Leveling_Count 0x0013 001 001 000 Pre-fail Always -
2038
>>>>179 Used_Rsvd_Blk_Cnt_Tot 0x0013 058 058 010 Pre-fail Always -
295
>>>>181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always -
0
>>>>182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always -
0
>>>>183 Runtime_Bad_Block 0x0013 058 058 010 Pre-fail Always -
295
>>>>187 Uncorrectable_Error_Cnt 0x0032 099 099 000 Old_age Always -
5310
>>>>190 Airflow_Temperature_Cel 0x0032 035 027 000 Old_age Always -
65
>>>>195 ECC_Error_Rate 0x001a 199 199 000 Old_age Always -
5310
>>>>199 CRC_Error_Count 0x003e 100 100 000 Old_age Always -
0
>>>>235 POR_Recovery_Count 0x0012 099 099 000 Old_age Always -
20
>>>>241 Total_LBAs_Written 0x0032 097 097 000 Old_age Always -
6830194150602
>>>
>>> Przepraszam za niedyskretne pytanie, w czym ten dysk siedział?
>>> Z atrybutu 241 wychodzi, że zapisów ogółem było 3180.56 TB, co daje
>>> 2869 GB dziennie.
>>
>>No dziwne, zgadzam się, ale robiłem testy przyrostowe i 1GB zapisu
>>faktycznie dodaje ca 1GB do "241" (to są 512 bajtowe bloki). To to
>>siedzi w domowym serwerku pod debianem. Poczta, sql, www głownie. Mały
>>ruch, małe obciążenie. Początkowo myślałem, że ten swap tyle nawrzucał
>>(fizycznej 4GB, swap, partycja, tyle samo), ale zaczynam trochę wątpić.
>>
>>W tej chwili jak patrzę na przyrosty to są w granicach 0.5-2MB/min.
>>Kiedyś tam jeszcze chodził openvpn, ale nie wiem czymu miałby akurat on
>>tak nabić. Chodził też emby, ale biblioteka była na innym dysku.
>
> Jak na domowy serwer, to gigantyczne wartości, nurtuje mnie to, może
> to błąd firmware dysku(jakieś kosmicznie wielkie write amplification
> lub błędne dane), może jakiś proces w Linuksie cyklicznie powodował
> wypełnianie i zwalnianie swapa czy sranie do katalogów tymczasowych,
> coś to musiało być, może stare logi się zachowały i są w stanie coś
> powiedzieć?
> To musiało być średnio 33 MB/s zapisu na dysk.

Jo, tyle. Ale nie może być to amplifikacja bo 1GB zapisany zwiększa
właśnie o tyle licznik.

>>Dzięki tez za pozostałe uwagi.
>
> Już wiem, co to za chipy flash:
> https://www.techpowerup.com/ssd-specs/samsung-860-ev
o-250-gb.d6
> Teraz wystarczy jakoś poszukać specyfikacji z podanym TBW dla tych
> chipów, może jeszcze jest szansa, że jednak mają zapas, czyli po
> secure erase dysk jeszcze popracuje.

Samsung dla tego dysku daje gwarancje na 150TBW. W sumie jakoś mało jak
na MLC?

--
Marcin

do góry

czwartek, 10 listopada 2022 o 22:12:52 UTC-6 Marcin Debowski napisał(a):

> > To musiało być średnio 33 MB/s zapisu na dysk.
> Jo, tyle. Ale nie może być to amplifikacja bo 1GB zapisany zwiększa
> właśnie o tyle licznik.

Zrob sobie test i zapisz 1000x 1 bajt daleko od siebie. System pokaze ze to jest
1000B zapisu a dysk ze 1000x512 czy 4096 (nie pamietam ile to wyjdzie na ssd).

do góry

Wcale nie przypadkiem, dnia Fri, 11 Nov 2022 04:12:50 GMT
doszła do mnie wiadomość <6ZjbL.1572754$%fx6.340553@fx14.ams1>
od Marcin Debowski <a...@I...zoho.com> :
>On 2022-11-11, Szwambuł Trantiputl <t...@d...com> wrote:
>> Wcale nie przypadkiem, dnia Fri, 11 Nov 2022 01:01:11 GMT
>> doszła do mnie wiadomość <r9hbL.2369207$%q2.1730743@fx15.ams1>
>> od Marcin Debowski <a...@I...zoho.com> :
>>>On 2022-11-10, Szwambuł Trantiputl <t...@d...com> wrote:
>>>> Wcale nie przypadkiem, dnia Thu, 10 Nov 2022 06:59:39 GMT
>>>> doszła do mnie wiadomość <vj1bL.852273$qD%2.456333@fx08.ams1>
>>>> od Marcin Debowski <a...@I...zoho.com> :
>>>>>Mam taki oto dysk:
>>>>>Model Family: Samsung based SSDs
>>>>>Device Model: Samsung SSD 860 EVO mSATA 250GB
>>>>
>>>>>
>>>>>Vendor Specific SMART Attributes with Thresholds:
>>>>>ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED
WHEN_FAILED RAW_VALUE
>>>>> 5 Reallocated_Sector_Ct 0x0033 058 058 010 Pre-fail Always -
295
>>>>> 9 Power_On_Hours 0x0032 094 094 000 Old_age Always -
27242
>>>>> 12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always -
27
>>>>>177 Wear_Leveling_Count 0x0013 001 001 000 Pre-fail Always -
2038
>>>>>179 Used_Rsvd_Blk_Cnt_Tot 0x0013 058 058 010 Pre-fail Always -
295
>>>>>181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always -
0
>>>>>182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always -
0
>>>>>183 Runtime_Bad_Block 0x0013 058 058 010 Pre-fail Always -
295
>>>>>187 Uncorrectable_Error_Cnt 0x0032 099 099 000 Old_age Always -
5310
>>>>>190 Airflow_Temperature_Cel 0x0032 035 027 000 Old_age Always -
65
>>>>>195 ECC_Error_Rate 0x001a 199 199 000 Old_age Always -
5310
>>>>>199 CRC_Error_Count 0x003e 100 100 000 Old_age Always -
0
>>>>>235 POR_Recovery_Count 0x0012 099 099 000 Old_age Always -
20
>>>>>241 Total_LBAs_Written 0x0032 097 097 000 Old_age Always -
6830194150602
>>>>
>>>> Przepraszam za niedyskretne pytanie, w czym ten dysk siedział?
>>>> Z atrybutu 241 wychodzi, że zapisów ogółem było 3180.56 TB, co daje
>>>> 2869 GB dziennie.
>>>
>>>No dziwne, zgadzam się, ale robiłem testy przyrostowe i 1GB zapisu
>>>faktycznie dodaje ca 1GB do "241" (to są 512 bajtowe bloki). To to
>>>siedzi w domowym serwerku pod debianem. Poczta, sql, www głownie. Mały
>>>ruch, małe obciążenie. Początkowo myślałem, że ten swap tyle nawrzucał
>>>(fizycznej 4GB, swap, partycja, tyle samo), ale zaczynam trochę wątpić.
>>>
>>>W tej chwili jak patrzę na przyrosty to są w granicach 0.5-2MB/min.
>>>Kiedyś tam jeszcze chodził openvpn, ale nie wiem czymu miałby akurat on
>>>tak nabić. Chodził też emby, ale biblioteka była na innym dysku.
>>
>> Jak na domowy serwer, to gigantyczne wartości, nurtuje mnie to, może
>> to błąd firmware dysku(jakieś kosmicznie wielkie write amplification
>> lub błędne dane), może jakiś proces w Linuksie cyklicznie powodował
>> wypełnianie i zwalnianie swapa czy sranie do katalogów tymczasowych,
>> coś to musiało być, może stare logi się zachowały i są w stanie coś
>> powiedzieć?
>> To musiało być średnio 33 MB/s zapisu na dysk.
>
>Jo, tyle. Ale nie może być to amplifikacja bo 1GB zapisany zwiększa
>właśnie o tyle licznik.
>
>>>Dzięki tez za pozostałe uwagi.
>>
>> Już wiem, co to za chipy flash:
>> https://www.techpowerup.com/ssd-specs/samsung-860-ev
o-250-gb.d6
>> Teraz wystarczy jakoś poszukać specyfikacji z podanym TBW dla tych
>> chipów, może jeszcze jest szansa, że jednak mają zapas, czyli po
>> secure erase dysk jeszcze popracuje.
>
>Samsung dla tego dysku daje gwarancje na 150TBW. W sumie jakoś mało jak
>na MLC?

Znalazłem test wytrzymałości tego(i wielu innych dysków, w języku
rosyjskim, ale jest czytelne:
https://3dnews.ru/938764/resursnie-ispitaniya-ssd-ob
novlyaemiy-material#Samsung%20860%20EVO
Nasz bohater padł osiągając 3.004 PB.
Czyli najparwdopodobniej parametr 177 - wear leveling count to jest
średnia ilość zerowań stron flash, ty masz 2032, dysk z testu padł
przy 2775.
Co najdziwniejsze, 860 Pro(na kościach chyba MLC 2 bit, jest na
stronie zaraz pod 860 EVO) padł przy 2.706 TB, czyli wytrzymał niemal
300 TB mniej niż EVO...
Nieźle pojechał 850 Pro, zaliczył 7.5 PB(wszystkie trzy dyski 256 GB).
--
Pójdziesz Pleśniowy
Legniesz Ciekliwy
Nakarmisz osty
Najesz pokrzywy
Stanisław Grochowiak.

do góry

Wcale nie przypadkiem, dnia Fri, 11 Nov 2022 04:12:50 GMT
doszła do mnie wiadomość <6ZjbL.1572754$%fx6.340553@fx14.ams1>
od Marcin Debowski <a...@I...zoho.com> :

>Samsung dla tego dysku daje gwarancje na 150TBW. W sumie jakoś mało jak
>na MLC?

Małe wyjaśnienie, 860 EVO to 3d TLC(samsung to nazywa MLC 3bit),
natomiast 860 PRO to MLC 2bit.
--
Pójdziesz Pleśniowy
Legniesz Ciekliwy
Nakarmisz osty
Najesz pokrzywy
Stanisław Grochowiak.

do góry

On 2022-11-11, Szwambuł Trantiputl <t...@d...com> wrote:
> Wcale nie przypadkiem, dnia Fri, 11 Nov 2022 03:33:59 GMT
> doszła do mnie wiadomość <HojbL.1572752$%fx6.1407141@fx14.ams1>
> od Marcin Debowski <a...@I...zoho.com> :
>>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)?
>
> Tu trzeba by wniknąć trochę głębiej w mechanizm działania FTL(flash
> translation layer, punkt 4):
> https://codecapsule.com/2014/02/12/coding-for-ssds-p
art-3-pages-blocks-and-the-flash-translation-layer/
> Może tablice FTL są popsute (secure erase je najprawdopodobniej
> wyzeruje), może poprostu firmware trafił na coś, z czym nie daje sobie
> rady(reflash firmware na nowszy nie zaszkodzi).

Dzięki. Jak przyjdzie zamiennik to poeksperymentuję. Samsung ma
jakiś-tam cały kombajn programowy pod Windowows do obsługo swoich ssd,
zobaczymy co zawyrokuje.

Przy okazji, być może głupie pytanie, czy takie pamięci jak leżą poza
urządzeniem (bez prądu znaczy), przez np. 3-4 lata, to coś się złego
może z nimi dziać?

--
Marcin

do góry