Új ssd meghalása, adat mentése?

 ( Robika88 | 2017. november 10., péntek - 2:54 )

Sziasztok újra!

Már megint ver az isten... Most a laptopban használt 2 hónapos ssd úgy döntött meghal.
Ami van:
Win10-es rendszerű mbr es telepítés volt aminek a c (ntfs) particiója eldobta magát.
Tele vagyok sok read error-ral.
A lemez elején a segéd boot partició és a D nagyobb meghajtó adatait látom.
A c-n kb. 30 giga össz adat volt op.rendszerestől. (ez a lényeg)
Mentés még nem volt, igen hanyagság, kövezzetek meg. (mondván hátha nem megy tönkre rögtön... de deee :@....)
Adatok: Kingston 480gb - (c:160gb)(d:300gb)

Mondván mi a picsát csináljak, a c részt linux alatt leküldtem a dd_rescue val.
Kérdésem, hogyan tudnám a rajta lévő adatokat valahogy előkaparna ha az image is fos.
Ezer hála.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Most akkor van egy mentett lemezképed?
Akkor GetDataBack for NTFS!

Ha a lemezképből se jön vissza semmi, akkor buktad az adataid.

Orwell az 1984-et regénynek írta és nem használati utasításnak!

+1

+1

+1

gyerekek...beszarok...
reggelre végzett az image analizálás, adatok megvannak. hála isten.

Tanulság, mindenki vonja le:
több programmal ellenőrizve, most a hard disk senti eredményeit íróm
- az összesen 5 napot futot 480gb kingstone ssd 145 hibás szektor. összes írt adat 313gb. kondíció 18%
- egy zsír új 240gb re mentet image már most 6 óra használat alatt (165gb írás) 1 hibás szektort és 99% os kondíciót mond

Hozzáteszem mind a 2 ssd-nek hangja van!!! Enyhe néha magas frekvenciás sípolást hallok.

Átmentem egy újabbra aztán visszaküldöm. Kerüljétek el de messzire. Nem tudom mit mokolnak a gyárba, vagy újra felújítják de hadjanak ki belőle.

Csak a kíváncsiság miatt, pontosan milyen kingston. Tudsz mondani pontosabb típust , P/n -t?

Meg esetleg s/n-t csak hogy tudjuk melyik szeriat kell kerulni, mert nalam valtozatos helyeken es valtozatos kingstonok jo ideje mennek hiba nelkul, a magas sipolo hangot en eddig csak a sajatombol hallottam amikor parhuzamosan nagy sebesseggel ir es olvas

Én a 3 hónapos Samsung 850 PRO SSD-t is hallom ciceregni, amikor leáll a ventillátor, hallani, halkan olyan, mintha egy légy zümmögne messze.
Nem hinném, hogy a táp hibája, mert a laptopban kell legyen egy belső táp is, az ssd nem a 19.5V-ról jár, hanem 5V-ról, elég sok dolog elhullana, ha az a belső táp gyengélkedne.

Nem gyengélkedés, ha cicceg, szimplán nem lettek a tekercsek elég jól "betaknyolva" ragasztóval, vagy rendesen belakkozva. Attól még lehet jó a tápfesz.

Nekem crucial ssd-k vannak es mar tobb TB-os irassal uzemelnek hibatlanul.
A Kingston (foleg a v300-as szeria) hires/hirhedt az anyagkoltsegen valo sporolasrol.
(Gyengebb minosegu es sebessegu NAND etc...)

--

"You can hide a semi truck in 300 lines of code"

Nekem az Intel SSD-k beváltak nagyon, tudom ajánlani. Több is van körülöttem évek óta hibátlanul.

--
Tanya Csenöl az új csatorna

Idézet:
- az összesen 5 napot futot 480gb kingstone ssd 145 hibás szektor. összes írt adat 313gb. kondíció 18%
- egy zsír új 240gb re mentet image már most 6 óra használat alatt (165gb írás) 1 hibás szektort és 99% os kondíciót mond

Remélem, tudod, hogy mennyire végtelen apró az esély, hogy ilyen "dupla" hibásodás megtörténjen? Nem lehet, hogy a tápegységeddel van baj?

Idézet:
Hozzáteszem mind a 2 ssd-nek hangja van!!! Enyhe néha magas frekvenciás sípolást hallok.

Biztosan az SSD-ből jön a magas frekvenciás hang? Nem a tápból?

Idézet:
Kerüljétek el de messzire

Szerintem elég merész dolog két elemű minta alapján ilyen messzemenő következtetést levonni. Az ipon egyik Kingston SSD-re önkéntesen közölt meghibásodási aránya 0.5%. Noha nincs infó arról, hogy frissítik-e ezt az értéket, és ha igen, milyen sűrűn, mégsem gondolom, hogy nagyságrendi eltérés lenne a valóság és az ott közölt adat között.

+1, első gondolatom a PSU
------------------------
{0} ok boto
boto ?

Ez ilyen, ssd halál esetén sok mindent nem olvasol vissza róla. Mentés kell legyen.

Akkor leírom az én tapasztalatomat is:

Nekem régebbi Kingstonom van és már kétszer volt garanciáztatva. Ja és most is 95% health-el megy HDSentinel szerint. Igazából az otthoni médiaszerveremben megy már, az SSD-n csak egy debian meg kodi van szóval ha megadja magát akkor nem fog fájni a fejem miatta. :)

Második gariztatásnál már úgy gondoltam hogy nem kérek többet a Kingstonból. Lehet csak rossz típust fogtam ki, de így már nem tudok további bizalmat adni a cég fele.

KINGSTON SV300S37A a típusa.

Megoldást én sem találtam, sehogy sem tudtam visszaszerezni az adataimat, szóval konklúzióként azt vontam le:
- SSD-n nem tárolok adatot csak rendszert és programokat,
- programok beállításáról Backupot készítek időnként, Windows alatt %appdata% backup. Linuxon meg a home az külön partíción van, és kép készül róla.

SV300 eleg vacak szeria foleg 240GB alatt. Nagyon kerulni kell.

--

"You can hide a semi truck in 300 lines of code"

A jövőben majd kerülöm :(

https://tardis.hu/le/ks_sv300_ssd.jpg

https://hup.hu/cikkek/20140615/a_kingston-t_es_a_pny-t_azon_kaptak_hogy_jo_ertekeles_utan_olcsobb_alkatreszekre_cserelte_ssd-inek_komponenseit

Ez pont a V300-as szeria. A tied meg az elso sorozatbol valo a 2 eves mukodesi ido alapjan.
--

"You can hide a semi truck in 300 lines of code"

Ez legalább a dízelbotránnyal felérő csalás.
A vársárlók tudatos megtévesztése a minimum fő bűncselekmény.
Fura, US-ben ennek az 1000/részéért milliós dolláros kártérítési pereket indítanak.
Macska szárítás microban pl.

$ dmesg | grep KINGSTON
ada0: <KINGSTON SV300S37A60G 505ABBF1> ATA8-ACS SATA 3.x device

2014. márciusában vásároltam, nem tapasztaltam még bajt. Nyilván persze egy minta nem minta, de a teljességhez ez az infó is hozzátartozhat. Persze a lentebbi hozzászólásod szerint ez egy korai sorozat lehet, ami még normálisabb volt. Ha ez tényleg igaz, örülök, hogy jót fogtam ki :)

Nekem is hibátlan, van benne 4844 üzemóra, semmi baja.

Model Family:     SandForce Driven SSDs
Device Model:     KINGSTON SV300S37A120G
Serial Number:    50026B786300BB55
LU WWN Device Id: 5 0026b7 86300bb55
Firmware Version: 608ABBF0
User Capacity:    120,034,123,776 bytes [120 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS, ACS-2 T13/2015-D revision 3
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Sun Nov 12 19:31:18 2017 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

745 GiB írásra, s nagyjából kétszer ennyi olvasásra volt igénybevéve.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nekem pendriveból csak Kings ment tönkre.
Eztuán Sandisk-et vagy más, megbízható márkát veszek.

biztosan nem psu.
mert asztali pc valamint laptopban is meghajtottam. mint a hülye füleltem is és egyértelmű, hogy az ssdből jön a sípolás, de nem mindig csak szakaszosan. pl ha nagy read feladatott tettem rá sípolt.

a érintett merevlemezek: suv400s37/480g valamint suv400s37/240g

eddig kingstone párti voltam, de most nagyon megingott a bizalmam... értem én, hogy tervezett elavulás meg olcsósítás, de ennyire. Munkahelyen meg muszály vagyok ssdt használni mert a régi vinyó lassú lenne.
melóba raidbe van a vinyo mert mindenki visitana ha baj van.
ui. nem beszélve arról, hogy az 1 éves kingstone g4 pendriveom bol nemrég vettem egy ugyanolyat, detto az a típus, magasabb áron vásárolva de az írási sebességem csak a fele a réginek... tököm tele van velük.

A sípolás teljesen normális jelenség ebben az iparágban. Pár év alatt el fog múlni mert nem fogod már hallani.

LOL .... jót nevettem... jah a fülem se lesz már jó.:-D most felvidítottál a sok ipari tömeggyártós szar után.

"eddig kingstone párti voltam"

Ezentúl meg gondolom Kingston párti leszel ;)
--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

Ha tényleg kingstone van ráírva, akkor az valami gagyi kínai hamisítvány lesz :)

Lassan ami nem kínai, az a hamis.
Zöldség is rengeteg van, tele tartósítóval, mintha pár perce szedték volna le a termést.
Pár hetes utaztatás után minimum fonnyadtnak kellene lennie.
Az a hazai, ami valamennyire fonnyadt, mert ez a természetes, egy normál élelmiszer az megromlik.

A PSU-t nem a ciripelésre értik, hanem hogy a rossz táp ki tud nyírni egymás után 2 SSD-t. Milyen táp konkrétan? Lehet rá kéne nézni, mielőtt egy harmadik adattárolót is kinyír.

A ciripeléstől nem lesz baja, sok SSD ad egyfajta halk, sípoló, fémes, elektromosan gerjedő hangot, attól még működnie kell. Nálam két Crucial MX300 és egy Samsung PM800-as is sípol (ez már talán hangos kategória), de amúgy hibátlanul működnek. Biztosan nem a táp ciripel, mivel közelről meghallgattam őket házon kívül üzemeltetve.

SSD-n szabad adatot tárolni, de csak olyat, amiről van mentés. Ha viszont behal a vezérlő, akkor nem lehet már róla adatot menteni, végleg bukó lesz az adatoknak, ha nem volt róluk mentés, úgy tudom, hogy még a Kürtnél sem tudják visszahozni az adatokat. Igaz a klasszikus vezérlőhiba úgy szokott kinézni, hogy fel sem ismeri a gép az SSD-t, már a BIOS/UEFI-ben sem látszik.


„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

SSD-n szabad adatot tárolni, de csak olyat, amiről van mentés.

+1024, azzal a kiegészítéssel, hogy tárolótól független igazság az, hogy ami csak egy példányban van meg, az nincs meg.
------------------------
{0} ok boto
boto ?

Avagy ez egy jó hír a merevlemez gyártóknak.
Még sokáig venni fogják a mágneseseket.

...még V100-as 256 GB-os Kingstonnál működött a trükk, hogy legújabb fw újrarak és látszólag minden szipiszuper - badblocks és h2testw is végigmegy rajta szépen hibamentesen. Csak pár hónap múlva kezd el újra problémázni.

...egyébként simán lehet valami gép/os inkompatibilitás vagy adott funkciók hibás működése (pl trim? ), most pl csak usb3-ra dugva használom és ha nem tekeri folyamatosan egy os, ami fut rajta, akkor egész jól elvan :)

Azon gondolkodom, hogy Linuxon az ember azt mondja neki, hogy noatime, de Windows-on hogyan? Egy ilyen kérdésemre valaki írta, hogy van megoldás, de azt nem tudom, hogy ez alapértelmezett-e Windows-on SSD esetén, vagy pusztán a file-ok olvasása is egy rakás írást generál.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Felrakod a gyártó ssd-hez kiadott segédprogramját és abban lehet "optimalizálni" az OS működését az ssd-vel kapcsolatban.

---
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!
Mindenki jó valamire. Ha másra nem, hát elrettentő példának.

Kérdés, a kérdező megtette-e mindezt, vagy csak úgy „vadasan” elkezdte használni, mondván, megy ez magától is.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A disablelastaccess kulcsszóra keress rá. Bár én nem bántanám, mert egyes szoftvereknek kellhet, és akkora hűdenagy írást nem produkál a meghajtóra. Linux alatt sem használom a noatime-ot, sem a discardot SSD-vel. Úgy van használva, mintha HDD lenne, csak néhány hetente végigfuttatok egy sudo fstrim -a -v parancsot, ami végig TRIM-eli a meghajtót, épp mikor kedvem szottyan rá, még arra is lusta voltam, hogy betegyem a cron-ba, hogy automatikusan lefusson x időközönként. Napi 4,3 giga az írásátlagom a SMART szerint (sudo smartctl -a /dev/sda), ezzel az ütemmel majd 102 év múlva érem el a gyártó által megadott garanciális íráslimitet (160 TBW), és ekkor is csak azt a limitet érem el, ami után nincs jótállás már az SSD-re (amúgy sem lesz, mert letelik a 3 év előbb, minthogy a limitet elérjem), de a garilimit többszörösét bírják ténylegesen a TLC NAND-os meghajtók is, nem hogy az MLC-sek. Egy átlag Windows-user ugyanezt a limitet kb. 30 giga napi írással 14,6 év alatt érné el, és szintén nem lennének még teljesen kifáradva a cellák. Összehasonlításképp ilyen hosszú időt még HDD-k sem szokták bírni napi használat mellett, mert az írásmennyiség nem korlátozó tényező, de az üzemidő ott is limitált. Felesleges túlkímélni az SSD-t, úgyse tart örökké, a vezérlő bármelyik nap megdögölhet írásterheléstől, cellafáradástól függetlenül, ezért törekedni kell rá, hogy ki legyen használva az összes íráslehetőség a meghajtó élettartama alatt, ne maradjon benne ki nem használt írástartalék. Ezek az SSD-kímélési és optimalizálási beállítások még régről származó babonák, abból a korszakból, mikor épp csak megjelentek az első SSD-k, és senki nem tudta mennyit bírnak igazából, meg hogy a különböző felhasználási területek mennyit írnak naponta. Azóta beigazolódott, hogy felesleges emiatt aggódni, főleg átlag felhasználás mellett. Pláne Linux alatt, ami alapból nagyságrendekkel kevesebbet ír a meghajtóra, meg sokkal hatékonyabban cache-el.


„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

Én sem a kernelnek mondom az fstab-ban a discard-ot, hanem van egy fstrim.timer nevű systemd felügyelete alatt lévő cucc, ez indítja az fstrim-et hetente egyszer. Viszont szigorúan noatime csatolom a filerendszereket, mivel láttam már megdöglött SSD-t életemben, olyannyira, hogy nekem kellett menteni, amit még lehetett, valamint új SSD-re új oprendszert telepíteni.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Annak az SSD-nek feltehetően a vezérlője döglődött, nem a cellák fáradtak el, máskor nézz rá a SMART adatoknál az elhasználódási mutatóra (lifetime percent kulcsszavak szoktak benne szerepelni), meg az írásmennyiségre (total writes vagy hasonló a neve, ez is gyártófüggő, meg az is, hogy hányas attribútum a SMART táblázatban). Az access time-ok írásának naponta nem kéne többnek lennie 500 MB-nál, de számoljunk 1 gigával, még akkor is bőven az alatt a szint alatt van, ami kimutathatatlan mennyiség a cellák összefáradására nézve. Ráadásul az accesstime nem is azonnal a lemezre íródik ki, hanem a kernel cache-ben tart mindent, amit csak lehet, és csak a végleges változatot írja ki, szóval a gyakorlatban van vagy 50-100 MB többletírás naponta az access time miatt egy átlag linuxos felhasználónál, de akkor is már sokat mondtam, ez már a szintén elenyésző böngészőcache-hez képest is elenyésző. Pendrive-oknál még lehet értelme ezen spórolni, SSD-knél csak felesleges önszivatás.

Az meg végképp kínos, ha neked kell mentegetni dölgött meg haldokló SSD-ről, alapszabályként mindenről kell lennie backupnak. A cellafáradásnak eleve úgy kéne kinéznie, ha meg is történik, hogy egyrészt jelzi a SMART, hogy el van használva a kondíció a meghajtón, meg csak read only csatolódnak fel róla a partíciók, vagy elfelejti az új írásokat, de a meglévő adatoknak látszania kéne. Ez az állapot ritkán áll elő, a klasszikus eset az, amikor a vezérlő hamarabb adja be a kulcsot, és vagy már bootolni sem lehet róla, vagy felcsatolni, vagy annyira kő halott az egész meghajtó, hogy már a BIOS/UEFI-ben sem látszik az eszközök között.


„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

Sok vonatkozásban igazat adok neked, bár nem mindenben. Amiről beszéltem, úgy ment tönkre, hogy egyes szektorai olvashatatlanok voltak, s emiatt széthullott a filerendszer, hiszen nyilván írni sem lehetett. A kernel ijedtében read only remount-olt. Azt nem bírom elképzelni vezérlőtől, hogy egyes területek elérhetők, míg mások nem. Ez épp magának a memóriának a hibája. A vezérlő azt tapasztalta, hogy busy a memória, de az a címterület már úgy is maradt. Kernel meg szépen logolta ezt.

Nekem van mentésem, de van, akinek hiába mondom, nem ér a szép szó. A mostani balhé után lett is egy mentés, de a vihar elmúltával már feledésbe merült a rendszeres mentés gondolata. Ilyenek az emberek. :(

Ami a böngésző cache-t illeti, azt sokszor RAM diskre teszem vagy HDD-re. Csak a kis hordozható notebook-omon van a swap, /home, /var is az SSD-n, mert abba gépbe nem lehet két háttértárat tenni. Viszont az nem elsődleges gép, viszonylag keveset használom. Mentésem amúgy arról is van.

Azért azt se feledjük, van, amikor ugyanazok a szektorok íródnak sokszor. Tudom, hogy az SSD relokál, a cím csak logikai, de akkor meg az lesz felesleges írás, szóval nem vagyok meggyőződve arról, hogy a noatime felesleges. Nyilván sync mount-ot sem használ az ember, bár azt máskor sem.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A bőngészőcache-t ne tedd HDD-re semmiképpen, nagyon lelassítja a weblapok renderélést!!! Legyen az SSD-n, vagy ha annyira kímélni akarod az SSD-t (feleslegesen), akkor RAM drive-on / memóriában legyen. Nálam csak azért van a RAM-ban, hogy ki legyen használva a 16 giga RAM, egyébként az SSD-n hagynám. A /var megint maradhat SSD-n, nem generál több írást, mint az access time. Nekem is laptopjaim meg subnoteszem van, és mindegyikbe max. egy SATA meghajtó megy, ergo nálam sem játszana az, hogy ezt-azt átteszek a HDD-re, de nem is hiányzik, szükség sincs rá.

Az összes SSD vezérlője reallokál, hogy szétossza az írásterhelést az összes cella között (wear leveling, ami nem egyenlő a garbage collectionnel / TRIM-mel, persze ez utóbbiak is többletírást generálnak), hogy egyenletesen fáradjon mind, ne legyen mindig csak az az 1-2 cella rojtosra írva. Ez valóban többletírást generál (míg a tényleges adatot tároló cellák tartalmát pakolássza át más cellákba), de azt a vezérlő nem számolja fel a SMART-ban, ergo a garanciális limitbe sem számolódik bele (de a gyártó figyelembe veszi, erre figyelemmel adja meg TLC-s meghajtóknál a garilimitet, ami emiatt szándékosan alacsonyabb szám, mint amit a meghajtó bír). Viszont ha nem tartod az SSD-t mindig csurig tömve, akkor az SSD vezérlője elég random módon ír, és nem sok szükség van a wear levelingre, ergo nem sok többletírásba kerül a vezérlőnek, hogy egyenletesen fáradjon az összes cella.


„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

Nem igazán következetes szerintem, amit írtál, vagy én nem értem. Először azt írod, hogy a wear leveling osztja el az írásterhelést, a későbbiekben meg azt, hogy az SSD vezérlője elég random módon ír, és nem sok szükség van a wear levelingre, de hiszen ez a random írás épp az. A filerendszer nyilvántartása íródna rojtosra, tehát a foglaltsági táblák, meg a journal. Persze a kernel használ disk cache-t, de néha ki kell sync-elni a háttértárra, hogy ne hulljon szét a filerendszer. Gyanítom, semmit nem ér az a journaling, amelyet órákig RAM-ban tartanánk, mert akkor minek van.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem olvasol figyelmesen, azért vélsz ellentmondást felfedezni. Azt írtam, hogy nincs nagy szükség a wear levelingre, HA NINCS csurig töltve az SSD. Ha viszont majdnem tele van, és már csak kevés cella van szabadon (amelyek között a random írás történhet), akkor nagyobb feladat hárul a wear levelingre, hiszen állandóan el kell pakolásznia a teli cellák tartalmát üres cellákba, hogy egyenletesebb legyen a cellák fáradása. Emiatt kell az SSD-n hagyni legalább 10-15% helyet, de én inkább +20%-ot ajánlok, az mindegy, hogy particionált nem particionált területen van-e meghagyva, én mindenesetre a particionált területes megoldást ajánlom. Minél inkább tele van a meghajtó, annál inkább intenzíven dolgozik a wear leveling, és annál nagyobb a többletírások száma.

A journal cache terén igazad van, azt a kernel nem tartja túl sokáig memóriában, de maga a journal meg nagyon keveset ír, és az SSD vezérlője ezt az írást is random módon osztja el az adatterületen, vagy eleve egy keveset használt cellába teszi, nem mindig ugyanaz a cella használódik el. Már ha van hely, ha nincs, akkor megint csak oda írja ki, ahol hely van, és a wear leveling meg tologatja a cellák tartalmát ide-oda.

Ha tényleg kímélni akarod az SSD-d, akkor nem a sok szir-szart kell róla áttenni RAM-ba, HDD-re, meg noatime-ozni, hanem hagyni kell rajta mindig bőségesen szabad helyet. Amúgy sem adattárolásra való, hanem egyfajta rendszercache-nek. Pendrive-ot és memóriakártyát is ezzel lehet leginkább kímélni, nem azzal, hogy nem írunk rá, azzal csak nem használjuk ki és potyára vettük meg. Ezért ajánlottam már sok SSD Kímélő Karcsinak egy másik fórumon, hogy ha annyira féltik az SSD-jüket, akkor be se szereljék a gépbe, inkább tegyék be a szoba sarkába egy üvegvitribe, ahol csak nézegetik, úgy nem kap sok írást. Oda is csak dobozostól ajánlom közszemlére tenni, nehogy szemlenyomatos legyen, árthat neki.

Félre ne érts, tele lehet írni az SSD-t, attól nem lesz baja önmagában. Akkor van baj, ha sokat használod állandóan csurig írt állapotban. Ha viszont csak alkalmanként töltöd meg teljesen, de aztán mindig csinálsz rajta elég szabad helyet, vagy teleírod, de nem sokat használod napi szinten, akkor a telepakoltság nem árt, mert megint csak nem kell sokat dolgoznia a wear levelingnek, és nem kap emiatt felesleges többletírást a meghajtó. Ez alapján a leggyilkosabb egy SSD-re nézve, ha szoftveres egész lemezes titkosítást használsz rajta (LUKS, TrueCrypt), mivel azoknak az a lényege, hogy megkülönböztethetetlenek a használt és nem használt szektorok (biztonsági okból), emiatt az SSD vezérlője úgy látja, hogy az összes cella hasznos adattal van tele (mikor meg igazából nincs), a wear levelingnek nem lesz helye, hogy működjön (és a TRIM sem működik, de erre vannak kerülőutak, de ezek a titkosítás támadhatóságát teszik lehetővé). Nem viccből szerelnek fel sok SSD-t hardveres öntitkosítással, hogy ne kelljen rajta szoftveres titkosítási megoldást alkalmazni.


„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

Miközben olvastalak, épp azon kezdtem gondolkodni, amit a végén írtál. Honnan tudja az SSD, hogy mi az adat? Ő nem értelmezhet partíciós táblát, filerendszert, mert semmi köze hozzá, hiszen lehet egy mikrokontroller is, ami tárol rajta valamit egy saját formátumban. Tehát az SSD szintjén csak szektor cím van, semmi más. (Ugye lehet MBR, GPT, de nem muszáj lenni partíciós táblának, lehet LVM, btrfs, vagy sima bináris valami direkt módon.)

Vagy ezt a kernel csinálja, a kernel tudja, hogy az eszköz SSD, és rotálja az adatot?

Van még egy bajom ezzel. Ha valamit máshova írunk, akkor az máshol van, tehát kell egy logikai címet a fizikai címmel összepárosító táblázat. Ez miben tárolódik? Csak non-volatile eszköz jöhet szóba természetesen.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A TRIM parancs futtatásából tudja. Amelyik szektorra az OS küldött TRIM parancsot, az abban lévő cellákat a vezérlő alapállapotba hozza (a tartalmuk törlődik). Innen tudja a vezérlő, hogy egy cella üres-e vagy nem. Állítólag néhány SSD-nek a TRIM-támogatástól függetlenül van saját garbage collectionje, ami ugyanezt csinálja, de azoknál nem tudom hogyan működnek, honnan tudja a vezérlő, ha egy cella tartalma már nem kell.

A logikai és fizikai cím párosításán már én is gondolkoztam, és nem sikerült rájönnöm, hogy hol tartódik nyilván. Valahogy a vezérlő deríti ki, nem a kernel, de passzolom mi alapján dönti el.

Azt viszont jól látod, hogy az SSD vezérlője nem érti a fájlrendszereket, csak fizikai cellákat és szektorokat lát.


„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

Tudja az SSD is, mert ugye az írás úgy megy, hogy az egész blokkot beolvassa és átírja egy másik blokkba a módosításokkal együtt és a régi blokkot megjelöli, mint üreset, amibe aztán írhat később. Ezt kombinálja a wear leveling annyival, hogy nem módosított blokkokat is átír néha máshova, különben az a helyzet állna elő, hogy 90 százalék read-only blokk és 10 százalék gyakran írt blokk esetén a 10 százalék elhasználódik. Ezt egészíti ki a TRIM, ami a fájlrendszer szintről jelzi a legalsó fizikai szintnek, hogy egy blokk már üres és újrafelhasználható.

"Ez miben tárolódik? Csak non-volatile eszköz jöhet szóba természetesen."

Ez nem igényel sok helyet, tudunk azért olyan tárolókat, amelyek nem öregszenek, sokszor írhatóak és nem felejtenek... :)

Bocs de SSD-t vagy OP rendszer tárolásra veszünk, vagy semmi értelme.

Félig off:

Idézet:
Mentés még nem volt, igen hanyagság, kövezzetek meg. (mondván hátha nem megy tönkre rögtön... de deee :@....)

Nem feltétlen csak a "tönkremenés" miatt kell szerintem backup, hanem a "véletlen" fájlműveletek (törlés, felülírás, stb.) miatt is - saját tapasztalat :)

Meg vírusok, ransomware-ek, szoftveres bugok miatti adatvesztés esetén is jól jön. Backupnak mindig lennie kell, nem érdekes, hogy mennyire új és jó kondícióban lévő tárolón van. Bízni lehet benne, hogy nem lesz adatvesztés, de felelőtlenség nem felkészülni rá.


„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

+1

Idézet:
vírusok, ransomware-ek, szoftveres bugok miatti adatvesztés

Egyezzünk meg abban, hogy ezek is beleférnek a "véletlen fájlműveletek" kategóriába, jó? :)

pár kérdésre válaszolnék újra:

- táp biztosan nem lehet, mert külső aktív usb hub -ban szoktam a mentéseket meghajtani. (5v-2a segítség)
- vírusokra nem gondoltam mert programot külön nem telepítünk, fájl mellékleteket elhanyagolom, pl windows script host is kikapcsolva a js szarok miatt
- a fájl műveletekre meg ott volt a win. előző verziókra pár giga hagyva
- kin keservesen sikerült lementenem kb azt az 500megát amire szűkség volt.
- igen kingston nem e a végén, a szemfüleseknek :-)
- úgy gondoltam, hogy 2 hónapot csak kibír, de szerintem kifogtam egy gyártó által készített zabigyereket.

KÖSZÖNÖM SZÉPEN A SEGÍTSÉGETEK, ÖTLETEITEK, IDŐTÖKET!

táp biztosan nem lehet, mert külső aktív usb hub -ban szoktam a mentéseket meghajtani.

A megdöglött SSD-nem a gépben volt? Mert, ha igen, akkor ebből hogyan következik a tápegység jósága?


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

+ adódik a kérdés, hogy a "biztosan" külső USB fix tápról meghajtott USBn felcsatolt SSD-ről van-e szó, avagy sem ... Mert a tuti biztos USB HUB + TÁP == oroszrulett, véleményem szerint.

Miért oroszrulett? Ez most nekem nem jött át. Arra gondolsz, hogy arról a tápról sem tudunk semmit?


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Arra gondolok, hogy USB + külső táp == vagy azt adja le amit "beállítasz" neki vagy nem ....

Bocs, univerzál tápokra gondoltam fentebb. Elnézést. Ha adott eszközhöz adják a tápot / csatit, akkor más a helyzet.

Sorry.

ps.: de mint fentebb említve lett USB HUB* és társai nem hiszem hogy a saját táppal adták ezt a dolgot. De majd a kérdező válaszol és remélem nem valami kínai USB HUB -ra rádugott SSDről van szó ..

Naiv lélek vagyok, elhiszem a specifikációt. Lehet, azért, mert szigorúak a minőségi elvárások a munkahelyemen, így a peremfeltételeknek megfelelően kell tervezni, s annak igazolhatóan úgy kell lennie. ;) Az nem megy, hogy „jó lesz, kibírja az”. :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ebben egyetértünk, de a fenti eset pont azt mutatja hogy "jóvanazúgy*" esete, nem?

Volt néhányunknak pár gondolata, de azt nem tudjuk, mi is történt valójában, s szerintem a kérdező sem tudja. Kellene egy oszcilloszkóp ahhoz a tápegységhez...


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Úgy érted, hiába pontosak a feszültségek multiméterrel, lehetnek nagyfrekis tüskék a jelben?
Jó ötlet, okosakat írsz.

Tüskék vannak. Ha nincsenek eléggé elsimítva akkor egy gyengébb tápú vagy érzékenyebb alkatrész megérezheti.
Öregedő kondenzátor is ronthatja az élményt, vagy nem simít már eléggé vagy ha valami meghúzza a tápot nem lesz már elég tárolt kapacitás benne ahoz hogy pár ms-ig bírja tartani a feszültségszintet.

Ezeket csak oszcilloszkóppal tudod megnézni.

Igen, így értem, hiszen a kondenzátorok idővel kapacitásukból veszítenek.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Kösz!
Jogos a kapacitás csökkenés.
Csak úgy értettem, más hiba miatt is rárakódhat káros jel az egyenfeszültségre.