A merevlemez-meghajtók adatai figyelmeztetés nélkül romolhatnak?
Mindannyian aggódunk adataink és fájljaink biztonságos és sértetlen megtartása miatt, de lehetséges-e, hogy az adatok megsérüljenek, és a felhasználó hozzáférhessen ahhoz, hogy a problémáról semmilyen értesítés vagy figyelmeztetés nélkül kerüljön sor? A mai SuperUser Q & A-posta a válasz egy aggódó olvasó kérdésére.
A mai Kérdések és válaszok munkamenet a Jóvagyon - a Stack Exchange alosztályának, a közösség által vezérelt Q&A webhelyek csoportjának köszönhetően..
A fotózás jóvoltából (Flickr).
A kérdés
A SuperUser olvasó topo morto tudni akarja, hogy a merevlemez-meghajtók adatai romolhatnak-e, és a figyelmeztetés nélkül hozzáférhetnek-e ehhez:
Lehetséges, hogy a merevlemez fizikai lebomlása a bitek "tartalmának" megjelenését okozhatja a fájl tartalmában anélkül, hogy az operációs rendszer észrevenné a változást, és értesíti a felhasználót erről a fájl olvasásakor? Például egy ASCII szövegfájlban lévő „p” (bináris 01110000) „q” -re (bináris 01110001) változhat-e, majd amikor a felhasználó megnyitja a fájlt, „q” -et lát, anélkül, hogy tudná, hogy hiba történt?
Érdekelnek a FAT, NTFS, vagy ReFS-re vonatkozó válaszok (ha ez különbséget tesz). Szeretném tudni, hogy az operációs rendszerek védik-e a felhasználókat ebből, vagy ha időnként ellenőrizzük a másolatok közötti eltéréseket.
A merevlemez-meghajtók adatai romolhatnak, és a sérülésekre figyelmeztetés nélkül férhetnek hozzá?
A válasz
A SuperUser közreműködő Guntram Blohm válaszol nekünk:
Igen, van egy dolog, amit úgynevezett bit rot. De nem, ez nem befolyásolja észrevétlenül a felhasználót.
Amikor egy merevlemez egy szektort ír a tálcákra, akkor nem csak a biteket írja fel ugyanúgy, mint amennyit RAM-ban tárolnak, hanem egy kódolást használ annak biztosítására, hogy nincsenek azonos hosszúságú sorok, amelyek túl hosszúak. Hozzáad egy ECC kódot is, amely lehetővé teszi, hogy néhány bitet érintő hibákat javítson, és néhány bitnél több hibát észlel.
Amikor a merevlemez leolvassa az ágazatot, ellenőrzi ezeket az ECC kódokat, és szükség esetén javítja az adatokat (és ha lehetséges). Ami ezután történik, a merevlemez körülményeitől és firmware-jétől függ, amit a meghajtó megnevezése befolyásol.
- Ha egy szektort el lehet olvasni és nincs ECC kód problémája, akkor az átadódik az operációs rendszernek.
- Ha egy szektor könnyen javítható, a javított verziót lemezre írhatjuk, olvashatjuk vissza, majd meggyőződhetünk arról, hogy a hiba véletlenszerű-e (azaz kozmikus sugarak, stb.), Vagy ha rendszeres hiba van a médiával.
- Ha a merevlemez-meghajtó megállapítja, hogy hiba van a médiával, akkor újraosztja az ágazatot.
- Ha egy szektor nem olvasható és nem korrigálható néhány olvasási kísérlet után (egy RAID merevlemezre kijelölt merevlemezen), akkor a merevlemez lemond, szétosztja az ágazatot, és elmondja a vezérlőnek, hogy probléma merült fel . A RAID vezérlőre támaszkodik, hogy rekonstruálja az ágazatot a többi RAID tagból, és írja vissza a hibás merevlemezre, amely aztán tárolja azt az átcsoportosított szektorban (ami remélhetőleg nem lesz probléma).
- Ha egy szektor nem olvasható vagy kijavítható az asztali merevlemezen, akkor a merevlemez több kísérletet tesz az olvasásra. A merevlemez minőségétől függően ez magában foglalhatja a fej áthelyezését, annak ellenőrzését, hogy vannak-e olyan ismétlődő bitek, amelyek ismétlődnek-e, ellenőrizve, hogy mely bitek a leggyengébbek, és néhány más dolog. Ha ezek a kísérletek sikeresek lesznek, a merevlemez átirányítja az ágazatot, és visszaírja a javított adatokat.
Ez az egyik fő különbség az „asztali”, „NAS / RAID” vagy „videomegfigyelő” merevlemezként értékesített merevlemezek között. A RAID merevlemez csak gyorsan lemondhat, és a vezérlő javíthatja a szektort, hogy elkerülje a felhasználó látószögét. Az asztali merevlemez újra és újra próbálkozik, mert a felhasználó néhány másodperc várakozásának valószínűleg jobb, mint mondani, hogy az adatok elvesznek. És egy videó merevlemez állandó adatátviteli sebességet ad meg, mint a hiba helyreállítása, mivel a sérült keret általában nem is észlelhető.
Mindenesetre, a merevlemez tudni fogja, hogy van-e kicsit rothadás, tipikusan visszanyerhető belőle, és ha nem, akkor megmondja a vezérlőnek, hogy ez megmondja a vezetőnek, hogy ezután megmondja az operációs rendszert. Ezután az operációs rendszer feladata, hogy bemutassa a hibát a felhasználónak és cselekedjen rajta. Ezért mondja a cybernard:
- Soha nem tapasztaltam egyetlen bites hibát magamban, de sok olyan merevlemezt láttam, ahol az egész szektor kudarcot vallott.
A merevlemez tudni fogja, hogy van valami rossz a szektorban, de nem fogja tudni, hogy mely bitek sikertelenek. Az ECC mindig meghibásodott egy kicsit.
Kérjük, vegye figyelembe, hogy a chkdsk és a fájlrendszerek, amelyek automatikusan javítják magukat, nem foglalkoznak a fájlok adatainak javításával. Ezek a fájlrendszer struktúráján belüli korrupcióra irányulnak, mint például a fájlméret különbsége a könyvtárbejegyzés és a hozzárendelt blokkok száma között. Az NTFS öngyógyító funkciója felismeri a strukturális károkat, és megakadályozza, hogy az adatok tovább befolyásolják az adatokat, de nem javítja a már sérült adatokat.
Természetesen vannak más okok is, amelyek miatt az adatok megsérülhetnek. Például a vezérlőn lévő rossz RAM megváltoztathatja az adatokat, mielőtt még a merevlemezre is elküldené. Ebben az esetben a merevlemezen lévő egyetlen mechanizmus sem fogja észlelni vagy javítani az adatokat, és ez lehet az egyik oka annak, hogy a fájlrendszer szerkezete sérült. Egyéb okok közé tartoznak a szoftverhibák, a merevlemezre történő írás közbeni áramkimaradások (bár ez a fájlrendszer naplózásával foglalkozik), vagy a rossz fájlrendszer-illesztőprogramok (az NTFS-meghajtó a Linuxon már régóta csak olvasható, mivel az NTFS megfordították, nem dokumentált, és a fejlesztők nem bíztak saját kódjukban).
- Ezt a forgatókönyvet egyszer alkalmaztam, amikor egy alkalmazás két különböző szerverre mentett két fájlt két különböző adatközpontban, hogy minden körülmények között rendelkezésre álljon a rendelkezésre álló adatok egy példánya. Néhány hónap elteltével észrevettük, hogy az összes másolt fájl körülbelül 0,1 százaléka nem egyezik meg az MD5 ellenőrző összegével, amelyet az alkalmazás tárolt az adatbázisában. Kiderült, hogy a szerver és a SAN közötti hibás szálkábel.
Ezek az egyéb okok az, hogy egyes fájlrendszerek - mint a ZFS - további ellenőrzési összegeket tárolnak a hibák észlelése érdekében. Úgy tervezték, hogy megvédje Önt egy sokkal több dologtól, ami tévedhet, mint egy kicsit rothadás.
Van valami, amit hozzá kell adni a magyarázathoz? Kikapcsolja a megjegyzéseket. Szeretne további válaszokat olvasni más tech-savvy Stack Exchange felhasználóktól? Nézze meg a teljes beszélgetés szálát itt.