Pagrindinis » kaip » Ar duomenys apie kietuosius diskus gali sumažėti be įspėjimo apie žalą?

    Ar duomenys apie kietuosius diskus gali sumažėti be įspėjimo apie žalą?

    Mes visi nerimaujame, kad mūsų duomenys ir failai yra saugūs ir nepažeisti, tačiau ar įmanoma, kad duomenys sugadinti ir prieiti prie naudotojo be pranešimo ar įspėjimo apie problemą? Šiandienos „SuperUser“ Q&A pranešimas turi atsakymą į nerimą keliančio skaitytojo klausimą.

    Šiandienos „Klausimų ir atsakymų“ sesija mums suteikiama pagal „SuperUser“ - „Stack Exchange“ padalinį, bendruomenės sukurtą „Q&A“ svetainių grupavimą.

    Nuotraukų mandagumo apibendrinimas (Flickr).

    Klausimas

    „SuperUser“ skaitytuvas „topo morto“ nori sužinoti, ar standžiųjų diskų duomenys gali susilpnėti ir gauti įspėjimo apie žalą:

    Ar įmanoma, kad fizinis standžiojo disko degradavimas gali sukelti bitų failo turinio „pasukimą“, jei operacinė sistema nepastebi pakeitimo ir apie jį praneša vartotojui, kai skaitymas failas? Pvz., Ar „p“ (dvejetainis 01110000) ASCII tekstiniame faile gali pasikeisti į „q“ (dvejetainis 01110001), tada, kai vartotojas atidaro failą, jie mato „q“, nežinant, kad įvyko gedimas?

    Mane domina atsakymai, susiję su FAT, NTFS arba ReFS (jei tai daro skirtumą). Noriu žinoti, ar operacinės sistemos apsaugo vartotojus nuo šios priežasties, ar mes turėtume tikrinti, ar laikui bėgant duomenys neatitinka kopijų.

    Ar standžiųjų diskų duomenys gali susilpnėti ir gauti įspėjimą apie žalą?

    Atsakymas

    „SuperUser“ autorius Guntramas Blohmas mums atsako:

    Taip, yra dalykas, vadinamas bitų puvimu. Bet ne, jis nepaveiks naudotojo nepastebėto.

    Kai kietajame diske sektorius įrašomas į plokšteles, jis ne tik rašo bitus tokiu pačiu būdu, kaip jie yra saugomi RAM, jis naudoja kodavimą, kad įsitikintų, jog nėra tos pačios bitų sekos, kurios yra per ilgos. Ji taip pat prideda ECC kodus, leidžiančius taisyti klaidas, turinčias įtakos kelioms bitoms, ir aptikti klaidas, kurios veikia daugiau nei keletą bitų.

    Kai kietasis diskas nuskaito sektorių, jis patikrina šiuos ECC kodus ir, jei reikia, taiso duomenis. Tai, kas nutinka toliau, priklauso nuo aplinkybių ir standžiojo disko programinės įrangos, kurią įtakoja disko pavadinimas.

    • Jei sektorius gali būti skaitomas ir neturi ECC kodo problemų, jis perduodamas operacinei sistemai.
    • Jei sektorius gali būti lengvai suremontuotas, pataisyta versija gali būti įrašyta į diską, nuskaityta atgal, tada patikrinama, ar klaida buvo atsitiktinė (t. Y. Kosminiai spinduliai ir tt), ar yra sisteminė klaida su žiniasklaida.
    • Jei kietajame diske nustatoma, kad yra žiniasklaidos klaida, jis perskirsto sektorių.
    • Jei po kelių skaitymo bandymų sektorius gali būti nei skaitytas, nei koreguojamas (kietajame diske, kuris priskiriamas RAID standžiajam diskui), kietasis diskas atsisakys, perskirstys sektorių ir pasakys valdytojui, kad yra problema . Jis remiasi RAID valdikliu, kad atstatytų sektorių iš kitų RAID narių ir įrašytų jį atgal į nepavykusį kietąjį diską, kuris tada saugo jį perskirstytame sektoriuje (tai, tikiuosi, neturės problemų).
    • Jei darbalaukio kietajame diske negalima skaityti ar pataisyti sektoriaus, kietasis diskas bandys jį perskaityti. Priklausomai nuo standžiojo disko kokybės, tai gali apimti galvos perstatymą, patikrinimą, ar yra kokių nors bitų, kurie perskaitytų pakartotinai, tikrinant, kurie bitai yra silpniausi, ir keli kiti dalykai. Jei kuris nors iš šių bandymų bus sėkmingas, standusis diskas perskirstys sektorių ir įrašys suremontuotus duomenis.

    Tai vienas iš pagrindinių skirtumų tarp standžiųjų diskų, kurie parduodami kaip „darbastalio“, „NAS / RAID“ arba „vaizdo stebėjimo“ diskai. RAID kietasis diskas gali tiesiog greitai atsisakyti ir valdytojui pataisyti sektorių, kad būtų išvengta vartotojo vėlavimo. Darbalaukio kietasis diskas ir toliau bandys vėl ir vėl, nes vartotojas, palaukęs kelias sekundes, greičiausiai yra geresnis nei pasakant, kad duomenys yra prarasti. Ir vaizdo standžiojo disko reikšmės yra pastovios, o duomenų atkūrimo dažnis yra didesnis nei klaidų atkūrimas, nes pažeistas rėmelis paprastai net nebus pastebėtas.

    Bet kokiu atveju, kietasis diskas žinos, ar bus šiek tiek puvinio, paprastai atsigaus iš jo, o jei to nepavyks, jis nurodys valdytojui, kuris savo ruožtu pasakys vairuotojui, kuris tuomet pasakys operacinei sistemai. Tada operacinė sistema turi pateikti naudotojui klaidą ir veikti pagal ją. Štai kodėl cybernard sako:

    • Aš niekada nepastebėjau vieno bitų klaidos, bet mačiau nemažai standžiųjų diskų, kuriuose visi sektoriai nepavyko.

    Kietasis diskas žinos, ar sektoriuje yra kažkas negerai, tačiau jis nežino, kurie bitai nepavyko. ECC visuomet bus sugautas vienas nesėkmingas bitas.

    Atkreipkite dėmesį, kad chkdsk ir failų sistemos, kurios automatiškai pataiso patys, nesprendžia duomenų taisymo failuose. Jie yra nukreipti į korupciją pačios failų sistemos struktūroje, pavyzdžiui, failo dydžio skirtumas tarp katalogo įrašo ir skiriamų blokų skaičiaus. „NTFS“ savęs gijimo funkcija aptiks struktūrinius pažeidimus ir neleis joms dar labiau paveikti jūsų duomenų, tačiau ji nepašalins jau sugadintų duomenų.

    Žinoma, yra kitų priežasčių, kodėl duomenys gali būti sugadinti. Pvz., Bloga atmintinė valdiklyje gali keisti duomenis, kol ji netgi išsiunčiama į kietąjį diską. Tokiu atveju jokiu kietojo disko mechanizmu nebus aptikta ar taisoma duomenų, o tai gali būti viena iš priežasčių, kodėl sugadinta failų sistemos struktūra. Kitos priežastys - programinės įrangos klaidos, trikdžiai rašant į kietąjį diską (nors tai yra sprendžiama failų sistemos žurnaluose), arba blogi failų sistemos tvarkyklės (NTFS tvarkyklė Linux'ui nustojo skaityti tik ilgą laiką, nes NTFS buvo sugrąžinta, dokumentais, o kūrėjai nepasitikėjo savo kodu).

    • Šį scenarijų turėjau vieną kartą, kai paraiška išsaugo visus savo failus dviejuose skirtinguose serveriuose dviejuose skirtinguose duomenų centruose, kad visomis aplinkybėmis būtų galima išlaikyti darbo duomenų kopiją. Po kelių mėnesių pastebėjome, kad apie 0,1 proc. Visų nukopijuotų failų neatitiko MD5 patikrinimo sumos, kurią taikomoji programa saugojo savo duomenų bazėje. Jis pasirodė esąs klaidingas pluošto kabelis tarp serverio ir SAN.

    Šios kitos priežastys yra priežastys, kodėl kai kurios failų sistemos, pvz., ZFS, saugo papildomą patikrinimo sumą, kad aptiktų klaidas. Jie yra skirti apsaugoti jus nuo daug daugiau dalykų, kurie gali suklysti, nei tik šiek tiek pūti.


    Ar ką nors papildyti paaiškinimu? Garsas išjungtas komentaruose. Norite perskaityti daugiau atsakymų iš kitų „tech-savvy Stack Exchange“ vartotojų? Čia rasite visą diskusijų temą.