Forum Debian Users Gang

Jacekalex napisał(-a):

W jakich jednostkach podają Total_LBAs_Written dyski OCZ/Toshiba, bo z pewnością nie a bajtach,
prawdopodobnie nie w kilobajtach nawet?

Ja tam widzę że masz zapisane około 83,5GB, czyli u ciebie jest prosto i podaje w MB. Niestety producenci mają to gdzieś i każdy podaje, jeżeli w ogóle podają, to jak im się podoba. Najprościej sprawdzić to przez prosty test. Na przykład zobaczyć jaki jest wynik LBAs i utworzyć plik powiedzmy tak.

dd if=/dev/zero of=test_LBAs bs=500MB count=1

To da plik o wielkości 500MB. I teraz sprawdzić czy parametr zwiększył się o tyle. Ale nie zawsze jest tak prosto, na przykład samsung podaje zapis sektorami i w tym przypadku wartość LBAs zwiększy się o około 976568, co da 976568*512=500002816 (czyli przy sektorze 512bajtów zapisano 500MB).

Edycja: No, czyli te wartości masz prawidłowe.

------------------------------
 SSD Status:   /dev/sdb
...
 Data written:
           MB: 83,410.000
           GB: 81.455
           TB: .079

Edycja 2: Zrobiłem błąd w liczebniku zapisane, był 85,5GB, a miało być 83,5GB, już poprawiłem.

Ostatnio edytowany przez jawojx (2020-02-10 14:35:22)

Jacekalex napisał(-a):

83GB to po moich kombinacjach...

Nawet pomnożenie tych wyników przez 1024 nie odzwierciedliło aktualnej zawartości dysku, dlatego dałem przelicznik x2048.
W ten sposób  jestem w okolicach faktycznego użycia dyzia, a przynajmniej mam taką nadzieję.

Ja nie brałem tej wartości z twojego wyniku ze skryptu, tylko podałem wartość jaką odczytał smartctl (zaokrąglana na bezczelnego) i wniosek jaki nasuwał się z twojego opisu. Fragment z twojego wyniku.

241 Total_LBAs_Written      0x0032   100   100   000    Old_age   Always       -       83409

Moim zdaniem, jeżeli jesteś przekonany że zapisałeś około 80GB danych, to u ciebie nic nie trzeba przeliczać i wartość Total_LBAs_Written wtedy, byłaby podana MB (tak jak pisałem to wcześniej). Niektóre dyski tak właśnie mają, a inne rożnie/inaczej, jak choćby podany przeze mnie przykład z samsungiem (sektory). A jak jest u ciebie, a jak się mylisz z tymi 80GB zapisanych, to wartość 83409 może oznaczać całkiem co innego. Pewnie można gdzieś znaleźć jakąś dokumentacje od Toshiby z tymi informacjami, tylko szkoda czasu na szukanie, a najszybciej i najprościej sprawdzić przez test z dd.

Co do 4000 godzin w rok i 83,5GB zapisu, to na podstawowy/systemowy trochę mało, te  83.5GB w rok*. I nie dowiemy się czy to jest prawidłowa wartość, bez jakiegoś testu. I trzeba było to sprawdzić tak jak opisałem, dla upewnienia się. Przecież można użyć mniejszej ilości danych niż 500MB, może 50MB. (Wcześniej sprawdź, czy coś nie zapisuje na dysku, to wynik będzie dokładny w 100% i znajdzie się jak liczy.)

dd if=/dev/zero of=test_LBAs bs=50MB count=1

Bo inaczej to takie celowanie z mnożnikiem x2048, gdzie twój dysk ma sektory o wielkości 512B, to dlaczego 2048. Przecież nie wiadomo, czy się nie pomyliłeś, z tym szacowaniem zapisu. Fragment z twojego wyniku smartctl.

Sector Size:      512 bytes logical/physical

*Ja w rok mam znacznie więcej niż 1,5TB zapasu na dysku (przy wrzuceniu wszystkiego w ramdysk, razem z tmp, przerzucam czasami duże ilości danych nie ma co pisać, że to się bierze z niczego), ale na niektórych mniej, to nic nie znaczy.

Ostatnio edytowany przez jawojx (2020-02-10 20:38:10)

Jeżeli przyjąć że jest to prawda i miejsce /ssdtmp jest na tym SSD (nie ma powodów bym myślał że jest gdzie indziej, dla ścisłości o tym wspomniałem), to jeden punkt Total_LBAs_Written ma około 25MB, nie można było okrągłej setki zrobić, tylko 128MB :), to z tego wynika że masz zapisane od początku, na tym SSD około 2TB (i to jest bliżej prawdy, niż 83,5GB)*. No musisz to obserwować, by potwierdzić uściślić ten parametr, a może coś tam sobie jakieś cache zrobiło (Windows 10 plik stronicowania, taki żart, wiem że nie masz Windowsa tam).

A tak poważnie to jest wciąż mały procent w stosunku do żywotności gwarantowanej przez producenta i wcale nie jest to dużo (najlepiej pytać kogoś kto ma Windowsa 10), a 83,5GB zapisu przez rok, to było ekstremalnie mało. Ale nie zmienia to faktu że producenci utrudniają znalezienie informacji, o niektórych atrybutach smart.

Ostatnio edytowany przez jawojx (2020-02-10 23:21:45)

Jacekalex napisał(-a):

Chodzi grzecznie niecały roczek, przepracował już ponad 40000 godzin…

A to bardzo ciekawe :D

Sprawdź jeszcze takie wyniki:

smartctl -l devstat /dev/sdb

Masz tu podany stopień zużycia dysku:

0x07  0x008  1               3  ---  Percentage Used Endurance Indicator

Percentage Used Endurance Indicator – This statistic counts increases from 0 to 100, and may even go beyond 100 for drives that exceed their expected lifetime. A value of 0 indicates a new device, whereas 100 indicates that the device is at the end of its lifespan as projected by the manufacturer. The value can reach a value of 255.

https://campus.barracuda.com/product/nextgenfirewal … dware-models/

Dla pewności trzeba by w dokumentacji producenta dysku sprawdzić, które (i jak) wyniki SMART należy interpretować.

Przykładowo dla mojego Intela kluczowy jest:

Media Wearout Indicator – This attribute reports the number of cycles the NAND media has undergone. The normalized value declines in a linear fashion from 100 to 1 as the average erase cycle count increases from 0 to the maximum rated cycles. When the normalized value reaches 1, the number will not decrease. However, it is likely that significant additional wear can be put on the device.

233 Media_Wearout_Indicator 0x0032   099   099   000    Old_age   Always

czyli bardzo dobrze.

3% z 60TB to 1.8TB, czyli mniej więcej tyle co wyliczył jawojx:

jawojx napisał(-a):

jeden punkt Total_LBAs_Written ma około 25MB, nie można było okrągłej setki zrobić, tylko 128MB :), to z tego wynika że masz zapisane od początku, na tym SSD około 2TB (i to jest bliżej prawdy, niż 83,5GB

Wynik 83GB byłby zupełnie nierealny dla baz danych, 3 systemów etc. i ok. 10 miesięcy.

Taka sugestia, wynikająca z nowych informacji.

Tamte wyniki były mało precyzyjne, bo i dane wyjściowe mało precyzyjne, przez to źle dobrane i zaokrąglone. Liczenie z "zaokrąglonego" procenta (nie ma wartości ułamkowej), też są mało dokładne przy dużych liczbach, bo może to jest 3,9%, a nie 3.1% (nie wiadomo jak producent uściśla ten procent, dla informacji o zużyciu może mało istotny ułamek, ale dla wiedzy spory).

Ale teraz mamy wynik zapisanych danych, co do sektora.

Kod:

0x01  0x018  6      5507396474  ---  Logical Sectors Written

Niestety w niektórych dyskach będzie info tylko o procentowym zużyciu (czasami odbiegające od rzeczywistego procenta zużycia), a w niektórych nie będzie żadnej informacji podawanej z smartctl -l devstat. A w jeszcze innych, to będą wartości równe i tu, i w Total_LBAs_Written będą to zapisane sektory.

I z tego możemy wyznaczyć jednostkę Total_LBAs_Written precyzyjniej niż wcześniej i przy tych informacjach już najdokładniej jak można.

Mając wyniki ilości zapisanych sektorów, Sector Size SSD i wartość atrybutu Total_LBAs_Written, można wyliczyć wielkość jednostki tego drugiego, dzieląc wynik zapisanych danych tu w MiB, wartość z Logical Sectors Written*512*2^-20, przez wartość z Total_LBAs_Written, powinno dać wynik u ciebie około 32MiB. I te 32 by pasowało, bo ja nigdzie nie widziałem przelicznika 25MB w Total_LBAs_Written, ale przecież nie widziałem wszystkiego. Na tych danych co mamy, wyglądało by to tak.

5507396474*512*2^-20/84036=32

Czyli jednostka w Total_LBAs_Written odpowiada 32MiB. I w zasadzie tyle, ale można sprecyzować i sprawdzić dalej dokładnie że, to

dd if=/dev/zero of=test_LBAs bs=32M count=1

utworzy nam plik o wielkości 33554432 bajtów (34 MB, 32 MiB). Aby być precyzyjnym, i nie mieć nieścisłości w wynikach, będziemy używać informatycznego przedrostka binarnego, a nie dziesiętnego. Czyli, dla przykładu, przeliczać z bajtów na "dwójkowy" MiB, tak.

33554432*2^-20=32

I tamten przykład z dd test_LBAs powinien zapisać 65536 sektorów (przy wielkości sektora 512B jak jest u ciebie). Dowód (sprawdziłem też, nie tylko liczyłem):

33554432/512=65536

i jeżeli taki jest wynik zapisanych sektorów (zmiany powinny być widoczne od razu, czasami tylko bywa tak, że uaktualniane są dopiero z opóźnieniem po 1-3s), to u ciebie jednostka w Total_LBAs_Written odpowiada 33554432B = 32MiB (czyli taka sama jak przy pierwszym obliczaniu) i wartość atrybutu 241 powiększy się po tym o jeden.

To według tych nowych danych z 5507396474 Logical Sectors Written, na tym dysku, jest zapisanych w przeliczaniu na TB.

5507396474*512*2^-40=2,564581332

Czyli masz dokładnie 2,564TB zapisane. A przy wartości 5507396474 zapisanych sektorów i przy wartości jednostki w Total_LBAs_Written odpowiadającemu 32MiB, wynik w atrybucje smart Total_LBAs_Written powinien wynosić.

(5507396474*512*2^-20)/32=84036,201080322

Czyli, Total_LBAs_Written wtedy było o wartości 84036. To daje już wyniki z maksymalną dokładnością.

Ostatnio edytowany przez jawojx (2020-02-12 19:12:14)

Mnie interesuje tylko, żeby dożył tego 60TBW.
Jeśli teraz mam w okolicy 2 TBW, to 30x10 miechów, to dużo więcej, niż ten dysk przetrwa i dużo więcej, niż moje oczekiwania, bylem tylko ciekaw, czy nie psuje się za szybko.

Producent daje do niego program SSDUTILITY, ale to jakaś spartolona binarka, która się wywala z segfaultem w sekundę po uruchomieniu. Tak właśnie wygląda ta tajna, kosmiczna technologia producentów. :P

Dokumentacji technicznej tego dyzia, w kontekście jego atrybutów SMART nie ma chyba nawet NSA.

Następny dysk kupię wyłącznie po konsultacji z bazą Smartmontools.

Ostatnio edytowany przez Jacekalex (2020-02-12 20:46:15)

Z opisu na stronie Toshiby.
W instrukcji też była tak uwaga w warunkach gwarancji.
Żadnego parametru SMART w tej gwarancji nie widziałem.

javox napisał(-a):

i jeżeli taki jest wynik zapisanych sektorów (zmiany powinny być widoczne od razu, czasami tylko bywa tak, że uaktualniane są dopiero z opóźnieniem po 1-3s), to u ciebie jednostka w Total_LBAs_Written odpowiada 33554432B = 32MiB (czyli taka sama jak przy pierwszym obliczaniu) i wartość atrybutu 241 powiększy się po tym o jeden.

# root ~> egrep '^LBA_SIZE' `which ssdlife`
LBA_SIZE=33554432

# root ~> ssdlife
------------------------------
 SSD Status:   /dev/sdb
------------------------------
 On time:      4,057 hr
------------------------------
 Data written:
           MBW: 2,706,208.000
           GBW: 2,642.781
           TBW: 2.580
------------------------------
 Mean write rate:
        MB/hr: 667.046
------------------------------
Zużycie dysku - zapis - zostało jeszcze:  95.70%
Dyziowi zostało jeszcze: 97% życia 
------------------------------

Może być, z ale tym razem zużycie dysku wynikające z wyczerpania TBW znacząco wyprzedza parametr "Percentage Used Endurance Indicator".

Poza tym przy takich rachunkach absurdalna jest wartość zapisu MB/hr, 10MB na minutę na pewno na dyzia nie trafia, większość logów idzie na kolejki /dev/{syslog,authlog,mess,maillog} a nie na dysk.
Aktualizacje systemowe robię raz na tydzień, home jest gdzie indziej, z baz SQL korzysta na razie Spamassasiin (filtrów bayesa nie używam), quiterss, postfix i dovecot, w niewielkim stopniu KDE.

# root ~> file  /dev/{syslog,authlog,mess,maillog}
/dev/syslog:  fifo (named pipe)
/dev/authlog: fifo (named pipe)
/dev/mess:    fifo (named pipe)
/dev/maillog: fifo (named pipe)

Wygląda na to, że z precyzją danych SMART się Toshiba nie popisała.

Ostatnio edytowany przez Jacekalex (2020-02-12 23:36:13)

Poza bazami danych, kilkoma logami, Portage na SSD zapisywać może tylko Quiterss.
FF, Chrome i Thuderbird nic tam nie zapisują bo po prostu nie mogą, zapisują w /home a home jest na innym dyziu.

Rsyslog zapisuje tam auth.log i kern.log, reszta idzie na named.pipe i omija dyski.

W każdym razie, jeśli dwoma niezależnymi metodami ustaliłem zużycie dyzia na jakieś 3-4,5%,
to dokładnie takich informacji poszukiwałem.

Dlatego od dłuższego czasu tam tam na górze ma takie tajemnicze słówko SOLVED. :P

Dzięki za wyczerpujący wykład.

Aktualny status pacjenta:

------------------------------
 SSD Status:   /dev/sdb
------------------------------
 On time:      4,079 hr
------------------------------
 Data written:
           MBW: 2,726,304.000
           GBW: 2,662.406
           TBW: 2.600
------------------------------
 Mean write rate:
        MB/hr: 668.375
------------------------------------------------
Zużycie dysku - zapis - zostało jeszcze:  95.67%
Dyziowi zostało jeszcze: 97% życia 
------------------------------------------------

Pozdro

Ostatnio edytowany przez Jacekalex (2020-02-13 22:13:33)