czwartek, 10 listopada 2022 o 21:34:02 UTC-6 Marcin Debowski napisał(a):
> On 2022-11-10, ptoki (ptoki) <sczy...@gmail.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-discard-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...
|