On 2022-11-11, Szwambuł Trantiputl <t...@d...com> wrote:
> 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).

Nie otwiera mi się. One typowo padają gwałtownie czy widać np. jakieś
spowolnienie? Czy też właśnie tak jak obecnie obserwuje, czyli pojawia
się dużo błędów podczas np. czytania?

--
Marcin

do góry

On 2022-11-11, ptoki (ptoki) <s...@g...com> wrote:
> 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).

To się zgadza, ale to efekt bloków mniejszych od jednostki alokacji
sektora. Przy 1GB takie coś nie wystąpi bo jak?

--
Marcin

do góry

Wcale nie przypadkiem, dnia Fri, 11 Nov 2022 23:04:16 GMT
doszła do mnie wiadomość <QxAbL.2370679$%q2.2052833@fx15.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 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ć?

Złego to raczej nie, ale dane mogą zostać uszkodzone przez utratę
ładunku komórek flash. Im więcej taka komórka ma na koncie zapisów,
tym szybciej to następuje, o ile komórka z małą ilością zapisów trzyma
ładunek nawet 5-6 lat, to pod koniec żywotności to może spaść do kilku
miesięcy, nawet do trzech.
--
Pójdziesz Pleśniowy
Legniesz Ciekliwy
Nakarmisz osty
Najesz pokrzywy
Stanisław Grochowiak.

do góry

Wcale nie przypadkiem, dnia Fri, 11 Nov 2022 23:09:23 GMT
doszła do mnie wiadomość <DCAbL.2370680$%q2.2197551@fx15.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 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).
>
>Nie otwiera mi się. One typowo padają gwałtownie czy widać np. jakieś
>spowolnienie? Czy też właśnie tak jak obecnie obserwuje, czyli pojawia
>się dużo błędów podczas np. czytania?

Przypomniało mi się, gdzieś w jakimś badaniu dysków na wytrzymałość
były wykresy pokazujące spory spadek wydajności, ale nie pamiętam, czy
dla wszystkich typów dysków.
W wyszukiwarce poszukaj frazy "ssd endurance experiment" czy "ssd
endurance challenge", kilka takich było, ale ostatni zakończono chyba
cztery czy pięć lat temu.
Pierwszy link, jaki znalazłem:
https://3dnews.ru/938764/resursnie-ispitaniya-ssd-ob
novlyaemiy-material
Czyli wydajność spadała niezbyt wiele.
--
Pójdziesz Pleśniowy
Legniesz Ciekliwy
Nakarmisz osty
Najesz pokrzywy
Stanisław Grochowiak.

do góry

Wcale nie przypadkiem, dnia Fri, 11 Nov 2022 23:16:03 GMT
doszła do mnie wiadomość <TIAbL.2259218$f0c6.2134186@fx10.ams1>
od Marcin Debowski <a...@I...zoho.com> :
>On 2022-11-11, ptoki (ptoki) <s...@g...com> wrote:
>> 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).
>
>To się zgadza, ale to efekt bloków mniejszych od jednostki alokacji
>sektora. Przy 1GB takie coś nie wystąpi bo jak?

Może to jednak jakiś dziwny błąd firmware, bo moim zdaniem jakby coś
tak(aplikacja/proces) waliło po dysku, to powinny być widoczne spore,
okresowe spadki wydajności, ale mogę się mylić.
Sprawa otwarta.
--
Pójdziesz Pleśniowy
Legniesz Ciekliwy
Nakarmisz osty
Najesz pokrzywy
Stanisław Grochowiak.

do góry

On 2022-11-11, ptoki (ptoki) <s...@g...com> wrote:
> 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.

Gdzieś się coś nie kaszuje i uwalnia z dużym opóźnieniem? W sensie, że
iostat o bieżących operacjach a gdzieś siedzi w jakimś buforze 0.8GB i
dopiero po dłuższym czasie zostaje fizycznie zapisane?

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

Dzięki, pomęcze biedaka jak go już wymienie.

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

Czym można z lini poleceń sprawdzić wydajność odczytów w jakiś rozsądny
sposób? Czy masz na myśli przeczytanie całego urządzenia np. dd? Bo
chyba nie to:

root@agatek:~# hdparm -tT /dev/sda

/dev/sda:
Timing cached reads: 2498 MB in 2.00 seconds = 1249.94 MB/sec
Timing buffered disk reads: 1074 MB in 3.00 seconds = 357.78 MB/sec

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

A ten kontroler to nie powinien być w obrębie ssd i pamiętać takich rzeczy?

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

Dzięki, popatrzę, ale obecnie nic się nie dzieje.

--
Marcin

do góry

piątek, 11 listopada 2022 o 18:43:51 UTC-6 Marcin Debowski napisał(a):
> On 2022-11-11, ptoki (ptoki) <s...@g...com> wrote:
> > 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.
> Gdzieś się coś nie kaszuje i uwalnia z dużym opóźnieniem? W sensie, że
> iostat o bieżących operacjach a gdzieś siedzi w jakimś buforze 0.8GB i
> dopiero po dłuższym czasie zostaje fizycznie zapisane?

Nie wiem, mysle ze nie. Probowalem sie wywiedziec od lolka co pisal fstrim i
przegladalem kod i nie dowiedzialem sie czemu takie dziwne zachowanie jest.
A jest na roznych kompach, z roznymi systemami. I wiem ze jakby lolek od fstrima
chcial to by zreplikowal moj eksperyment w doslownie 2 minuty.
Jego tlumaczenia byly po prostu powtarzaniem tego co w kodzie i na stronie. Obstawiam
ze on zaimplementowal to tak jak gdzies napisano bez zbytniego testowania i ogladu.
A no i to samo jest na roznych dyskach. Od jakichs cruciali, poprzez samsungi az po
kingstony.

I jeszcze, gdyby fstrim zwalnial mniej niz pokazuje iostat to bym zalozyl ze moze OS
robi cos a fstrim nie ma szansy na zwolnienie bo OS to zrobil.
Ale jest zazwyczaj odwrotnie.
Moze, moze, ogromne moze podczas operacji IO jest wysylane cos w rodzaju "zapisz 3
bajty ale zaznacz caly blok za zapisany" i fstrim zwalnia caly blok i dlatego opmpuje
numerki ale to jest niekonsystentne nawet tak.
Bo operacja IO jest jedna czy piec na krzyz i zapisow jest na 300kB a fstrim zwalnia
np. 20MB.

Nie klei sie to zupelnie.

No i na koniec to mimo ze fstrim biega caly czas to moglem jakims cudem odwolac te
bloki recznie i dysk dostal kopa. Smierdzaca sprawa.


> Czym można z lini poleceń sprawdzić wydajność odczytów w jakiś rozsądny
> sposób? Czy masz na myśli przeczytanie całego urządzenia np. dd? Bo
> chyba nie to:
>
> root@agatek:~# hdparm -tT /dev/sda
>
> /dev/sda:
> Timing cached reads: 2498 MB in 2.00 seconds = 1249.94 MB/sec
> Timing buffered disk reads: 1074 MB in 3.00 seconds = 357.78 MB/sec

Hdparm jest slaby do tego. Ja uzywam disks z gui. Tam mozna zapodac ile probek i
jakiej wielkosci ma pobrac z calej powierzchni.
I ladnie widac ktore obszary sa zaafektowane. Jak masz plaski wykres na poziomie tych
200 czy 25 albo 500MB/sek to dysk jest zdrowy.
Jak wydajnosc opada o polowe albo do 20% tego sufitu to wiadomo ze cos jest nie tak.
I to wszystko przy odczytach. O zapisach nawet nie wspominam.

> > 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.
> A ten kontroler to nie powinien być w obrębie ssd i pamiętać takich rzeczy?

Nie, bo trim mowi dyskowi co jest nieuzywane.
A trim z windy nie wie co skasowal linux i odwrotnie.
No i nie wiem czy format mowi ze teraz wszystko na partycji jest nieuzyte zanim
zacznie formatowac.
Ogolnie w tym zakresie nieco kiepsko to wyglada. Trzeba niestety z paranoi podcierac
tym dyskom tylki...

do góry

On 2022-11-11, Szwambuł Trantiputl <t...@d...com> wrote:
> Wcale nie przypadkiem, dnia Fri, 11 Nov 2022 23:04:16 GMT
> doszła do mnie wiadomość <QxAbL.2370679$%q2.2052833@fx15.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 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ć?
>
> Złego to raczej nie, ale dane mogą zostać uszkodzone przez utratę
> ładunku komórek flash. Im więcej taka komórka ma na koncie zapisów,
> tym szybciej to następuje, o ile komórka z małą ilością zapisów trzyma
> ładunek nawet 5-6 lat, to pod koniec żywotności to może spaść do kilku
> miesięcy, nawet do trzech.

To wystarczy. Po prostu zastanawiam się nad kupnem czegoś na zapas bo o
mSATA coraz trudniej.

--
Marcin

do góry

On 2022-11-13, ptoki (ptoki) <s...@g...com> wrote:
> piątek, 11 listopada 2022 o 18:43:51 UTC-6 Marcin Debowski napisał(a):
>> Czym można z lini poleceń sprawdzić wydajność odczytów w jakiś rozsądny
>> sposób? Czy masz na myśli przeczytanie całego urządzenia np. dd? Bo
>> chyba nie to:
>>
>> root@agatek:~# hdparm -tT /dev/sda
>>
>> /dev/sda:
>> Timing cached reads: 2498 MB in 2.00 seconds = 1249.94 MB/sec
>> Timing buffered disk reads: 1074 MB in 3.00 seconds = 357.78 MB/sec
>
> Hdparm jest slaby do tego. Ja uzywam disks z gui. Tam mozna zapodac
> ile probek i jakiej wielkosci ma pobrac z calej powierzchni. I ladnie
> widac ktore obszary sa zaafektowane. Jak masz plaski wykres na
> poziomie tych 200 czy 25 albo 500MB/sek to dysk jest zdrowy. Jak
> wydajnosc opada o polowe albo do 20% tego sufitu to wiadomo ze cos
> jest nie tak. I to wszystko przy odczytach. O zapisach nawet nie
> wspominam.

Ok, sprawdzę przy okazji. Dzięki.

--
Marcin

do góry

On 2022-11-10, Marcin Debowski <a...@I...zoho.com> wrote:
> Mam taki oto dysk:
> Model Family: Samsung based SSDs
> Device Model: Samsung SSD 860 EVO mSATA 250GB
> Serial Number: S41MNX0M412082W
> LU WWN Device Id: 5 002538 e40f4e862
> Firmware Version: RVT42B6Q
> User Capacity: 250,059,350,016 bytes [250 GB]
> Sector Size: 512 bytes logical/physical
> Rotation Rate: Solid State Device
> Form Factor: mSATA
> TRIM Command: Available, deterministic, zeroed
> Device is: In smartctl database [for details use: -P show]
> ATA Version is: ACS-4 T13/BSR INCITS 529 revision 5
> SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
> Local Time is: Thu Nov 10 14:48:57 2022 +08
> SMART support is: Available - device has SMART capability.
> SMART support is: Enabled

Koniec tej historii jest taki, że napuściłem niejakiego Samsung Magician
(SM) na ten dysk (musiałem uzyć przejściówki mSATA->SATA). SM popatrzał,
znalazł błedy (full scan) i zadeklarował, ze on je spokojnie naprawi.
Pozwoliłem. Pokazał, że wszystko jest cacuś. Przeleciałem po tym dysk
ddrescue i znalazł praktycznie tyle samo błędów. No to jeszcze raz SM.
Znowu z dumą naprawił. Juz mi się niechciało rebutować do Linuksa i
przeskanowałem ten naprawiony dysk SM raz jeszcze i znowu znalazł błędy.
Tak, że ten tego. Viva Samsung.

--
Marcin

do góry