másolás közben ssd írásvédetté válik - miért?

Merevlemezek, vezérlők

Kingston 240GB UV400 SSD, külső usb tokban, másolás közben változó idő után file system read-only hibaüzeneteket kapok. Ha újracsatolom mindne folytatódik, nem írásvédett, de x idő, és megint az.

1 év körüli, keveset volt használva (desktop, "netezős" gépben), formáztam mielőtt most másoltam volna rá, ext4-re. Nem tudom számít-e, lehet volt a netezős gépben használatkor rajta swap.

(Ha számít két xubuntu 16.04.3-as gépen volt tesztelve, egyik live linux volt.)

Mi okozhatja, mi lehet a megoldás?

  • 2809 megtekintés

( Crayon | 2018. 01. 03., sze – 08:29 )

dmesg vagy syslog mit ír? miért remountolja read-only-ra?
Van ennek a toknak külső tápja?
Első tippre a külső tok amivel használod nem tudja elég árammal meghajtani.

dmesg és syslog megnézésre kerül, köszi a tippet, táphiba lehetséges, elővettem a dupla fejű y-kábelt, közben láttam, hogy az volt hozzá gyárilag...a zseniális az, hogy a laptopon 3 usb van, egyikben live linux usb pendrive, másik kettő ezzel lefoglalva, nincs hova másolni :), csak a memória kártyára

Keressél rövid és vastag kábelt! Ha nincs megjelölve az átmérő, akkor a 30-50cm hosszúak általában ilyenek.
Ha az usb port >0,5A-t le tud adni, akkor az Y kábel fele is elég lehet.
A végső megoldás a külső táplálású hub.

Azt írja az adatlap: Power Consumption: 2.515W (MAX) Write
Ez picit nagyobb mint 0,5A.

A gyári kb. ez a 30-50 cm-es, jóval vastagabb, mint a szokásos, y rész bekötve, de hiba újra megjelent. A külső házon van táp lehetőség, nincs kéznél ilyen tápom, de ez még akkor alternatíva.

Kérdés 1: Lehet power management probléma a laptop oldaláról? Töltőn van, alap xubuntu live, csak az "x idő után jelentkező hiba" miatt jutott eszembe.

Kérdés 2: Mi dönti el, hogy vezérlő halál, vagy csak táplálás probléma? Hogy tudom kizárni egyiket-másikat?

Ezek után csak külső táppal lehet eldönteni.

Bár rámérhetnél az USB 5V-ra is terhelt állapotban. Nyilvánvalóan az SSD nem 5V-os alkatrészeket tartalmaz, hanem egy kis kapcsolóüzemű táp allítja elő a saját tápját. Ha az 5V kevesebb, akkor több áramot fog felvenni. Az USB port meg figyeli az áramot és leold, ha soknak találja. Tehát ezt okozhatja a laptop kisebb feszültsége, vagy a precíz áramfigyelés.

Nekem pl. soha nem kellett Y kábelt használnom, mert dedikált 1,5A-es (iPhone töltő!!!) portjaim vannak.

Ökölszabály: Ha hw hiba gyanúja merül fel, akkor annak elhárításáig nem mountolunk!

Némi kersgélés után ez akár kernel hiba is lehet, aminek a forrása pl. az usb/sata bridge.

Itt kellene az usb kergetését abbahagyni, és rendes sata portra dugva low level visgálatot végezni! Utána aká a másolást is el lehet végezni. ;)

De még ezek előtt megkukkantani a smart adatokat, mert az ext4 hibája az néhány szinttel odébb kezdődik.

(Sajnos nem vagyok hardware-es témákban otthon, és maga a hiba egy már mount-olt, dolgozó egységnél jelentkezett, szerencsére nem volt rajta adat, épp költöztem volna rá.)

Közvetlen sata portra kerül most, köszönet a tanácsért! (Már épp raktam volna át a másik usb házba próbaként, nem vagyok toppon úgy látszik.)

$ sudo smartctl -a /dev/sda1
...
SMART Health Status: OK
...

(Szűkszavúság oka gondolom az USB, sata portra kötöm, és folytatom.)

+1

Kíváncsi vagyok, mit tud ma egy Kingston, nekem még V100-as csinált hasonló csúnyaságokat... de rengeteg hulladék usb/sata átalakító van, úgyhogy tényleg előbb azt kéne kiiktatni.

szerk: hdparm-mal lehet, hogy lehet APM-et állítani... elvileg ssd-knél is csökkenti a felvett áramot, legalábbis nekem úgy rémlik, hogy sikerült így usb-re kötött ssd-t stabilabbá tenni.

( _ventura_ v | 2018. 01. 03., sze – 08:30 )

Feltéve ha minden ok, akkor kuka, mivel szerintem annak kampeca.

Nálunk is volt ilyen model talán 200G-s mindkettő hamar kifeküdt.

Fedora 26, Thinkpad x220

( uid_16313 | 2018. 01. 03., sze – 08:52 )

Firmware legfrissebb? Esetleg egy frissítés még segíthet.

--
robyboy

( ncc1701 | 2018. 01. 03., sze – 09:02 )

Kingston ssd, ipari hulladék, döglik a vezérlője. Szék lába alá, ha billeg...

Ezt mire alapozod? Szerintem nem hulladék, erre alapozom: http://i-pont.hu/kings.jpg Ez egy a hétből, amit használok. Mind ilyesmi állapotú. Ez egy hp notebook-ban rendszerlemez win10 alatt, ami napi 8-10 órában szántja. Virtualboxban debian is elfutkorászik a háttérben. Intenzív használatnak van kitéve. A DVD helyén egy Samsung ssd figyel, hasonló jó egészségnek örvendően, pedig az is hasonló intenzitással íródik, olvasódik. http://i-pont.hu/samu.jpg http://i-pont.hu/samu2.jpg

És tudható, hogy mire használjátok? Mert a kérdező sima otthoni használatról ír....és nem mindegy, hogy hogyan hajtogatja az ember...otthonra a kingston és a samu is kiváló...az én kingstonom 2011 óta melegszik a notebookban. Ár-érték arányban jobb, mint a sandisk és ha egy nas is figyel, akkor a mentés is meg van oldva. Ha elkezd így hat év elteltével lerogyni én nem is fogok vele vacakolni, kuka és veszek egy újat. Kb. pár ezres/év áron volt ssd a gépben szar hdd helyett. Gyakorlatilag három éve nullára íródott az értéke, így mondhatni vastagon kerestem is vele. :)

( p2pking | 2018. 01. 03., sze – 10:56 )

Garancia ?
Ha van akkor irany cserelni. Beepitett adatvedelmi reakcio a vesztet erzo ssd eseten.

Ha nem, akkor kuka kukanovics.

Ha utannaolvasol akkor ahogy mar irtak paran, kingston nem a strapabirasarol es stabilitasarol meg a kimagaslo minosegerol hires...

http://karikasostor.hu - Az autentikus zajforrás.

Azóta 2x rápróbáltam még (nem annál a gépnél vagyok amin tudom tesztelni), gyári vastag y kábel mindkét dugóját bekötöttem, így is erre a hibára futott, most találtam egy rövidebb (de sajna vékonyabb) kábelt, ezzel megy épp a tesztelés.

Amit kihagytam, jelezzétek ha probléma lehet: usb2-es laptop, usb3-as külső ház (a vastag y kábel a gyári volt hozzá).

Garancia van, mit érdemes venni helyette? Visszafizetés lesz, vagy kapok egy ugyan ilyent és cseszhetem?

( zitev v | 2018. 01. 03., sze – 13:39 )

+1 kingston=megdeglend'

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

( cherockee v | 2018. 01. 03., sze – 17:09 )

Közben e2fsck futtatásra került, mert a "dmesg | less" azt mutatta, hogy "mounting fs with errors, running e2fsck is recommended". Most futtatom tovább a másolást, várom a hibát.

(Nem csepegtetni akarom a rejtélyt, de lehet fontos: X201-es laptop, töltőn, az SSD-re épp egy szintén usb-n bekötött hdd-ről mennek az adatok, és live linux, ezért a harmadik usb is foglalt. Nap elején lehet kapcsolódik, lehet véletlen, volt egy memóriakártyára másolás ugyan ezen a gépen, a hdd-ről, a memóriakártya megtelt, most az is hibás, már bekötéskor read-only mount-olódik, az ssd viszont nem volt read-only on mount.)

( Raynes v | 2018. 01. 03., sze – 15:55 )

Szerintem dögledezik. A Kinston V-széria nem valami megbízható, szeretnek gyorsan megdögleni. Azért mielőtt leírjuk, írd meg a sudo smartctl -a /dev/meghajtóneve kimenetét, ha nem lenne nálad ilyen, a smartmontools csomagot kell hozzá feltenni.

Felhozta itt valaki a TBW-t. Az lényegtelen, mert az SSD-k elsöprő többségénél nem a cellák szoktak elfáradni, hanem a vezérlő döglik be egy idő után, függetlenül a cellák állapotától. Ez minden SSD-nél bekövetkezik, egyik sem üzemel örökké, csak a kevésbé megbízhatóbbaknál elég gyorsan megtörténik, a strapabíróbbak mennek 6-10 évig is. Megjegyezném, hogy ez a HDD-knél is így van, azoknál is inkább a vezérlő döglik, és nem a bad sectorok terjedése szokott lenni a tipikus halálok, persze az utóbbi is előfordul.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

( cherockee v | 2018. 01. 03., sze – 17:10 )

Azóta két kört futottam még, x idő után megint read-only mountolódik, e2fsck futtatása lehet "helyrehozza" (nem kérdez hibajavításról, nem is igazán látom mit csinál, ha egyáltalán), de lehet csak az újra felcsatolás. Dmesg tartalma:

http://sykth.com/ssd-dmesg-1.txt

Ilyet buffer IO errort bad sectoros meghajtóknál szokott írogatni. Ha még van rá jótállás, futtass egy smartctl-t (lásd előző hsz.-em), és annak a kimenetével küldd vissza. Ha nincs már rá garancia, akkor meg dobd ki, ezen a ponton felesleges bármit futtatni. Ha csak logikai, fájlrendszerbeli hibája lenne, egy fsck már elsőre helyrehozta volna.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

Most ott tartok, hogy fentiekben tanácsoltak szerint kivettem az usb tokból, és azóta tökéletesen működik. Dmesg-ben semmi. Smart adatok PASSED (bővebben: http://sykth.com/ssd-smart.txt), 100 Gb feletti írás történt hiba nélkül, jelenleg fut még egy 100 Gb, előzőleg pár Gb-onként dobta a hibát, sajnos nem kapcsoltam elsőre, hogy akkor zárjunk ki mindent, belső sata csatlakozóra kéne rakni, és ott futtatni. Ha viszont most is hibára futok, akkor nem tudom merre tovább. A történet végét mindenképp dokumentálom, jelen állás szerint az USB külső tok a gyári kábellel nem megfelelően működött, még lehet megpróbálom majd külső táppal, csak az nincs kéznél, és az SSD-t sem akarom tovább tortúráztatni ilyenekkel.

Azt hiszem, már mindent leírtam. Ha van lehetőséged, akkor külső táppal a táplálás elégtelenségét kellene kizárni.
A kernel üzenetek alapján kereshetsz a bugok között, ha inkompatibilitás gyanús a dolog.
Az eddigiek alapján fele-fele arányban hibás a táp vagy a csatoló (a driver miatt).