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

do góry

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

do góry

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

do góry

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

do góry

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

do góry

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.

do góry

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

do góry

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.

do góry

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

do góry

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

do góry