eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.pecetanatomia padania ssd
Ilość wypowiedzi w tym wątku: 30

  • 1. Data: 2022-11-10 07:59:39
    Temat: anatomia padania ssd
    Od: Marcin Debowski <a...@I...zoho.com>

    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

    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

    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

    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?

    --
    Marcin


  • 2. Data: 2022-11-10 10:40:29
    Temat: Re: anatomia padania ssd
    Od: Roman Tyczka <r...@h...you.spammer>

    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



  • 3. Data: 2022-11-10 11:24:06
    Temat: Re: anatomia padania ssd
    Od: Marcin Debowski <a...@I...zoho.com>

    On 2022-11-10, Roman Tyczka <r...@h...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


  • 4. Data: 2022-11-10 12:13:17
    Temat: Re: anatomia padania ssd
    Od: Roman Tyczka <r...@h...you.spammer>

    On 10.11.2022 11:24, Marcin Debowski wrote:
    > On 2022-11-10, Roman Tyczka <r...@h...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



  • 5. Data: 2022-11-10 13:11:39
    Temat: Re: anatomia padania ssd
    Od: Marcin Debowski <a...@I...zoho.com>

    On 2022-11-10, Roman Tyczka <r...@h...you.spammer> wrote:
    > On 10.11.2022 11:24, Marcin Debowski wrote:
    >> On 2022-11-10, Roman Tyczka <r...@h...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


  • 6. Data: 2022-11-10 13:33:08
    Temat: Re: anatomia padania ssd
    Od: "ptoki (ptoki)" <s...@g...com>

    czwartek, 10 listopada 2022 o 06:11:41 UTC-6 Marcin Debowski napisał(a):
    > On 2022-11-10, Roman Tyczka <r...@h...you.spammer> wrote:
    > > On 10.11.2022 11:24, Marcin Debowski wrote:
    > >> On 2022-11-10, Roman Tyczka <r...@h...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.


  • 7. Data: 2022-11-10 14:17:02
    Temat: Re: anatomia padania ssd
    Od: ToMasz <t...@p...fm.com.pl>

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



  • 8. Data: 2022-11-10 21:54:23
    Temat: Re: anatomia padania ssd
    Od: Szwambuł Trantiputl <t...@d...com>

    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.

    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.


  • 9. Data: 2022-11-10 23:30:09
    Temat: Re: anatomia padania ssd
    Od: Adam <a...@p...onet.pl>

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

    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


  • 10. Data: 2022-11-11 02:01:11
    Temat: Re: anatomia padania ssd
    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.

    Dzięki tez za pozostałe uwagi.

    --
    Marcin

strony : [ 1 ] . 2 . 3


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: