Előre nem értik, utólag meg én vagyok a főgyökér, mikor közlöm, hogy nem megmondtam? Ügyfél át akarta vinni az ADSL-t valami nevenincs szolgáltatóhoz. Nem Btel, nem is tudom, de T. EnterNet, GTS szokásosak az "drága". Átpapírozta, lassú, szakad, nem műxik. nincs ügyfélszolgálat. Na mondom mi legyen? Hát csináljak valamit, mert ez nem állapot, teljesen működésképtelen. Én meg benyögtem, hogy de legalább olcsóbb, ez van. Azt hittem lebasz egyet.
Valakinek nagyonfontossürgősen elb@#&dott az nvme-cucca. A win (ill. már a BIOS) nem is látja a 'diszket', linuxon (külső adapterrel) megjelenik az sdb, de 0 mérettel.
Mit lehet tenni ilyenkor? Van bármi esély a gyógyulásra?
Igen, van dinamikus klónozásra is lehetőség, amikor csak a használt szektorokat viszi át, ahogy írtad (egyébként csak az egyszerűsítés kedvéért mondtam a szektoronkénti másolást mert tisztában vagyok vele, hogy blokk szinten gondolkozunk: az SSD-n nincsenek szektorok mert a NAND lapkák blokkjaiban cellák vannak, illetve a modern HDD-ken sem CHS alapon címzünk már hanem LBA alapon). És természetesen nem úgy gondoltam, hogy a hibás szektort a klónon is hibásnak jelöli, hanem csak a hibás adattartalmát másolja át. Van olyan program (Macrium) ami ha hibát talál elbotlik rajta és egyszerűen kiakad, vége a dalnak. Az Acronis megengedőbb a hibás szektorok kezelését illetően mert annál a bitpontos másolat esetén kiválasztható, hogy a hibás szektorokkal vagy azok nélkül készüljön el a klón.
Egyébként a Macrium az új X verzióban most nagyon alávágott a felhasználói táborának az előfizetéses rendszerre való átállással.
"klónozás és nem megfelelő beállítás esetén a hibás szektorok tartalma is átmásolódik."
Legtöbb klónozó eleve nem szektort fog másolni. Szépen megcsinálja a partíciókat, meg úgyis ott lesz, hogy mit mire méretezzen dinamikusan és tartalmat másol. Hibás szektor tartalma hibás, azt a vezérlő felül is vágja, nem fogod olvasni (varázslatokat most kihagyhatjuk) és tartalma sincs, mert hibás. Ha hibás, attól még olyan módszer nincs, amit lentebb emlegettél, hogy majd az a szektor (főleg SSD-n) a cél eszközön is hibás legyen, tök nonszensz olyan nincs, hogy majd így a szoftver az SSD-n a 17. szektort (főleg ha eltérő méretek is vannak) majd hibásnak jelöli mert a forrás HDD-n az volt, ne marháskodjunk már.
"Windowsban a CHKDSK nem elég? Annak is van felülettesztje (?)"
Mondtam, hogy olyan eszköz kell, ami pontosanmegmondgya és dokumentálja is, hogy hol vannak a hibák!
Ha ezeket lefuttatod a teljes diszken (tehát NEM akármilyen partíción!), esetleg több gépben is, ha már megteheted, először csak olvasva, akkor ki fog derülni, hogy mindig ugyanott jelentkezik-e a hiba (tehát sanszos, hogy maga a lemez [tárterülete] bibis), vagy 'vándorol', ami arra utalna, hogy máshol, vélhetően az eszközön kívül van az ok.
"De azt írtad, hogy ha lemezt klónoztam bitről-bitre, akkor átmehetett a lemezhiba. Az hogyan, ha a hibák bejegyzése másutt található (firmware)?"
A hibás szektor a felhasználói adatterületen, fizikailag létező dolog, ezért a firmware-ban futó translator csak virtuálisan tudja kimaszkolni mert fizikailag nem képes eltüntetni. Bitpontos klónozás során a programokban általában be lehet jelölni, hogy a hibás szektorokkal együtt, vagy azok kihagyásával történjen a klónozás és nem megfelelő beállítás esetén a hibás szektorok tartalma is átmásolódik.
"A klónozásra már én is gyanakodtam, de még az első SSD-t átraktam asztali gépbe, letakarítottam a partíciókat, egy db partíciót létrehoztam és elkezdtem rá másolni, ott is jöttek a CRC hibák. Ezért is kérdeztem, hogy a elronthatja egy esetleg rosszul működő laptop az SSD-t úgy, hogy utána másik gépben is ugyanaz a hiba jelentkezik."
Elméletileg elronthatja, viszont ilyen eset még nem nagyon volt a praxisomban.
"Az SSD-t lehet "resetelni", vagyis visszaállítani úgy, ahogy új állapotában volt?"
Teljes formázásnál minden szektor ellenőrzésre kerül és a hibásak kimaszkolódnak (ha még van spare area). Viszont ez írásterhelést jelent az SSD-nek. Ennél gyorsabb megoldás a secure erase ami csak az MCU titkosító kulcsát változtatja meg, így a korábbi kulccsal titkosított adatok visszafejthetetlenné válnak (tehát nem kell megformázni az SSD-t ha csak az adatok miatt aggódunk, hogy illetéktelen szemek elé kerülnek). Viszont ennek a megoldásnak az a hátránya is egyben ami az előnye, hogy gyors, mert nem ellenőrzi és maszkolja ki a hibás szektorokat.
Szó sem volt vaktában lövöldözésről. Csak éppen javasoltam igazolni, vagy kísérletileg cáfolni a kérdező szerint legelsőként feltételezett - és nem ellenőrzött - hibát, miszerint az SSD a hibás. Utólag megnézve, lényegében ugyanazt javasoltam, amit te a 94523-ban, csak más szavakkal.
Megjegyzés: Én azért a javaslatom előtt megnéztem az adott SSD-ről írtakat az árukeresőn, és ugy láttam, hogy több száz közül az első néhány tucat hozzászólászóló egyaránt arról számolt, be, hogy hogy nem volt gondj az adott SSD-vel (tovább nem olvastam a véleményeket). Ezért gyanakodtam arra, hogy ellenőrizni kellene, hogy egyáltalán tényleg az SSD hibája okozta -e a gondot.
De azt írtad, hogy ha lemezt klónoztam bitről-bitre, akkor átmehetett a lemezhiba. Az hogyan, ha a hibák bejegyzése másutt található (firmware)?
A klónozásra már én is gyanakodtam, de még az első SSD-t átraktam asztali gépbe, letakarítottam a partíciókat, egy db partíciót létrehoztam és elkezdtem rá másolni, ott is jöttek a CRC hibák. Ezért is kérdeztem, hogy a elronthatja egy esetleg rosszul működő laptop az SSD-t úgy, hogy utána másik gépben is ugyanaz a hiba jelentkezik.
Az SSD-t lehet "resetelni", vagyis visszaállítani úgy, ahogy új állapotában volt? GOndolom nem, de azért egy kérdést megér...
"Macrium Reflect nevű programmal csináltam, és igazából a partíciókat csak át kellett húzogatni, tehát nem igazi lemez klónozás volt."
Most akkor bitpontos klónozást csináltál (amit kellene), vagy csak átmásoltad a mappákat (partíciókat)? Ha az utóbbi akkor fuss neki újra az előbbivel.
"De a rossz szektorkat nem valami elkülönített tárolón rögzíti, hanem az adatterületen?"
A hibás szektorokat a meghajtók a szervizterületükön (tehát nem a felhasználó által elérhető adatterületen) lévő firmware modulokban tárolják. Több lista is van: külön a gyárilag már meglévő hibás szektoroknak, külön egy a bizonytalan állapotú szektoroknak, külön egy a működés közben létrejött hibás szektoroknak, stb. A meghajtó firmware-je a tartalék területről (spare area) lecseréli a hibás szektorokat jókra és a változtatást bejegyzi a megfelelő, fizikai Cylinder-Head-Sector (CHS) alapú listába, ami alapján a fordító (a translator) elcsúsztatja a további logikai blokk címeket (LBA), hogy az oprendszer számára összefüggőnek látsszon a meghajtó. Így amíg a tartalék terület nem fogy el teljesen, addig az oprendszer számára a meghajtó használható és csak a S.M.A.R.T.-jából látható, ha valami nincs rendben (vagy még onnan se, mert nem minden érték frissül valós időben csak power cycle esetén).
"Ha a rossz szektor be lett jegyezve, akkor oda már nem tenne adatot, így CRC hiba sem kellene, hogy jöjjön."
Így van, a bejegyzett hibás szektorokra nem ír. Viszont mint már írtam, azok a CRC hibák nem a lemezfelület hibáiból adódnak hanem az alaplap SATA vezérlője és a HDD vezérlője közti kommunikációs hibákból. Normál PC esetén kábelcserét javasolnának de laptop esetén ez nem járható út. Laptop esetén azt lehet ellenőrizni, hogy pl. nem e folyadékkáros az alaplap amitől megváltozik a SATA adatvonalak differenciálpárjainak a vonalon belüli egymáshoz viszonyított ellenállása, ami tud anomáliákat okozni.
"Ja, és a HDD-t hibátlannak jelezte a HD Sentinel"
