Dotaz: Nespolehlivé SSD?

[Valoun]

Mám 3 roky staré SSD formátu mSATA z ASUS Xtreamu Ultra a dal jsem ho do noveho Asrock Beeboxu. Po čase mi začal zlobit Openelec/Kodi, který tam je nainstalovaný. A teď problém, který jsem objevil:

OPENELEC dodává systém ve formě souborů KERNEL a SYSTEM a k nim příslušné kontrolní součty KERNEL.md5 a SYSTEM.md5.

Když ty soubory na SSD nahraju, tak mi md5sum KERNEL vrátí správný hash. Ale jakmile SSD odmountuju a zase přimountuju (ani ho nemusím fyzicky vyjmout, nebo vypnout PC), a znovu zkusím md5sum KERNEL, tak už součet nesedí.

Mám z toho vyvozovat že je vadné SSD? fsck.ext4 ani badblocks žádné problémy nenaznačuje. Nebo může být problém i v řadiči, tj. spojení s počítačem? Bohužel nemám jiné mSATA zařízení, abych to vyloučil.

---

---

Odpovědi

[Aleš Kapica]

U SSD jsou chyby obzvláště zákeřné a selhání nepříjemné. A doba vystřízlivění ze superrychlých SSD už ťuká na dveře. Osobně mám v notebootu řadič se dvěma mSATA SSD. Předtím jsem využíval toho, že můžu mít ve svém HP ProBook 6475b místo DVD další SSD disk. Ostatně - to byl i jeden z pádných důvodů proč jsem ten notebook chtěl.

[Valoun]

Tak to asi bude mít to SSD za sebou. Připojil jsem ho přes USB adapter k jinému počítači a zkusil smartctl. A tahle to dopadlo:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x0000   100   100   000    Old_age   Offline      -       0
  5 Reallocated_Sector_Ct   0x0000   100   100   000    Old_age   Offline      -       0
  9 Power_On_Hours          0x0000   100   100   000    Old_age   Offline      -       0
192 Power-Off_Retract_Count 0x0000   100   100   000    Old_age   Offline      -       0
194 Temperature_Celsius     0x0000   100   100   000    Old_age   Offline      -       30
195 Hardware_ECC_Recovered  0x0000   100   100   000    Old_age   Offline      -       0
196 Reallocated_Event_Count 0x0000   100   100   016    Old_age   Offline      -       0
198 Offline_Uncorrectable   0x0000   100   100   050    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0000   100   100   050    Old_age   Offline      -       0
 12 Power_Cycle_Count       0x0000   100   100   000    Old_age   Offline      -       856
241 Total_LBAs_Written      0x0000   100   100   000    Old_age   Offline      -       977658
242 Total_LBAs_Read         0x0000   100   100   000    Old_age   Offline      -       943074
160 Unknown_Attribute       0x0000   100   100   000    Old_age   Offline      -       0
161 Unknown_Attribute       0x0000   100   100   000    Old_age   Offline      -       127
163 Unknown_Attribute       0x0000   100   100   000    Old_age   Offline      -       6
164 Unknown_Attribute       0x0000   100   100   000    Old_age   Offline      -       90358
165 Unknown_Attribute       0x0000   100   100   050    Old_age   Offline      -       117
166 Unknown_Attribute       0x0000   100   100   050    Old_age   Offline      -       88
167 Unknown_Attribute       0x0000   100   100   100    Old_age   Offline  FAILING_NOW 131

Read SMART Log Directory failed: Connection timed out

SMART Error Log not supported

A dmesg mi podezření potvrzuje, SSD selže i při pouhé snaze o čtení SMART dat, jestli to chápu dobře:

[ 3775.047550] usb 1-7: Product: Ext. HDD
[ 3775.047559] usb 1-7: Manufacturer: Innostor
[ 3775.047568] usb 1-7: SerialNumber: 0000020141020
[ 3775.266925] usb-storage 1-7:1.0: USB Mass Storage device detected
[ 3775.267445] scsi host3: usb-storage 1-7:1.0
[ 3776.568359] scsi 3:0:0:0: Direct-Access     Innostor Ext. HDD         0.00 PQ: 0 ANSI: 6
[ 3776.569453] sd 3:0:0:0: Attached scsi generic sg1 type 0
[ 3776.573204] sd 3:0:0:0: [sdb] 62717952 512-byte logical blocks: (32.1 GB/29.9 GiB)
[ 3776.579508] sd 3:0:0:0: [sdb] Write Protect is off
[ 3776.579527] sd 3:0:0:0: [sdb] Mode Sense: 00 00 00 00
[ 3776.580821] sd 3:0:0:0: [sdb] Asking for cache data failed
[ 3776.580838] sd 3:0:0:0: [sdb] Assuming drive cache: write through
[ 3776.591613]  sdb: sdb1 sdb2
[ 3776.597575] sd 3:0:0:0: [sdb] Attached SCSI disk
[ 3777.290445] EXT4-fs (sdb1): recovery complete
[ 3777.292133] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)
[ 3777.497594] EXT4-fs (sdb2): recovery complete
[ 3777.498809] EXT4-fs (sdb2): mounted filesystem with ordered data mode. Opts: (null)

...

spusten smartctl -d sat -a /dev/sdb

...

[ 3876.948248] usb 1-7: reset high-speed USB device number 9 using ehci-pci
[ 3892.060106] usb 1-7: device descriptor read/64, error -110
[ 3907.276110] usb 1-7: device descriptor read/64, error -110
[ 3907.492253] usb 1-7: reset high-speed USB device number 9 using ehci-pci
[ 3922.604250] usb 1-7: device descriptor read/64, error -110
[ 3937.820238] usb 1-7: device descriptor read/64, error -110
[ 3938.036292] usb 1-7: reset high-speed USB device number 9 using ehci-pci
[ 3948.444248] usb 1-7: device not accepting address 9, error -110
[ 3948.556269] usb 1-7: reset high-speed USB device number 9 using ehci-pci
[ 3958.964271] usb 1-7: device not accepting address 9, error -110
[ 3958.964477] usb 1-7: USB disconnect, device number 9
[ 3959.098619] Buffer I/O error on dev sdb1, logical block 81921, lost sync page write
[ 3959.098641] JBD2: Error -5 detected when updating journal superblock for sdb1-8.
[ 3959.098650] Aborting journal on device sdb1-8.
[ 3959.098667] Buffer I/O error on dev sdb1, logical block 81921, lost sync page write
[ 3959.098678] JBD2: Error -5 detected when updating journal superblock for sdb1-8.
[ 3959.160099] usb 1-7: new high-speed USB device number 10 using ehci-pci
[ 3959.228875] Buffer I/O error on dev sdb2, logical block 3702784, lost sync page write
[ 3959.228895] JBD2: Error -5 detected when updating journal superblock for sdb2-8.
[ 3959.228903] Aborting journal on device sdb2-8.
[ 3959.228920] Buffer I/O error on dev sdb2, logical block 3702784, lost sync page write
[ 3959.228932] JBD2: Error -5 detected when updating journal superblock for sdb2-8.
[ 3974.272256] usb 1-7: device descriptor read/64, error -110
[ 3989.488280] usb 1-7: device descriptor read/64, error -110
[ 3989.704290] usb 1-7: new high-speed USB device number 11 using ehci-pci
[ 4004.816105] usb 1-7: device descriptor read/64, error -110
[ 4020.036272] usb 1-7: device descriptor read/64, error -110
[ 4020.252336] usb 1-7: new high-speed USB device number 12 using ehci-pci

Na druhý pokus o výpis už jen smartctl zahlásí:

/dev/sdb failed: No such device

[Petr Šobáň]

USB adaptér vyhoď a připoj ho na přímo k řadiči a pak smartctl......

USB může chybovat a nespolupracovat s SSD!

Jinak samozřejmě že jak ten OS používáš tak už konkrétní součty nebudou sedět na ssd se už něco zase zapíše používáním ne?

[Valoun]

Měl jsem na mysli to, že 2x provedený md5sum hned po sobě neodpovídá, když mezitím provedu umount/mount. Nebootuju z nej ani nic takového (ostatně to řeším práve proto, že kvůli chybě ani nenabootuje, protože se ani nerozbalí jádro komprimované XZ).

Je to úplně stejné, jako kdybych na to SSD nahrál Matrix.avi a udělal nad ním md5sum, umount, mount, md5sum.

Co se USB adaptéru týče jinou možnost nemám (jinou základní desku která by brala mSATA nemám) a s jinými disky v něm jsem problém neměl.

[lertimir]

Asi bych si koupil adapter mSATA-SATA a věřil mu vice než převodníku na USB.

[Valoun]

No já to právě mám připojené přes USB-SATA a SATA-mSATA, ale to jen pro účel té diagnostiky.

Tu chybu s poškozením souboru a nesouhlasícím MD5 hashem mi to dělá i přímo v mSATA portu na základní desce toho Beeboxu, když si tam nabootuju Ubuntu z flashky a pak to zkouším přímo na tom SSD, tedy bez jakéhokoli adaptéru.

[Petr Šobáň]

Chybný součet může dělat i vadná ram.

Takže chybný součet to generuje i na jiném zařízení?

[Valoun]

Příloha:

• MemTest86-Report-20151120-082915.html (17636 bytů)

Tak jsem spustil memtest86 na paměti v Beeboxu a vyšlo mi report, který je v příloze.

1.) našlo se množství chyb (nečekal jsem to, vzhledem k tomu, že mi spolehlivě běhal přes dva měsíce)

2.) V reportu se píše, že nejvyšší nalezená chybová adresa je cca 6143MB, což je u 4GB paměti dost nečekané.

3.) V průběhu testu jsem si zjistil, že se jedná o paměť DDR3 1,5V, kdežto Beebox uvádí, že do něj patří DDR3L, které mají provozní napětí jen 1,35V. Proto možná ty nahodilé chyby. Takže každopádně koupím novou paměť.

S novou pamětí znovu otestuji SSD disk a uvidí se, jinde zatím nezlobil. Každopádně děkuji za nasměrování, paměť jsem nepodezříval.

[Ruda]

Mount ext4 v rw modu ten filesystem zmeni! Proto ti nesedi checksum, zkus pridat k mountu -o ro.

[Ruda]

Jo a pozor ani to read only obcas nezajisti, ze se ext[3|4] nezmeni

[GeorgeWH]

toto som si najprv myslel aj ja, ale ked som si to este raz precital, tak som to pochopil tak, ze pripojil disk, nakopiroval nan nejaky subor a vypocital md5sum, umountol a opat mountol disk, ale md5sum mu uz nesedel. je to aj logicke, pretoze inac by musel pocitat hash zo zariadenia (napr. /dev/sdb), ak by to malo sediet s tym, ako to ty myslis. aleeeeee mozno je to cele uplne inak a jablka rastu na hruske...

[R]

Presne tak, riesi sa tu neexistujuci problem. Okrem "ro" je este vhodne poznat parameter "noload", ten sa hodi pri zachrane dat z poskodeneho disku.

[Valoun]

Reaguji i na předešlé, které nepochopili problém. Nedělám žádné checksumy celých filesystémů, ale jen jediného souboru. Nakopíruju jediný soubor na cílový disk (v tomto případě SSD, ale klidně si představte disketu, jestli to pomůže), pak udělám checksum toho souboru, odmountuju ten disk, hned ho zase přimountuju a znovu udělám checksum toho jediného souboru a součet nesedí.

Musím tomu ještě nějaký čas věnovat hledání příčiny, ale nechci, aby tu ostatní zbytečně ztráceli čas scénaři, o kterých není vůbec řeč.

Možná to takhle bude jasnější, toto je princip mého problému:

mount /dev/sda1 /tmp/sda1
cp SOUBOR /tmp/sda1/
md5sum /tmp/sda1/SOUBOR => asfcbagbafkgcafcg
umount /dev/sda1
mount /dev/sda1 /tmp/sda1
md5sum /tmp/sda1/SOUBOR => gmiklikvdklagndkl

[Andrej]

Na normálním souborovém systému, který má checksumy dat i metadat, se taková věc za dobu trvání vesmíru nemůže stát. Prostě není možné nahrát soubor, mít správný checksum a po odmountování přečíst neplatná data. Souborový systém buď vrátí platná data, nebo ohlásí chybu.

No a pokud člověk nepoužívá Btrfs nebo ZFS, dobře mu tak. K tomu se zkrátka nic jiného poznamenat nedá.

SSD je nespolehlivé médium. Kdo si něco takového koupí a svěří tomu svá data, musí s tím počítat. Zatímco na harddiscích jsou Btrfs nebo ZFS nejlepší volba, na SSD jsou naprostá nezbytnost, bez které se člověk neobejde. Jinak nebude mít nikdy jasno v tom, která data ještě má a která už ne. Není nic horšího než mít nějaká data jen tak „napůl“…

[Valoun]

Děkuji za radu. Fakt je že BTRFS ani ZFS jsem ještě nikdy nepoužil. V tomhle případě mi jde jen o domácí přehrávač k televizi. Na to mám k tomu určený OPENELEC, který primárně používá ext4, nechci nic vymýšlet ani budovat sám, za ten čas mi to nestojí. Žádná data tam nemám, na to mám svůj vlastní server s disky v RAIDU a automatickými zálohami. Ale málokdo má čas a chuť se starat doma o všechny počítače, a ještě k tomu hackovat vlastní přehrávač, mikrovlnku a jánevímcoještě.

Jestli má EXT4 checksumy i na data netuším, v absolutní spolehlivost jakéhokoli media nevěřím. Jen jsem z klasických HDD zvyklý na jiné projevy nespolehlivosti. Takže si prostě ještě nejsem jistý, zda podezřívat SSD, nebo pamět (jak naznačili výše) nebo jít Alze hodit na hlavu Beebox.

[Aleš Kapica]

Jestli je to diskem odzkoušíš tím, že ten disk zkusíš v jiném počítači. Na test paměti je určen memtest, ale některé chyby bývají záludné - kupř. mi se projevovala vada paměti když byly v páru. Je třeba ho nechat běžet delší dobu.

[ewew]

Na normálním souborovém systému, který má checksumy dat i metadat, se taková věc za dobu trvání vesmíru nemůže stát. Prostě není možné nahrát soubor, mít správný checksum a po odmountování přečíst neplatná data. Souborový systém buď vrátí platná data, nebo ohlásí chybu.

Ale stále to podlieha programatorskej chybe.

No a pokud člověk nepoužívá Btrfs nebo ZFS, dobře mu tak. K tomu se zkrátka nic jiného poznamenat nedá.

Potom budeš robiť obnovu dát, keď im to ten dokonaly system zlikviduje. Ďalšia vec je efektivita. Dnes nie je v móde použivať jednoduché riešenie ale prilepiť na niečo obrovsku kopu kódu. Lebo sw staršieho dátumu je odpad.

SSD je nespolehlivé médium. Kdo si něco takového koupí a svěří tomu svá data, musí s tím počítat. Zatímco na harddiscích jsou Btrfs nebo ZFS nejlepší volba, na SSD jsou naprostá nezbytnost, bez které se člověk neobejde. Jinak nebude mít nikdy jasno v tom, která data ještě má a která už ne. Není nic horšího než mít nějaká data jen tak „napůl“…

Toto je výsledok tvorby veľkých dát a ich neefektivnosti.