🚀 go-pugleaf

On 10.11.2022 07:59, Marcin Debowski wrote:
> Device     Boot     Start       End   Sectors   Size Id Type
> /dev/sda1            2048   8390655   8388608     4G 82 Linux swap / Solaris
> /dev/sda2  *      8390656 125045423 116654768  55.6G 83 Linux
> /dev/sda3       125046784 488397167 363350384 173.3G 83 Linux
> 
> 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?

Bo kontroler rozrzuca dane po całym fizycznym dysku?
Dlatego zaleca się zostawienie 10% niespartycjonowanej powierzchni na 
SSD, wtedy nawet dobicie zajętością do 100% pozostałych partycji nie 
jest groźne.

-- 
pzdr
Roman

On 2022-11-10, Roman Tyczka <romantyczka@hate.you.spammer> wrote:
> On 10.11.2022 07:59, Marcin Debowski wrote:
>> Device     Boot     Start       End   Sectors   Size Id Type
>> /dev/sda1            2048   8390655   8388608     4G 82 Linux swap / Solaris
>> /dev/sda2  *      8390656 125045423 116654768  55.6G 83 Linux
>> /dev/sda3       125046784 488397167 363350384 173.3G 83 Linux
>> 
>> 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?
>
> Bo kontroler rozrzuca dane po całym fizycznym dysku?
> Dlatego zaleca się zostawienie 10% niespartycjonowanej powierzchni na 
> SSD, wtedy nawet dobicie zajętością do 100% pozostałych partycji nie 
> jest groźne.

Skąd kontroler wie jak jest spartycjowany dysk? To nie ten MZ poziom 
abstrakcji. Partycje nie są inicjowane poprzez wypełnienie ich w 
jakikolwiek sposób a typów partycji jest kilka.

-- 
Marcin

On 10.11.2022 11:24, Marcin Debowski wrote:
> On 2022-11-10, Roman Tyczka <romantyczka@hate.you.spammer> wrote:
>> On 10.11.2022 07:59, Marcin Debowski wrote:
>>> Device     Boot     Start       End   Sectors   Size Id Type
>>> /dev/sda1            2048   8390655   8388608     4G 82 Linux swap / Solaris
>>> /dev/sda2  *      8390656 125045423 116654768  55.6G 83 Linux
>>> /dev/sda3       125046784 488397167 363350384 173.3G 83 Linux
>>>
>>> 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?
>>
>> Bo kontroler rozrzuca dane po całym fizycznym dysku?
>> Dlatego zaleca się zostawienie 10% niespartycjonowanej powierzchni na
>> SSD, wtedy nawet dobicie zajętością do 100% pozostałych partycji nie
>> jest groźne.
> 
> Skąd kontroler wie jak jest spartycjowany dysk? To nie ten MZ poziom
> abstrakcji. Partycje nie są inicjowane poprzez wypełnienie ich w
> jakikolwiek sposób a typów partycji jest kilka.

No właśnie nie wie, bo nie musi wiedzieć. Wie, ża ma blok danych zapisać 
na dysku i zapisuje tam gdzie chce, mając partycje w nosie.

-- 
pzdr
Roman

On 2022-11-10, Roman Tyczka <romantyczka@hate.you.spammer> wrote:
> On 10.11.2022 11:24, Marcin Debowski wrote:
>> On 2022-11-10, Roman Tyczka <romantyczka@hate.you.spammer> wrote:
>>> On 10.11.2022 07:59, Marcin Debowski wrote:
>>>> Device     Boot     Start       End   Sectors   Size Id Type
>>>> /dev/sda1            2048   8390655   8388608     4G 82 Linux swap / Solaris
>>>> /dev/sda2  *      8390656 125045423 116654768  55.6G 83 Linux
>>>> /dev/sda3       125046784 488397167 363350384 173.3G 83 Linux
>>>>
>>>> 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?
>>>
>>> Bo kontroler rozrzuca dane po całym fizycznym dysku?
>>> Dlatego zaleca się zostawienie 10% niespartycjonowanej powierzchni na
>>> SSD, wtedy nawet dobicie zajętością do 100% pozostałych partycji nie
>>> jest groźne.
>> 
>> Skąd kontroler wie jak jest spartycjowany dysk? To nie ten MZ poziom
>> abstrakcji. Partycje nie są inicjowane poprzez wypełnienie ich w
>> jakikolwiek sposób a typów partycji jest kilka.
>
> No właśnie nie wie, bo nie musi wiedzieć. Wie, ża ma blok danych zapisać 
> na dysku i zapisuje tam gdzie chce, mając partycje w nosie.

To nie rozumiem komentarza, że się zaleca min 10% skoro z tego co 
napisałem wynika, że zostawiłem wolne jakieś 70%. Pytanie, dlaczego te 
70% ma błędy skoro nic tam zasadniczo nie pisało. Obstawiam, że może 
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.

-- 
Marcin

czwartek, 10 listopada 2022 o 06:11:41 UTC-6 Marcin Debowski napisał(a):
> On 2022-11-10, Roman Tyczka <roman...@hate.you.spammer> wrote: 
> > On 10.11.2022 11:24, Marcin Debowski wrote: 
> >> On 2022-11-10, Roman Tyczka <roman...@hate.you.spammer> wrote: 
> >>> On 10.11.2022 07:59, Marcin Debowski wrote: 
> >>>> Device Boot Start End Sectors Size Id Type 
> >>>> /dev/sda1 2048 8390655 8388608 4G 82 Linux swap / Solaris 
> >>>> /dev/sda2 * 8390656 125045423 116654768 55.6G 83 Linux 
> >>>> /dev/sda3 125046784 488397167 363350384 173.3G 83 Linux 
> >>>> 
> >>>> 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? 
> >>> 
> >>> Bo kontroler rozrzuca dane po całym fizycznym dysku? 
> >>> Dlatego zaleca się zostawienie 10% niespartycjonowanej powierzchni na 
> >>> SSD, wtedy nawet dobicie zajętością do 100% pozostałych partycji nie 
> >>> jest groźne. 
> >> 
> >> Skąd kontroler wie jak jest spartycjowany dysk? To nie ten MZ poziom 
> >> abstrakcji. Partycje nie są inicjowane poprzez wypełnienie ich w 
> >> jakikolwiek sposób a typów partycji jest kilka. 
> > 
> > No właśnie nie wie, bo nie musi wiedzieć. Wie, ża ma blok danych zapisać 
> > na dysku i zapisuje tam gdzie chce, mając partycje w nosie.
> To nie rozumiem komentarza, że się zaleca min 10% skoro z tego co 
> napisałem wynika, że zostawiłem wolne jakieś 70%. Pytanie, dlaczego te 
> 70% ma błędy skoro nic tam zasadniczo nie pisało. Obstawiam, że może 

1. Minimum 10% oznacza minimum. 30% jest lepiej ale nadal ten problem wystepuje.
2. Musisz wiedziec ze kontroler sledzi caly dysk i liczy sobie jak mocno uzyte sa poszczegolne bloki komorek.
3. Uzycie tych blokow jest zazwyczaj bardzo nierownomierne.
4. Sa sposoby aby dac mu troche zycia.

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

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.

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.

* - pad dysku jest dosyc nierownomierny. Kontroler sobie sprawdza jakiej jakosci sa komorki i moze czasem stwierdzic ze nie ma co, padamy na sztywno i szybko a czasem probuje cos z tym zrobic i pada podobnie jak pokazujesz. Kiedys padaly na zimno i nie bylo nawet bledow odczytu. Jak sie pojawily to dysk potem juz w biosie sie nawet nie pokazywal. Teraz widze ze jest nieco lepiej.

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.

(...)
> Device     Boot     Start       End   Sectors   Size Id Type
> /dev/sda1            2048   8390655   8388608     4G 82 Linux swap / Solaris
> /dev/sda2  *      8390656 125045423 116654768  55.6G 83 Linux
> /dev/sda3       125046784 488397167 363350384 173.3G 83 Linux
> 
> 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 :(

ToMasz

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 <agatek@INVALID.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.

Ciekaw jestem, czy to przekroczyło wytrzymałość chipów z rego dysku -
V-NAND 3bit MLC, mogło już przekroczyć maksymalną ilość zapisów, ale
nie chce mi się szukać, a w dodatku nie wiem, jak interpretować
atrybut 177 - wear leveling count -> 2038 w tym modelu.

>SMART Self-test log structure revision number 1
>Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
># 1  Extended offline    Completed: read failure       90%     27237         491744
># 2  Extended offline    Completed: read failure       90%     27236         491744
># 3  Short offline       Completed: read failure       80%     27236         491744
># 4  Short offline       Completed: read failure       80%     27236         491744
>
>Disk /dev/sda: 232.89 GiB, 250059350016 bytes, 488397168 sectors
>Disk model: Samsung SSD 860 
>Units: sectors of 1 * 512 = 512 bytes
>Sector size (logical/physical): 512 bytes / 512 bytes
>I/O size (minimum/optimal): 512 bytes / 512 bytes
>Disklabel type: dos
>Disk identifier: 0x46341ac6
>
>Device     Boot     Start       End   Sectors   Size Id Type
>/dev/sda1            2048   8390655   8388608     4G 82 Linux swap / Solaris
>/dev/sda2  *      8390656 125045423 116654768  55.6G 83 Linux
>/dev/sda3       125046784 488397167 363350384 173.3G 83 Linux

Miałem dysk z podobnym objawem, pomogło mu secure erase, ale tylko na
pewien czas, już nie pamiętam, co z tym dyskiem dalej się działo(jakiś
Adata 128 GB M.2).

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

Wear leveling:
https://en.wikipedia.org/wiki/Wear_leveling

Czy może komputer, w którym siedział ten dysk, wyliczał funkcję falową
wszechświata? No bo te 2896 GB dziennie, to trochę szokuje, typowy
user jedzie kilkanaście GB.
Szwambuł Trantiputl
-- 
Pójdziesz Pleśniowy
Legniesz Ciekliwy
Nakarmisz osty
Najesz pokrzywy
		Stanisław Grochowiak. 

Dnia Thu, 10 Nov 2022 21:54:23 +0100, Szwambuł Trantiputl napisał(a):

> 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 <agatek@INVALID.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.

Z tego, co ja widzę:

>> 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       27

musowo siedział w jakimś serwerze lub workstation.


-- 
Pozdrawiam.

Adam

On 2022-11-10, Szwambuł Trantiputl <trantiputl@duck.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 <agatek@INVALID.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.

Dzięki tez za pozostałe uwagi.

-- 
Marcin

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 <agatek@INVALID.zoho.com>  :
>On 2022-11-10, Szwambuł Trantiputl <trantiputl@duck.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 <agatek@INVALID.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-evo-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. 

On 2022-11-10, ptoki (ptoki) <sczygiel@gmail.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

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 <agatek@INVALID.zoho.com>  :
>On 2022-11-10, ptoki (ptoki) <sczygiel@gmail.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-part-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. 

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

On 2022-11-10, ToMasz <tomasz@poczta.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

On 2022-11-11, Szwambuł Trantiputl <trantiputl@duck.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 <agatek@INVALID.zoho.com>  :
>>On 2022-11-10, Szwambuł Trantiputl <trantiputl@duck.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 <agatek@INVALID.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-evo-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

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

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 <agatek@INVALID.zoho.com>  :
>On 2022-11-11, Szwambuł Trantiputl <trantiputl@duck.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 <agatek@INVALID.zoho.com>  :
>>>On 2022-11-10, Szwambuł Trantiputl <trantiputl@duck.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 <agatek@INVALID.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-evo-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-obnovlyaemiy-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. 

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 <agatek@INVALID.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. 

On 2022-11-11, Szwambuł Trantiputl <trantiputl@duck.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 <agatek@INVALID.zoho.com>  :
>>On 2022-11-10, ptoki (ptoki) <sczygiel@gmail.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-part-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

On 2022-11-11, Szwambuł Trantiputl <trantiputl@duck.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 <agatek@INVALID.zoho.com>  :
>>On 2022-11-11, Szwambuł Trantiputl <trantiputl@duck.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 <agatek@INVALID.zoho.com>  :
>>>>On 2022-11-10, Szwambuł Trantiputl <trantiputl@duck.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 <agatek@INVALID.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-evo-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-obnovlyaemiy-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

On 2022-11-11, ptoki (ptoki) <sczygiel@gmail.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

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 <agatek@INVALID.zoho.com>  :
>On 2022-11-11, Szwambuł Trantiputl <trantiputl@duck.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 <agatek@INVALID.zoho.com>  :
>>>On 2022-11-10, ptoki (ptoki) <sczygiel@gmail.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-part-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. 

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 <agatek@INVALID.zoho.com>  :
>On 2022-11-11, Szwambuł Trantiputl <trantiputl@duck.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 <agatek@INVALID.zoho.com>  :
>>>On 2022-11-11, Szwambuł Trantiputl <trantiputl@duck.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 <agatek@INVALID.zoho.com>  :
>>>>>On 2022-11-10, Szwambuł Trantiputl <trantiputl@duck.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 <agatek@INVALID.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-evo-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-obnovlyaemiy-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-obnovlyaemiy-material
Czyli wydajność spadała niezbyt wiele.
-- 
Pójdziesz Pleśniowy
Legniesz Ciekliwy
Nakarmisz osty
Najesz pokrzywy
		Stanisław Grochowiak. 

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 <agatek@INVALID.zoho.com>  :
>On 2022-11-11, ptoki (ptoki) <sczygiel@gmail.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. 

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

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

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

piątek, 11 listopada 2022 o 18:43:51 UTC-6 Marcin Debowski napisał(a):
> On 2022-11-11, ptoki (ptoki) <sczy...@gmail.com> wrote:
> > 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.
> 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...

On 2022-11-11, Szwambuł Trantiputl <trantiputl@duck.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 <agatek@INVALID.zoho.com>  :
>>On 2022-11-11, Szwambuł Trantiputl <trantiputl@duck.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 <agatek@INVALID.zoho.com>  :
>>>>On 2022-11-10, ptoki (ptoki) <sczygiel@gmail.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-part-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

On 2022-11-13, ptoki (ptoki) <sczygiel@gmail.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

On 2022-11-10, Marcin Debowski <agatek@INVALID.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