Dotaz: Rozbíjí se souborový systém na jednom disku

[T.O.M.]

Mám malý komp v domácí síti, který slouží jako firewall, DHCP server, síťové úložiště, web/dlna/torrent server, atd. Vše nastavené podle doporučení na Arch wiki.

Čas od času mi datový disk s ext4, který používám jako síťové úložiště přes NFS, začne házet chyby (viz. logy níže). Ze začátku jsem si říkal, že to mohlo být výpadkem napájení, ale ani s UPS to nepřestalo, nebo že je to špatným nastavením NFS, vadným SATA kabelem, odcházející zakladní deskou, atd. Časem jsem točivý disk vyměnil za SSD, motherboard, zdroj i datový kabel za jiný. Nic nepomohlo.

Když problém nastane, stačí ve fstab zakomentovat montovaní toho disku, reboot, FS opravit pomocí fsck, znovu namontovat a jede se dál. Opakované testy neodhalily žádné vadné bloky. Když to bylo párkrát do roka, dalo se to přežít. Teď se to už děje i několikrát týdně.

Jsem naprosto v koncích a nevím, co dál vyzkoušet nebo zkontrolovat. Nějaké nápady?

/etc/fstab na serveru:

UUID=c8260cc9-5c7c-448a-948f-ec520ddb0f1f   /mnt/data   ext4   rw,noatime,nodiratime,discard,errors=remount-ro   0 2

/etc/fstab na desktopu:

server:/   /mnt/data-server   nfs4   defaults,_netdev,noatime,users,exec,noauto,x-systemd.automount,rsize=32768,wsize=32768   0 0

Relevantní dmesg logy:

ata4: SATA max UDMA/133 cmd 0x20a0 ctl 0x20d8 bmdma 0x2078 irq 19
...
ata4.00: SATA link down (SStatus 0 SControl 300)
ata4.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata4.01: ATA-9: Apacer AS350 1TB, H190117H, max UDMA/133
ata4.01: 2000409264 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata4.01: configured for UDMA/133
...
sd 3:0:1:0: [sdc] 2000409264 512-byte logical blocks: (1.02 TB/954 GiB)
sd 3:0:1:0: [sdc] Write Protect is off
sd 3:0:1:0: [sdc] Mode Sense: 00 3a 00 00
sd 3:0:1:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sdc: sdc1
sd 3:0:1:0: [sdc] Attached SCSI disk
...
EXT4-fs (sdc1): mounted filesystem with ordered data mode. Opts: discard,errors=remount-ro. Quota mode: none.
...
ata4.00: link is slow to respond, please be patient (ready=-19)
ata4.00: SRST failed (errno=-16)
ata4.00: link is slow to respond, please be patient (ready=-19)
ata4.00: SRST failed (errno=-16)
ata4.00: link is slow to respond, please be patient (ready=-19)
ata4.00: SRST failed (errno=-16)
ata4.01: limiting SATA link speed to 1.5 Gbps
ata4.00: SRST failed (errno=-16)
ata4.00: reset failed, giving up
ata4.01: disabled
sd 3:0:1:0: [sdc] tag#0 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=91s
sd 3:0:1:0: [sdc] tag#0 CDB: Write(10) 2a 00 00 00 0b 20 00 00 08 00
blk_update_request: I/O error, dev sdc, sector 2848 op 0x1:(WRITE) flags 0x103000 phys_seg 1 prio class 0
Buffer I/O error on dev sdc1, logical block 100, lost async page write
sd 3:0:1:0: [sdc] tag#0 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s
sd 3:0:1:0: [sdc] tag#0 CDB: Write(10) 2a 00 63 40 08 38 00 00 08 00
blk_update_request: I/O error, dev sdc, sector 1665140792 op 0x1:(WRITE) flags 0x103000 phys_seg 1 prio class 0
Buffer I/O error on dev sdc1, logical block 208142343, lost async page write
sd 3:0:1:0: [sdc] tag#0 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s
sd 3:0:1:0: [sdc] tag#0 CDB: Write(10) 2a 00 63 40 08 80 00 00 08 00
blk_update_request: I/O error, dev sdc, sector 1665140864 op 0x1:(WRITE) flags 0x103000 phys_seg 1 prio class 0
Buffer I/O error on dev sdc1, logical block 208142352, lost async page write
sd 3:0:1:0: [sdc] tag#0 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s
sd 3:0:1:0: [sdc] tag#0 CDB: Write(10) 2a 00 63 40 09 00 00 00 08 00
blk_update_request: I/O error, dev sdc, sector 1665140992 op 0x1:(WRITE) flags 0x103000 phys_seg 1 prio class 0
Buffer I/O error on dev sdc1, logical block 208142368, lost async page write
sd 3:0:1:0: [sdc] tag#0 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s
sd 3:0:1:0: [sdc] tag#0 CDB: Write(10) 2a 00 63 40 0a 08 00 00 08 00
blk_update_request: I/O error, dev sdc, sector 1665141256 op 0x1:(WRITE) flags 0x103000 phys_seg 1 prio class 0
Buffer I/O error on dev sdc1, logical block 208142401, lost async page write
sd 3:0:1:0: [sdc] tag#0 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s
sd 3:0:1:0: [sdc] tag#0 CDB: Write(10) 2a 00 63 41 09 00 00 00 08 00
blk_update_request: I/O error, dev sdc, sector 1665206528 op 0x1:(WRITE) flags 0x103000 phys_seg 1 prio class 0
Buffer I/O error on dev sdc1, logical block 208150560, lost async page write
EXT4-fs error (device sdc1): ext4_check_bdev_write_error:215: comm nfsd: Error while async write back metadata
Aborting journal on device sdc1-8.
sd 3:0:1:0: [sdc] tag#0 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s
sd 3:0:1:0: [sdc] tag#0 CDB: Write(10) 2a 00 3b 84 08 00 00 00 08 00
blk_update_request: I/O error, dev sdc, sector 998508544 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
blk_update_request: I/O error, dev sdc, sector 998508544 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
Buffer I/O error on dev sdc1, logical block 124813312, lost sync page write
JBD2: Error -5 detected when updating journal superblock for sdc1-8.
sd 3:0:1:0: [sdc] tag#0 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s
sd 3:0:1:0: [sdc] tag#0 CDB: Write(10) 2a 00 00 00 08 00 00 00 08 00
blk_update_request: I/O error, dev sdc, sector 2048 op 0x1:(WRITE) flags 0x3800 phys_seg 1 prio class 0
blk_update_request: I/O error, dev sdc, sector 2048 op 0x1:(WRITE) flags 0x3800 phys_seg 1 prio class 0
Buffer I/O error on dev sdc1, logical block 0, lost sync page write
EXT4-fs (sdc1): I/O error while writing superblock
EXT4-fs (sdc1): Remounting filesystem read-only
EXT4-fs error (device sdc1) in ext4_delete_entry:2656: Journal has aborted

Odpovědi

[Kit]

Zkontroluj RAM a případně ji vyměň. Případně to může být způsobeno vadnou základovou deskou.

[T.O.M.]

RAM jsem taky testoval, vše OK. V podstatě jsem disk strčil do úplně jiného kompu, zůstala jen skříň. Právě to mi hlava nebere, dělá to to samé s dvěma různými datovými disky, ve dvou různých HW konfiguracích.

Systémový disk s OS a /home se nikdy nerozsypal, takže mám spíš podezření na SW problém. Teď ještě zkouším NFS nahradit za SSH-FS, abych aspoň jednu proměnnou vyřadil, ale je to na dlouho...

[ewew]

Pozeral si čo píše smart diskov ?

Máš zoznam komponentov, ktoré tam máš použité ? Ide o to či nie je známy problém daného komponentu. Podľa logov je tam problém s softvérovým resetom disku ale na ata4.00. Nevieme či je tam nejaký disk, vp prípade, že ano, tak ten disk má nejaký problém a hw sa snaží disk znovu pripojiť čo sa mu nepodari. Možné je, že neodpovedajúci disk spôsobi zvlášntny stav na radiči a prepne na SATA1 až nakoniec disk odpoji. Následne sú tam chyby komunikácie medzi diskom a systémom. Po vykonaní stanoveného počtu pokusov a zápis súborový systém ohlasí chyby. Podľa fstabu máš nastavené aby pri chybe fs prešiel do režimu len čítanie.

Ešte môžeš otestovať RAM s memtester. Je to nástroj na testovanie RAM priamo z distribúcie. Takže nie je nutné system odstaviť. Jedine čo to potrebuje je spustenie s právami roota. Nevýhoda je, že je nutné dávať pozor aby testovaný region nebol príliš veľky čím by ohrozil činnosť systému do bodu nepoužiteľnosti.

[T.O.M.]

Seznam komponent bych mohl udělat, ale přes 8 let jsem je bez problémů používal jako desktop. ata4 odpovídá /dev/sdc, což je ten datový disk s jediným oddílem.

smartctl neukazoval žádné chyby, ale už jsem ho nějakou chvíli nepouštěl. Naopak jsem teď opět spustil read-only bad blocks test (e2fsck -vck /dev/sdc1) a po necelé hodině už hlásí 50 chyb při čtení

V tom případě musím přeformulovat otázku: co může způsobit bad blocks stejně u točivého disku i SSD, který sice běží 24/7, ale je většinu času idle a převážně se z něj jen čte? Tzn. žádné GB přepisu denně ani neustálé zápisy malých bloků...

[Heron]

V tom případě musím přeformulovat otázku: co může způsobit bad blocks stejně u točivého disku i SSD, který sice běží 24/7, ale je většinu času idle a převážně se z něj jen čte?

Pokud to chápu správně, tak ten točivý disk je ten SAMSUNG HD103SJ z roku 2011? Tam bych spíš viděl jako zázrak, že ještě funguje. Dva mám ještě ve skříni a z ostatních mám magnety a plotny na ozdobu jako podtácek.

Tj ano, klidně se může stát, že ten rotačák odchází stářím (už dávno k tomu má nárok) a prostě jsi měl smůlu a koupil vadný kus ssd.

[Petr Šobáň]

Zdroj?

Kdysi mi taky kolaboval náhodně HDD a nic jsem nenašel až po delším pátrání vyměněn zdroj a od té doby OK.

[Andrej]

Co hlásí ECC? Nic? Ani jedna neopravitelná chyba či restart kvůli chybám?

(Nemáš snad stroj s úložištěm bez ECC, že ne…?)

Dál bych doporučoval nikde nepoužívat Ext4. Ne že by to s tímhle problémem nutně souviselo, ale zkrátka z principu: Souborový systém (v podstatě) z 20. století, navržený pro disky velikosti jednotek GB, nepatří do 20. let 21. století na disky velikosti TB.

Důležitou výhodou moderního souborového systému s checksumy dat i metadat je, že v případě problémů s hardwarem selže rychle, včas, co nejdřív, než se poškodí data.

S Ext4 teď už nemáš žádnou jistotu, že data (někde tu a tam, třeba uprostřed velkých souborů) nejsou kontaminovaná něčím zcela náhodným. Dokonce bych řekl, že po několika takových incidentech už máš téměř jistotu, že data někde poškozená budou.

[T.O.M.]

Samozřejmě že mám stroj s úložištěm bez ECC Sice tomu říkám server, ale to jen proto, že mi nestojí na stole a běží 24/7.

Navíc je to na staré ITX desce, data jsou na jednom disku, žádný raid a zálohy dělám ručně párkrát do roka a to teprve několik posledních let, co se problém objevil poprvé. Vše je zavřené na chodbě v dřevěné skříni u stropu s větrací mřížkou dole a vepředu, kde je průměrná teplota asi 40˚C...

Znáš tu o kovářovic kobyle...

Ext4 používám, protože s tím mám dlouhodobé zkušenosti, včetně řešení podobných problémů, a jednoduše nemám čas a vlastně ani chuť zkoušet něco novějšího a tím ještě zvyšovat pravděpodobnost ztráty dat kvůli mojí neznalosti.

[Kit]

S problémem dřevěné skříňky jsem se už setkal. Špatné chlazení.

Chyby se projevují jen v létě nebo i v zimě?

[T.O.M.]

Projevují se bez ohledu na roční období. Podle sensors je teplota CPU i dalších komponent celoročně stejná. Jen UPS to fakt nesedělo a baterka nevydržela ani 2 roky, tak jsem ji zatím odstavil. Chystám se přidat nějaký větrák, který by hnal teplý vzduch ven, ale zatím přemýšlím nad uchycením.

No, koupil jsem nový disk, většinu dat obnovil ze zálohy, zbytek se po opakovaném nátlaku podařilo vyčíst z vadného disku. Snad vydrží déle než předchozí (něco málo přes rok).

[Tom K]

Jaká je teplota disku podle hddtemp?
Jestli je ve skříni 40, tak ten disk může mít přes 50 a to už je dlouhodobě moc.

[T.O.M.]

Po včerejším nátlaku jsem nějak dostal disk to stavu, kdy jsem z něj vyčetl skoro 400GB, která jsem ani zachránit neplánoval. A stále nevyskočila jediná chyba v dmesg. Před tím stačilo jen otevřít malý textový soubor nebo zapnout zobrazení skrytých souborů.

Sensors ukazuje na CPU 40˚C a SYSTIN 37˚C. Skutečnou teplotu jsem odhadoval z těchto hodnot, rtuťový teploměr teď říká, že v horní části skříně je "jen" 32˚C. Disky jsou vespod. Digitální teploměr ukazuje na povrchu všech disků asi 33˚C. Hddtemp říká tohle:

$ sudo hddtemp /dev/sda  # SSD se systémem
/dev/sda: ADATA SX900: 36°C
$ sudo hddtemp /dev/sdb  # Původní datové HDD, teď jedna ze záloh
/dev/sdb: SAMSUNG HD103SJ: 32°C
$ sudo hddtemp /dev/sdc  # Problémové SSD
/dev/sdc: Apacer AS350 1TB: 48°C

48˚C mi přijde dost vzhledem k tomu, že teď jen visí na kabelech mimo case a na omak tolik určitě nemá. Pokud je tato teplota pravdivá, viděl bych to na nějaký HW problém uvnitř disku...

[michal]

Cau, mal som podobny problem s novym (asi) vadnym diskom - 2.5" barracuda 2TB (ST2000LM 015-2E8174), vyreklamoval som ho

2019-10-30T07:36:35+01:00 ds kernel: [ 3104.283624] ata1: hard resetting link
2019-10-30T07:36:40+01:00 ds kernel: [ 3109.669993] ata1: link is slow to respond, please be patient (ready=0)
2019-10-30T07:36:45+01:00 ds kernel: [ 3114.469995] ata1: softreset failed (device not ready)
2019-10-30T07:36:45+01:00 ds kernel: [ 3114.475096] ata1: SRST fail, set srst fail flag
2019-10-30T07:36:45+01:00 ds kernel: [ 3114.479660] ata1: hard resetting link
2019-10-30T07:36:50+01:00 ds kernel: [ 3119.870009] ata1: link is slow to respond, please be patient (ready=0)
2019-10-30T07:36:54+01:00 ds kernel: [ 3123.910075] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
2019-10-30T07:36:54+01:00 ds kernel: [ 3123.916403] ata1: link reset sucessfully clear error flags
2019-10-30T07:36:55+01:00 ds kernel: [ 3124.840007] ata1.00: device reported invalid CHS sector 0

mozno to slo spravit aj inac, este v diskusii nepadlo slovo "jumper", podla errno=-16 som nasiel https://forums.opensuse.org/showthread.php/454214-SOLVED-ata1-SRST-failed-(errno-16)-boot-extremely-slow-BIOS-disappears

[T.O.M.]

Můj disk je SATA SSD bez jumperů, takže tím to nebude.

[Heron]

Podle toho výpisu to vypadá na vadný kabel / řadič / elektroniku disku. Pokud se poškozují disky ve stejném sata konektoru, tak to bude chyba tam.

Jinak dej sem ještě výpis smartctl -a /dev/sdX. Je to ssd, takže pouštět smart testy netřeba, jinak na tom vadném rotačáku můžeš pustit long test smartctl -t long /dev/sdX (a potom výsledek v smartctl -a). Pokud možno to provádět na zdravém HW, ne v tom záhadném kompu.

Jinak, co má být cílem? Za každou cenu to udržet při životě? SAMSUNG HD103SJ to je tak rok 2011 (ano vím, že to není ten vadný disk, ale spíš mi jde o stáří ostatních komponent). Už jsem se setkal i s tím, že nějak záhadně probíjela bedna (od stíněného neuzemněného STP kabelu) a vracelo se to přes komponenty do zdroje.

Z diskuse jsem pochopil, že jsi vyměnil MB, zdroj, i disky. Pojďme na to opačně, co tam teda zůstalo? Předpokládám i OS. Pokud bych měl chyby hledat tam, tak bych si tipnul, že něco zapisuje přímo na disk někam, kam mu to nepřísluší. Nezkouší to něco mountovat třeba jako ext2, ještě před mountem jako ext4? Nic nad tím (tj samba, nfs, nebo sshfs) fs přímo poškodit nemůže, to nesahá přímo na disk.

Když problém nastane, stačí ve fstab zakomentovat montovaní toho disku, reboot, FS opravit pomocí fsck, znovu namontovat a jede se dál.

Co tohle přesně znamená? Disk máš v fstabu, když se rozbije, tak jakým způsobem potom zakomentuješ fstab? Většina dister se chová tak, že pokud je to rootfs, tak bootování ukončí nějakou "rescue" konzolí, očekává heslo roota a potom přejde do single user režimu (v podstatě bash, žádné služby, žádná síť). A rootfs zůstává readonly - pro ruční kontrolu adminem. Pokud selže mount ostatních fs, tak boot pokračuje dál a čeká se na timeout jednotlivých služeb, které na tom fs závisejí (v systemd). Tj tady se za příslušný čas potom dá přihlásit na ssh a pořešit fsck rovnou. Úprava fstabu není potřeba.

Jinak to, že jsou dva různé disky po sobě vadné se občas stane. Občas si tuhle kartu vybereme každý z nás. Tj pokud je to v záruce, tak bych to reklamoval a vyzkoušel s novým kusem.

[T.O.M.]

Máš pravdu, točivej disk mám asi 10 let a do loňského jara byl bezproblémový. Dokonce je možné, že problémy s ním byly spíš kvůli výpadkům napájení díky "upečenému" akumulátoru v UPS (kvůli vyšší teplotě okolí). Tak jako tak jsem si loni koupil nový desktop a ze starého udělal "server". Tzn. z původního serveru nezbylo nic kromě bedny a točivého disku. Ten tam mám už jen do počtu, je plně zastavený a montuju ho ručně jen v nouzi. Kvůli vibracím jsem ho nahradil za SSD, které je po 13 měsících nepoužitelné, takže reklamace. OS je taky čistá instalace.

Cílem této diskuze má být potvrzení nebo vyvrácení, že za problémy není jen chyba HW disku, ale i moje nastavení fstab, NFS, atd. Nějakou dobu jsem třeba používal 'soft' parametr pro NFS mount, o kterém jsem se později dočetl, že může způsobit silent data corruption.

Co tohle přesně znamená?

V rescue konzoli jsem párkrát skončil, nejspíš kvůli výpadku napájení. Root FS je většinou OK. Fstab upravuji právě kvůli dlouhým timeoutům, protože na vadný disk mám ještě několik bind-mountů a na to čeká asi 5 služeb a já nemám nervy čekat dlouhé minuty, jestli/až komp nabootuje nebo ne.

Jinak poslední výpis ze smartctl:

$ sudo smartctl -a /dev/sdc
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.13.7-arch1-1] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model:     Apacer AS350 1TB
Serial Number:    J46680R000112
LU WWN Device Id: 5 000000 000000000
Firmware Version: H190117H
User Capacity:    1,024,209,543,168 bytes [1.02 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:      2.5 inches
TRIM Command:     Available, deterministic, zeroed
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-2 (minor revision not indicated)
SATA Version is:  SATA 3.2, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Sun Aug  8 13:09:26 2021 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00) Offline data collection activity
                                        was never started.
                                        Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever 
                                        been run.
Total time to complete Offline 
data collection:                (   33) seconds.
Offline data collection
capabilities:                    (0x7b) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine 
recommended polling time:        (   2) minutes.
Extended self-test routine
recommended polling time:        (   2) minutes.
Conveyance self-test routine
recommended polling time:        (   2) minutes.
SCT capabilities:              (0x0031) SCT Status supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0013   100   100   050    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0012   100   100   000    Old_age   Always       -       9219
 12 Power_Cycle_Count       0x0012   100   100   000    Old_age   Always       -       31
167 Unknown_Attribute       0x0022   100   100   000    Old_age   Always       -       0
168 Unknown_Attribute       0x0012   100   100   000    Old_age   Always       -       0
169 Unknown_Attribute       0x0013   096   096   010    Pre-fail  Always       -       14680078
171 Unknown_Attribute       0x0032   000   000   000    Old_age   Always       -       0
172 Unknown_Attribute       0x0032   000   000   000    Old_age   Always       -       0
173 Unknown_Attribute       0x0012   200   200   000    Old_age   Always       -       25771048973
175 Program_Fail_Count_Chip 0x0022   070   100   010    Old_age   Always       -       0
177 Wear_Leveling_Count     0x0012   100   100   000    Old_age   Always       -       0
180 Unused_Rsvd_Blk_Cnt_Tot 0x0033   100   100   000    Pre-fail  Always       -       6560
187 Reported_Uncorrect      0x0032   100   000   000    Old_age   Always       -       222
192 Power-Off_Retract_Count 0x0012   100   100   000    Old_age   Always       -       19
194 Temperature_Celsius     0x0022   048   048   000    Old_age   Always       -       48 (Min/Max 48/48)
199 UDMA_CRC_Error_Count    0x0012   100   100   000    Old_age   Always       -       0
206 Unknown_SSD_Attribute   0x0032   200   200   000    Old_age   Always       -       6
207 Unknown_SSD_Attribute   0x0032   200   200   000    Old_age   Always       -       19
208 Unknown_SSD_Attribute   0x0032   200   200   000    Old_age   Always       -       13
209 Unknown_SSD_Attribute   0x0032   200   200   000    Old_age   Always       -       35
210 Unknown_Attribute       0x0032   200   200   000    Old_age   Always       -       46
211 Unknown_Attribute       0x0032   200   200   000    Old_age   Always       -       39
231 Unknown_SSD_Attribute   0x0023   100   100   005    Pre-fail  Always       -       0
241 Total_LBAs_Written      0x0032   100   100   000    Old_age   Always       -       3970
242 Total_LBAs_Read         0x0032   100   100   000    Old_age   Always       -       9611
245 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       0

SMART Error Log Version: 1
ATA Error Count: 34 (device log contains only the most recent five errors)
        CR = Command Register [HEX]
        FR = Features Register [HEX]
        SC = Sector Count Register [HEX]
        SN = Sector Number Register [HEX]
        CL = Cylinder Low Register [HEX]
        CH = Cylinder High Register [HEX]
        DH = Device/Head Register [HEX]
        DC = Device Command Register [HEX]
        ER = Error register [HEX]
        ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 34 occurred at disk power-on lifetime: 9138 hours (380 days + 18 hours)
  When the command that caused the error occurred, the device was in an unknown state.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 08 08 55 a8 ed  Error: UNC 8 sectors at LBA = 0x0da85508 = 229135624

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 08 08 55 a8 ed 80      00:28:16.300  READ DMA
  ec 00 00 00 00 00 a0 80      00:28:16.300  IDENTIFY DEVICE
  ef 03 42 00 00 00 a0 80      00:28:16.300  SET FEATURES [Set transfer mode]
  ec 00 00 00 00 00 a0 80      00:28:16.300  IDENTIFY DEVICE
  c8 00 08 e0 54 a8 ed ff      00:28:15.300  READ DMA

Error 33 occurred at disk power-on lifetime: 9138 hours (380 days + 18 hours)
  When the command that caused the error occurred, the device was in an unknown state.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 08 00 55 a8 ed  Error: UNC 8 sectors at LBA = 0x0da85500 = 229135616

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 08 00 55 a8 ed 80      00:28:13.500  READ DMA
  c8 00 08 f8 54 a8 ed 80      00:28:13.500  READ DMA
  c8 00 08 f0 54 a8 ed 80      00:28:13.400  READ DMA
  c8 00 08 e8 54 a8 ed 80      00:28:13.400  READ DMA
  c8 00 08 e0 54 a8 ed 80      00:28:13.400  READ DMA

Error 32 occurred at disk power-on lifetime: 9138 hours (380 days + 18 hours)
  When the command that caused the error occurred, the device was in an unknown state.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 08 68 ad a7 ed  Error: UNC 8 sectors at LBA = 0x0da7ad68 = 229092712

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 08 68 ad a7 ed 80      00:28:06.000  READ DMA
  c8 00 08 60 ad a7 ed 80      00:28:06.000  READ DMA
  c8 00 08 58 ad a7 ed 80      00:28:06.000  READ DMA
  c8 00 08 50 ad a7 ed 80      00:28:06.000  READ DMA
  c8 00 08 48 ad a7 ed 80      00:28:06.000  READ DMA

Error 31 occurred at disk power-on lifetime: 9138 hours (380 days + 18 hours)
  When the command that caused the error occurred, the device was in an unknown state.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 08 08 1e 75 ed  Error: UNC 8 sectors at LBA = 0x0d751e08 = 225779208

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 08 08 1e 75 ed 80      00:27:37.200  READ DMA
  ec 00 00 00 00 00 a0 80      00:27:37.100  IDENTIFY DEVICE
  ef 03 42 00 00 00 a0 80      00:27:37.100  SET FEATURES [Set transfer mode]
  ec 00 00 00 00 00 a0 80      00:27:37.100  IDENTIFY DEVICE
  c8 00 08 d8 17 74 ed ff      00:27:36.500  READ DMA

Error 30 occurred at disk power-on lifetime: 9138 hours (380 days + 18 hours)
  When the command that caused the error occurred, the device was in an unknown state.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 08 00 1e 75 ed  Error: UNC 8 sectors at LBA = 0x0d751e00 = 225779200

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 08 00 1e 75 ed 80      00:27:35.400  READ DMA
  ec 00 00 00 00 00 a0 80      00:27:35.400  IDENTIFY DEVICE
  ef 03 42 00 00 00 a0 80      00:27:35.300  SET FEATURES [Set transfer mode]
  ec 00 00 00 00 00 a0 80      00:27:35.300  IDENTIFY DEVICE
  c8 00 08 d8 17 74 ed ff      00:27:34.900  READ DMA

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Conveyance offline  Completed without error       00%      3287         -
# 2  Conveyance offline  Completed without error       00%      3245         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

[Heron]

Ten disk má 34 hlášených smart chyb. Takže vyreklamovat.

ATA Error Count: 34 (device log contains only the most recent five errors) - pod tím je seznam dostupných chyb.

Cílem této diskuze má být potvrzení nebo vyvrácení, že za problémy není jen chyba HW disku, ale i moje nastavení fstab, NFS, atd. Nějakou dobu jsem třeba používal 'soft' parametr pro NFS mount, o kterém jsem se později dočetl, že může způsobit silent data corruption.

To ale nezpůsobí poškození FS. Soft může způsobit ztrátu dat v otevřených souborech, pokud spojení na NFS server vypadne. To spojení se drží tak dlouho, dokud se NFS server opět nenahodí. Tohle má (jako všechno) výhody a nevýhody. Pokud se NFS server objeví zpět, tak se prostě pokračuje dál. Pokud ale umře, tak v případě hard mountu, je tento mountpoint prakticky neodpojitelný (lazy, force umount pomůže). Proto se někdy nasazuje soft, ale je zase potřeba zajistit dostupnost NFS serveru. Každopádně, na FS to nemá vliv a na HW pod ním už vůbec ne.

Těžko říct, možná vadný kus, možná není stavěnej na nonstop provoz. Což jako teda není nic z řady pro domácí uživatele, ale provozujem to tak všichni. Já zatím celkem bez problémů Samsungy řady EVO, ale jen na rootfs a počítám s tím, že kdykoliv chcípnou.

Fstab upravuji právě kvůli dlouhým timeoutům, protože na vadný disk mám ještě několik bind-mountů a na to čeká asi 5 služeb a já nemám nervy čekat dlouhé minuty, jestli/až komp nabootuje nebo ne.

Jo, to dává smysl. Už jsem si několikrát říkal, že se musím pokusit o nějaké early ssh, protože standardně je ssh až dost pozdě a čekal x krát 90s se mi taky nechce.

[T.O.M.]

Chtěl jsem disk před reklamací smáznout a měl tak možnost si vyzkoušel destructive read-write test s badblocks. A výsledek? Ani jedna chyba! Tak jsem zkusil non-destructive read-write test pomocí fsck a výsledek byl stejný, což fakt nechápu...

Aspoň že smart chyby zůstaly na disku zalogované, tak jsem zvědavý, jak dopadne reklamace.

[LarryL]

Podle mne jsou ty Smart chyby jen "soft" chyby, které si firmware disku opravil. Proto ti badblocks neukazuje žádné vadné sektory.

[Heron]

Nebo spíš při tom prvním write testu ten disk realokoval vadné bloky jinam (protože z nich už nemusí tahat data a prostě zapsal nová) a tváří se, že se nic neděje. Takhle se chovají i rotační disky, sektor se číst nedá, ale dá se zapsat (je to uvnitř jiný sektor se stejným LBA). Každopádně by to měl zvěčnit ve smart atributech jako realocation (sector / event).

[LarryL]

Ano tou opravou jsem myslel přealokované vadné bloky. Tady řešili něco podobného. smartctl hlásil Smart chyby, ale badblocks nic nenašel. Z odpovědi jsem pochopil, že sektory se asi přealokovaly po spuštění extended testu:

In your case, there's no indication of bad sectors because the extended test was performed (11746 h) after the last error occurred (11706 h). So, you can sleep peacefully. :)

[T.O.M.]

Tak teď jsem z toho jěště víc zmatený. Chápu 'soft' chyby, i když moc nadšený z nich nejsem, protože kdo by chtěl přepisovat disk jakýmkoliv testem, kdykoliv se chyby objeví.

Pořádně jsem teda prozkoumal jednotlivé smart atributy podle wiki:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
187 Reported_Uncorrect      0x0032   100   000   000    Old_age   Always       -       222
192 Power-Off_Retract_Count 0x0012   100   100   000    Old_age   Always       -       19
231 Unknown_SSD_Attribute   0x0023   100   100   005    Pre-fail  Always       -       0

ID 187 - The count of errors that could not be recovered using hardware ECC.

ID 192 - Number of power-off or emergency retract cycles.

ID 231 - Indicates the approximate SSD life left, in terms of program/erase cycles or available reserved blocks. A normalized value of 100 represents a new drive, with a threshold value at 10 indicating a need for replacement. A value of 0 may mean that the drive is operating in read-only mode to allow data recovery.

První dvě ukazují, že tam jsou nějaké chyby, ale poslední, že disk už je v podstatě nepoužitelný, což není pravda, protože na něj můžu zapisovat.

V práci na Windows se mi disk s ext4 vůbec nezobrazil, ani v Device manageru. Přeformátoval jsem ho teda na ntfs a taky nic...

Tak mám vůbec začít řešit reklamaci? Nebo mi ho vrátí, že je v pořádku, protože se 'soft' chyby nepočítají? Každopádně už mu svá data nesvěřím.

[Heron]

Smart se čte jinak. Kdysi jsem o tom něco napsal (ale tohle se týká rotačních disků), ale klidně je možné používat i jiné spolehlivé zdroje.

Žádný z tebou uvedených atributů není důležitý. Tvůj disk hlásí chyby do svého chybového logu a to je podstatné.

To, že se vadné sektory, které nejdou přečíst, "opraví" zápisem (ve skutečnosti náhradou tohoto sektoru za jiný rezervní) je zcela běžná vlastnosti. Rozhodně to ale není tak, že by se vadný disk měl přepisovat, aby byl "v pořádku".

Tahle vlastnost prodlužuje dobu na výměnu disku. Disk má rezervní bloky a ty použije místo vadných. Kdyby byl disk v nějakém chytrém redundantním fs (btrfs), tak data přečte z jiného disku a potom opraví i tu kopii na tom "vadném" disku. Toto je zcela v pořádku, pokud to disk poctivě napíše do Reallocated_Sector_Ct. Osobně vyměňuju disk ve chvíli, kdy tam jsou buď chyby v logu, nebo realokované nebo vadné sektory (viz ten článek). Realokace mi je dává trochu víc času na výměnu disku. Tj pole se nerozpadne hned a vadný disk je ještě nějakou dobu (z rezervy) číst a ukládat data. Zítra se to vymění.

Nikdy jsem neměl s reklamací problém (a to jsem otočil hezkých pár disků). Stačí přiložit výpis ze systémového logu, poukázat na chyby ve smartu, dát výpis chyb fs a projde to.

Nikdo se v obchodě nebude zabývat skutečnou kontrolou těchto chyb. Vůbec se jim to nevyplatí. Oni chtějí odfiltrovat vrácený hw od BFU, který to ani nepozná a možná to jen zkouší. Ale pokud vidí výpis z raidu, tak je to bez řečí. Tohle nemá být návod pro BFU nebo výmluva, oni mají také jenom omezené kapacity na testovaní a pokud jim to někdo takto setřídí, tak je to pro ně výhoda. Stejně to pošlou zpět výrobci.

Každopádně, za reklamaci přece nic nedáš ne? Pravděpodobně ti to vyjde, prachy dobrý.

[vandrovnik]

ID 231 má Value 100, tzn. disk normálně použitelný, neopotřebovaný.

ID 192 nevím

ID 187 bych chápal tak, že 222 sektorů disk nedokázal přečíst, a tak oznámil chybu. Na základě toho bych ho reklamoval, protože co jiného s diskem, který neudrží data, která na něj byla zapsaná.

[Heron]

UUID=c8260cc9-5c7c-448a-948f-ec520ddb0f1f /mnt/data ext4 rw,noatime,nodiratime,discard,errors=remount-ro 0 2

Ještě diskuse k tomu discard. Doporučuje se to tam nemít a místo toho pravidelně volat fstrim.

Tohle doporučení, jak jsem pochopil, vychází s toho, že discard se volá na každý uvolněný blok fs a disky mažou po větších blocích a tyhle malé informace si prostě nezapamatují, takže trim vlastně neprobíhá (pro malé nesouvislé bloky). FStrim jednou za čas vezme informace o veškerých nepoužitých blocích a pošle to disku naráz.

Ano ano, tím opět narážíme na kvalitu HW a implementace funkcí v jejich FW. O NCQ Trim se už snad ani nemá smysl otírat (dnes jsou ty disky na blacklistech a ncq trim se u nich nepoužívá).

Každopádně, není to žádná chyba to tam mít. Předpokládám, že ti tam stejně už běží fstrim.timer, takže se volá oboje (opět, ničemu to nevadí).

[T.O.M.]

Jj, s discard jsem se taky hrál, jak ve fstab, tak s issue_discards pro LVM na root a home FS. Nějak jsem to ale nedotáhl, takže díky za tip na fstrim.timer.

[Pavel 'TIGER' Růžička]

Tak já tu mám SSDéčko (Kingston A400), na kterém se do půl roku totálně rozbil NTFS. Ukazovalo spousty chyb, ale dal jsem jej do jiného stroje a je bez chyb, jen je strašně moc pomalé, třebaže počet zápisů neodpovídá ani mírnému opotřebení. Firmware nejnovější, různé testy bez chyb. Používám jej na nedůležitý přenos dat s vědomím, že může kdykoliv selhat. Do původního stroje jsem dal stejný model, aniž bych cokoliv měnil a ten už tam jede normálně přes dva roky. A pak se v tom vyznejte.