Ajakirjaga failisüsteemid on failisüsteemide klass, mille iseloomulik tunnus on päevik, muudatuste loendi salvestamine, mis aitab teatud määral säilitada terviklikkust. failisüsteem.

Süsteemikontrolli (nt fsck) käivitamine suurtes failisüsteemides võib võtta kaua aega, mis on tänapäeva kiirete süsteemide puhul väga halb. Failisüsteemi terviklikkuse puudumise põhjuseks võib olla vale lahtiühendamine, näiteks kui kettale kirjutati lõpetamise ajal. Rakendused saaksid värskendada failides sisalduvaid andmeid ja süsteem saaks uuendada failisüsteemi metaandmeid, mis on "failisüsteemi andmed" ehk teisisõnu teavet selle kohta, millised plokid milliste failidega on seotud, millised failid mis kataloogides asuvad ja nagu .. Andmefailide vead (terviklikkuse puudumine) on halvad, kuid hullemad kui failisüsteemi metaandmete vead, mis võivad põhjustada failide kadumise ja muid tõsiseid probleeme.

Terviklikkuse probleemide minimeerimiseks ja süsteemi taaskäivitamise aja minimeerimiseks peab päevikfailisüsteem enne muudatuste tegelikku kirjutamist loendit muudatustest, mida ta failisüsteemis teeb. Need kirjed salvestatakse failisüsteemi eraldi osasse, mida nimetatakse "ajakirjaks" või "logiks". Kui failisüsteemi muudatused on turvaliselt logitud, rakendab päevikuga failisüsteem need muudatused failidele või metaandmetele ja seejärel eemaldab need kirjed logist. Logikirjed on korraldatud seotud failisüsteemi muudatuste komplektideks, sarnaselt sellele, kuidas andmebaasi lisatud muudatused korraldatakse tehinguteks.

Ajakirja olemasolu suurendab failisüsteemi terviklikkuse säilitamise tõenäosust, kuna logifaili kirjed tehakse enne tegelike muudatuste tegemist ning neid kirjeid hoitakse alles seni, kuni need on täielikult ja ohutult rakendatud. Kui arvuti taaskäivitatakse, saab mounter garanteerida päevikusse salvestatud failisüsteemi terviklikkuse, kontrollides lihtsalt logifailis oodatud, kuid tegemata muudatusi ja kirjutades need seejärel failisüsteemi. See. kui päevik on olemas, siis enamikul juhtudel ei pea süsteem failisüsteemi terviklikkust kontrollima, mis tähendab, et arvuti on peaaegu kohe pärast taaskäivitamist töövalmis. Sellest tulenevalt vähenevad failisüsteemi probleemide tõttu andmete kadumise võimalused oluliselt.

Linuxis on saadaval mitu ajakirjandusega failisüsteemi. Neist kuulsaimad:

XFS, Silicon Graphicsi poolt välja töötatud, kuid nüüd avatud lähtekoodina välja antud ajakirjade failisüsteem;

ReiserFS, spetsiaalselt Linuxi jaoks loodud ajakirjanduse failisüsteem;

JFS, ajakirjanduse failisüsteem, mille algselt töötas välja IBM, kuid mis on nüüd välja antud avatud lähtekoodiga;

xt3 on ext2 failisüsteemi päevik, mida kasutab enamik GNU/Linuxi versioone. Ainulaadne funktsioon ext3 süsteemid - võimalus migreeruda sellele ext2-st ilma ketast ümber vormindamata. Disainitud dr Stephan Tweedie poolt.

OS-i perekonnas Microsoft Windows päevik sisaldab faili NTFS süsteem. Operatsioonisüsteemis Mac OS X – HFS+.

Ajakirjanduse olevik ja tulevik

Ajakirjastatud failisüsteemide definitsioone on palju, kuid anname kõigile arusaadava sõnastuse: päevikuga failisüsteem on süsteem neile, kes on programmist väsinud. fsck kontrollib allalaadimise ajal. See on ka süsteem neile, kellele on tõrketaluvusega süsteemide idee lähedal. Kui see pole õige, lülitage toide sisse tavaline süsteem kui logimist ei toimu, tuvastab OS selle fakti ja käivitab järgmisel alglaadimisel fsck ketta terviklikkuse kontrolli. See utiliit skannib failisüsteemi ja proovib probleeme andmeid kahjustamata lahendada. Kinnitusprotsess võib võtta üsna kaua aega. Mõnikord rikutakse failisüsteem nii tõsiselt, et OS käivitub ainult ühe kasutaja režiimis ja palub kasutajal teha täiendavat taastamist.

Ütle fsck

Mis veelgi hullem, operatsioonisüsteem saab failisüsteemi ühendamisel automaatselt käivitada fsck-protsessi, et veenduda metaandmete õigsuses (isegi kui viga ei olnud). Seega elimineerimine tarbetuid kontrolle failisüsteemi terviklikkus on märkimisväärne valdkond, mida tuleb parandada.

Nüüd teate, kes vajab päevikuga failisüsteeme, kuid miks ei vaja sellised süsteemid fsck-kontrolle? Ühesõnaga, sest nad peavad spetsiaalset päevikut. Ajakiri on fail, mis on helipuhver, kuhu salvestatakse kõik failisüsteemi muutmisega seotud toimingud. Neid muudatusi rakendatakse perioodiliselt failisüsteemile. Rikke korral saab logi kasutada lähtepunktina salvestamata andmete taastamiseks ja metaandmete riknemise vältimiseks.

Kokkuvõtteks võib öelda, et päevikuga failisüsteem on tõrkekindel failisüsteem, mille muutmiskäsud logitakse enne täitmist, mis aitab vältida metaandmete rikkumist. (Vt joonis 1). Nagu Linuxi puhul tavaliselt, on sellistest süsteemidest palju variatsioone. Heidame kiire pilgu failisüsteemide ajaloole ja seejärel täna saadaolevatele failisüsteemidele ja nende erinevustele.

Mis on metaandmed?

metaandmed helistas teenindusstruktuurid põhiandmete salvestamiseks vajalikud andmed. Toimingud, nagu faili ja kataloogi loomine ja kustutamine, faili laiendamine, faili kärpimine ja nii edasi, mõjutavad metaandmeid.

Joonis 1. Tüüpiline päeviku failisüsteem.

Linuxi ajakirjandusega failisüsteemide ajalugu

IBM® oli esimene, kes töötas välja päevikuga failisüsteemi nimega JFS (Journaled File System). JFS-i esimene versioon võeti kasutusele 1990. aastal ja tänapäevast versiooni säilitatakse Linuxis, kuna JFS2 arendati hiljem. 1994. aastal tutvustas Silicon Graphics suure jõudlusega faili XFS süsteem IRIX OS jaoks. 2001. aastal porditi XFS Linuxile. 1998. aastal töötati Amiga süsteemide jaoks välja failisüsteem. tark süsteem Failisüsteem (SFS), mis anti hiljem välja GNU vähema üldavaliku litsentsi (LGPL) all ja sai tuge Linux 2005-s. Kõige laialdasemalt kasutatav failisüsteem on ext3fs (inglise keelest. kolmas pikendatud failisüsteem ), mis on ext2 süsteemi laiendus, millele on lisatud ajakirjandus. Ext3fs-i tugi tutvustati Linuxis 2001. aastal. Lõpuks on laialdaselt kasutusele võetud ReiserFS-i ajakirjanduse failisüsteem avanud palju uusi arenguteid ja võimalusi. Selle süsteemi areng aga pidurdus selle autori juriidiliste probleemide tõttu.

Raie liigid

Kõik ajakirjanduse failisüsteemid peavad failisüsteemi muudatuste puhverdamiseks ajakirja (mida on vaja ka katastroofiabi), kuid selle kohta, mida ja millal logida, on erinevaid strateegiaid. Kolm levinumat strateegiat on tagasikirjutusrežiim, tellimisrežiim ja andmerežiim.

IN tagasikirjutamise režiim logitakse ainult metaandmeid ja andmeplokid kirjutatakse otse kettale. See aitab kaasa failisüsteemi struktuuri terviklikkusele ja kaitseb kahjustuste eest, kuid andmete riknemine on siiski võimalik (näiteks kui süsteemi krahh toimub pärast metaandmete kirjutamist ajakirja, kuid enne andmeploki kirjutamist). Otsustama täpsustatud probleem lubab tellimisrežiim. Selles režiimis logitakse ka ainult metaandmeid, kuid andmed ise logitakse enne metaandmete logimist. See tagab failisüsteemi andmete ühtsuse pärast taastamist. Lõpuks on võimalik sisse logida andmerežiim, mis logib nii metaandmed kui ka andmed ise. Sellel režiimil on kõrgeim vastupidavus andmete kahjustamise ja kadumise vastu, kuid selle puuduseks on aeglane jõudlus, kuna kõik andmed kirjutatakse kaks korda (kõigepealt logisse, seejärel kettale).

Logitud muudatuste rakendamise reeglid võivad erinevates lähenemisviisides samuti olla erinevad. Näiteks millal tuleks muudatusi rakendada? Millal ajakiri täis on? Või millal teatud aeg läbi saab?

Ajakirjastatud failisüsteemid täna

Tänapäeval kasutatakse aktiivselt mitut ajakirjanduse failisüsteemi, millest igaühel on oma eelised ja puudused. Allpool on neli kõige populaarsemat päeviku failisüsteemi.

JFS2

JFS2 (tuntud ka kui täiustatud ajakirjanduse failisüsteem) on esimene päevikuga failisüsteem ja pikka aega kasutati enne Linuxi teisaldamist operatsioonisüsteemis IBM AIX® OS. JFS2 on 64-bitine failisüsteem, mille juured on küll algsest JFS-ist, kuid mida on skaleeritavuse ja mitmeprotsessoriliste arhitektuuride toe osas oluliselt täiustatud.

JFS2 toetab järjestatud logimist, sellel on kõrge jõudlus ja taastumisaeg on vähem kui sekund. See kasutab jõudluse parandamiseks ulatusepõhist failide eraldamise meetodit. Ulatuspõhine jaotamine tähendab faili paigutamist mitmesse külgnevasse sektsiooni, mitte paljudesse identsetesse plokkidesse. Järjepidevuse tõttu võimaldavad need jaotised kiiremat lugemist ja kirjutamist. Ulatuste täiendav eelis on metaandmetega töötamise madalam hind. Faili paigutamisel plokkidesse salvestatakse iga ploki metaandmed. Kui kasutatakse ulatusi, siis muudetakse ulatuste metaandmeid, mis tavaliselt koosnevad mitmest plokist.

JFS2 kasutab mõlema jaoks ka B+-puid tõhus otsing kataloogide ja ulatuse kirjelduste haldamiseks. JFS2-l pole oma poliitikat kettale muudatuste tegemiseks, selle asemel põhineb see kupdate deemoni ajalõpul.

XFS

XFS on teine ​​​​varajane päevikufailisüsteem, mille töötas välja Silicon Graphics 1995. aastal IRIX OS-i jaoks. 2001. aastal juurutati XFS Linuxile, mis oli selleks ajaks juba hästi läbimõeldud ja töökindel failisüsteem.

XFS kasutab täielikku 64-bitist adresseerimist ja pakub väga suur jõudlus B+-puude kasutamise kaudu kataloogide ja failide paigutamiseks. XFS salvestab andmeid ulatustena, toetades muutuva ulatusega suurusi (512 baidist 64 kilobaidini). Lisaks ulatustele kasutab XFS laiska jaotust, mis lükkab plokkide eraldamist edasi, kuni on aeg need kettale kirjutada. See funktsioon suurendab mitme kettaploki järjestikuse täitmise tõenäosust, kuna nende arv on salvestamise ajal teada.

XFS-i muud huvitavad omadused on garanteeritud I/O kiirus, kui failisüsteemi kasutajatele eraldatakse reserv. ribalaius I/O operatsioonide jaoks ja otsene I/O, mille puhul andmed kopeeritakse otse ketta ja rakenduse puhvri vahel (mitte puhvri läbimise asemel). XFS-is päeviku kirjutamine toimub tagasikirjutamise meetodil.

Kolmas laiendatud failisüsteem (ext3fs)

Kolmas laiendatud failisüsteem (ext3fs) on kõige populaarsem ajakirjade failisüsteem ja see on arenenud välja tuntud failisüsteemist ext2. Tegelikult ühildub see ext2-ga, kuna see töötab identsete struktuuridega, kuid ajakirja lisamisega. Lisaks on võimalik ühendada ext3 partitsioon ext2-na või teisendada ext2 ext3-ks, kasutades utiliiti tune2fs.

ext3fs toetab kõiki kolme logimisstrateegiat ( Kirjuta tagasi, tellimis- ja andmerežiim), kuid vaikimisi on tellimisrežiim. Logiandmete kettale teisaldamise poliitika on konfigureeritav, kuid esialgu on see selline, et ülekanne toimub kas siis, kui logi on 1/4 täis või kui üks edastustaimeretest aegub.

Ext3fs-i üks peamisi puudusi tuleneb asjaolust, et see ei olnud algselt mõeldud päeviku failisüsteemiks. Kuna see põhineb ext2fs-il, puuduvad sellel paljud teistes failisüsteemides leiduvad progressiivsed funktsioonid (nt ulatus). Samuti töötab see tavaliselt halvasti võrreldes ReiserF-ide, JFS-i ja XFS-iga, kuid on vähem protsessori- ja mälumahukas kui paljud teised failisüsteemid.

ReiserFS

Mis on aheraine tihendamine?

Sageli juhtub, et failil on suurus väiksem suurus loogiline plokk. Selle asemel, et eraldada igale sellisele failile terve plokk, jätke osa plokist hõivamata (seda osa nimetatakse saba), püüavad nad ühte plokki mahutada mitu faili. See meetod annab 5% kasumi vaba ruum võrreldes teiste failisüsteemidega, kuid mõjutab jõudlust negatiivselt.

ReiserFS-failisüsteem loodi algusest peale päevikustamiseks. 2001. aastal lisati see 2.4 kerneli põhiharusse ja sellest sai esimene ajakirjanduse failisüsteem, mis ilmus Linuxis. Peamine logimisviis on tellimine. Toetab failisüsteemi suuruse suurendamist "lennult". ReiserFS toetab ka aheraine tihendamine killustatuse dünaamiliseks vähendamiseks, võimaldades sellel väikeste failidega töötamisel ületada ext3fs-i.

ReiserFS (nimetatakse ka ReiserFS v3) kasutab palju kaasaegsed lähenemised, näiteks B+-puud. Failisüsteemi formaat põhineb ühel B+ puul, mis muudab otsingutoimingud eriti kiireks ja skaleeritavaks. Logist kettale migratsioonipoliitika sõltub logi suurusest ja põhineb migreerimist vajavate plokkide arvul.

ReiserFS-i mainet on mitu korda kahjustatud: viimane kord- süsteemi autori probleemid seadusega (vt täpsemalt jaotisest).

Ajakirjastatud failisüsteemide tulevik

Nüüd, kui oleme vaadanud mineviku ja mineviku failisüsteeme, heidame pilgu sellele, mida tulevik toob (ja mis mitte).

Reiser4

Pärast ReiserFSi edukat juurutamist kernelisse ja selle kasutamist paljudes distributsioonides Linuxi ettevõte Namesys (kes on ReiserFS-i taga) on alustanud tööd uue ajakirjanduse failisüsteemi Reiser4 kallal, mis ehitati täiesti nullist ja sisaldab palju täiustatud funktsioone.

Parem ajakirjandus Reiser4-s saavutatakse juhuslike kirjutiste kasutamise ja plokkide viivitatud jaotamise kaudu, kuni logiandmed on migreeritud (nagu tehti XFS-is). Reiser4 arhitektuur pakkus pluginatele paindlikku tuge (näiteks tihendamise või krüptimise funktsioonide lisamiseks), kuid Linuxi kogukond lükkas selle idee tagasi, kuna arvas, et need täiustatud funktsioonid peaksid olema virtuaalses failisüsteemi alamsüsteemis (VFS).

Pärast süüdistuse esitamist Namesysi omanikule ja samal ajal ka ReiserFSi autorile peatati kogu Reiser4 ümber käiv äritegevus.

Neljas laiendatud failisüsteem

Neljas laiendatud failisüsteem (ext4fs) on ext3fsi edasiarendus. Ext4fs loodi ext3fs-i asendajana, millel on otsene ja tagasiühilduv, kuid sisaldab palju täiustusi (mõned neist rikuvad selle ühilduvuse). Praktikas on võimalik ext4 partitsioon paigaldada ext3-na ja vastupidi.

Esiteks on ext4fs 64-bitine failisüsteem, mis toetab tohutuid mahtusid (kuni 1 eksabait). See võib kasutada ka ulatust, kuid sel juhul kaob ühilduvus ext3fs-iga. Sarnaselt XFS-ile ja Reiser4-le lükkab ext4fs kettale plokkide eraldamise edasi ja toimub vastavalt vajadusele (mis vähendab killustumist). Ajakiri säilitab ka kontrollsummad sisu suurema usaldusväärsuse tagamiseks. B+- või B*-puude asemel kasutatakse spetsiaalset B-puud, nn. H-puu, mis võimaldab alamkataloogidel olla palju suurem suurus(ext3-s on see piiratud 32 Kb-ga).

Kuigi laisk eraldamine vähendab killustumist, aja jooksul failisüsteem suur suurus endiselt killustatud. Selle probleemi lahendamiseks töötati välja utiliit e4defrag, mida saab kasutada defragmentimiseks üksikud failid või kogu failisüsteemi.

Teine huvitav erinevus ext4fsi ja ext3fsi vahel on faili ajatempli täpsus. Ext3-s on ajatempli ühik üks sekund. Ext4fs vaatab tulevikku: kuna protsessori kiirused ja liidese kiirused kasvavad jätkuvalt, on vaja täpsemat mõõtmist. Seetõttu võeti ajamõõtmeks üks nanosekund.

Kuigi ext4fs on lisatud Linuxi kernel versioonis 2.6.19 võib seda juba stabiilseks pidada. See alles väljatöötamisel olev süsteem on lähtepunktiks Linuxis tuleviku ajakirjanduse failisüsteemi loomisel.

Edasi liikudes

Ajakirjaga failisüsteemid pakuvad töökindlust ja kaitset andmete riknemise eest süsteemi krahhi või voolukatkestuse korral. Lisaks on taastumisajad sellistes süsteemides palju kiiremad kui traditsioonilistes failisüsteemides (näiteks need, mis kasutavad fsck-d). Uute logimismeetodite väljatöötamine põhineb nii JFS-i ja XFS-i varasematel kogemustel kui ka uute algoritmide ja struktuuride otsimisel. Ei ole päris selge, kuidas päevikustatud failisüsteemid tulevikus arenevad, kuid nende kasulikkus on selge ja neist on juba saanud failisüsteemide uus standard.

Kell tavaline töö failisüsteemis tehakse kõik muudatused tavaliselt kohe kettale (õigemini OS-i ketta vahemällu, kuid see pole selles kontekstis oluline).

Paljud toimingud nõuavad mitme failisüsteemi struktuuri samaaegset muutmist ( metaandmed. Lihtne näide: kõvalingi loomisel tuleb korraga suurendada inode linkide arvu ja muuta selle kataloogi sisu, kuhu link tehakse.Neist toimingutest ei saa teha ainult ühte – failisüsteemi sisu on vale.

Tavalise failisüsteemi töötamise ajal tehakse selline keeruline toiming alati tervikuna, välja arvatud juhul, kui failisüsteemi juurutuskood sisaldab kriitilisi vigu. Kuid ebanormaalse taaskäivituse ajal või riistvara rike see olukord on väga reaalne.

Kuna pärast taaskäivitamist me ei tea, milliseid toiminguid tehti, mis oli puudulik ja teame ainult seda, et ketast ei eemaldatud õigesti (nn määrdunud lipp lähtestatakse), siis peame analüüsima kogu failisüsteemi. kettale ja seega tuvastage failisüsteemis kõik vead ja parandage need. Loomulikult pole kaugeltki alati võimalik seda automaatselt teha (ebaloomulik intelligentsus, paraku pole keegi veel suutnud selgeltnägija võimeid õpetada), seetõttu võib sama fsck.ext2 pärast ebanormaalset taaskäivitamist vajada käsitsi sekkumist.

Need, kes kasutasid fsck-d 100-200 G partitsioonil (mis pole tänapäeval sugugi haruldane), teavad hästi, et sellest on vähe rõõmu. Mitme terabaidise massiivi administraatorid, mille lisaminuti seisaku eest võivad nad sõna fsck peale “kogemata” peast rebida, palderjani haarata või paluda neil nende juuresolekul selliste sõnadega mitte vanduda.

Selle probleemi lahendamiseks leiutati juba ammu geniaalne idee (kui keegi teab millal ja kelle poolt - öelge palun) - Esiteks kirjutage kettale kavandatud toimingu kirjeldus ja alles seejärel käivitage. Siis on võimalik mitte kogu ketta õigsust testida, vaid vaadata ainult logi sisu ja kui toimingut ei lõpetatud, kerige see tagasi. Selleks ei pea te fsck-d käivitama – seda teeb failisüsteemi draiver ise.

Kokkuvõtteks võib öelda, et ainus asi, mida päeviku failisüsteem saab ja peaks tegema, on säästa fsck aega. Sellest lähtuvalt on failisüsteemi metaandmete järjepidevus tagatud, ei rohkem ega vähem.

Selle naudingu hind: meil on väike (tavaliselt mõõdetakse kümnetes megabaitides) kettapindala, mis moodustab maksimaalne koormus, see on maksimaalne jõudlus, mõõdetuna i/o operatsioonide arvuna sekundis, langeb. Ja loomulikult kulub natuke kettaruum et plaatide hindade ajastul< 1$/гигабайт никого не волнует.

Andmete logimine

Nagu märkasite, kirjutatakse metaandmetega toimingud tavaliselt logisse. Kuid sama saate teha andmetega.

Minu teada saab Linuxis ainult ext3 teha andmepäevikut parameetriga data=journal.

Loomulikult vähendab andmete logimine paljudel juhtudel mõnevõrra jõudlust (kuid mitte kõik, IBM-i veebisaidil on testitulemused, mille kohaselt võib andmelogimise kasutamine failisüsteemide jaoks, millel andmebaasid asuvad, jõudlusele isegi tõuke anda).

See tööriist ei taga ka andmete turvalisust, aga minu isiklik kogemus ext3 kasutamine koos data=journaliga on kõige usaldusväärsem failisüsteem.

Esitus

Tähelepanelik lugeja on kindlasti märganud, et ajakirja kasutamine on kettale ebaühtlase koormuse tekitamine – üks väike (võrreldes failisüsteemi kogumahuga) ala moodustab ebaproportsionaalselt palju toiminguid.

On kaks väga huvitavat lahendust:
Esiteks saate logi teisaldada eraldi kettale (enamik failisüsteeme lubab seda), mille tulemusena me tegelikult kahekordistame jõudlust, lisades vaid ühe ketta. See näeb eriti kena välja, kui tohutu RAID-massiivi jõudlust nii lihtsal ja odaval viisil suurendatakse.

Teiseks võite kasutada spetsiaalsed kaardid püsimälu (näiteks UMEM, mida ma kahjuks pole Venemaal müügil näinud), mis on ka märgatavalt kiiremad kui tavalised kettad (kuid on väikese mälumahuga).

On ka täiesti ekstravagantne lahendus, mida ma pole veel proovinud - teha päevik mälus asuvale plokkseadmele. Muidugi tuleb pärast taaskäivitamist selline failisüsteem uuesti luua, kuid ajutiste andmete puhul võib see anda huvitava ja märgatava jõudluse tõusu. Eriti andmete, mitte ainult metaandmete logimisel.

Trikid

Nagu juba nägite, võib ajakiri anda ka kiiruse tõusu. On veel mõned geniaalsed nipid, mida ajakirjanduse failisüsteem saab kasutada jõudluse veelgi suurendamiseks:

• edasilükatud faililoome (faili loomise ajal ärge looge koheselt kataloogi kirjet, vaid hoidke seda mõnda aega ainult logis, fail võib olla ajutine ja kustutatakse kohe);

• viivitatud failijaotus (ärge eraldage füüsiliselt ruumi isegi faili esimesele plokile enne, kui on vaja kirjutada vähemalt üks plokk), on täiesti võimalik, et kasutaja muudab esmalt faili suurust ja alles siis hakkab andmeid kirjutama. Selle tulemusena väheneb killustatus (kui programmid seda nippi kasutavad);

Need on kõige lihtsamad, seal on palju rohkem väikseid nippe, mis võimaldavad ajakirjaga failisüsteemil tavalisest kiiremini töötada, jäädes samas töökindlamaks.

Puudused

Nagu ma ütlesin, logi ei ole imerohi ja andmed ei salvesta üldse. Paljude jaoks loob aga päevikuga failisüsteemide kasutamine vale turvatunde - kuidas saate lõppude lõpuks taaskäivitada masina lähtestamisega ja see ei vannu isegi käivitamisel!

Jah, see ei kõiguta. Ja see on mõne seisukohast täiesti õige fsck fail süsteem. Ainult siin andmetest korraga, ainult tükid võivad alles jääda.

Oletame, et sellistes olukordades võivad reiserfid jätta muudetud failidesse prügi (suvalised andmed, mis olid faili jaoks eraldatud plokis). Mis tegelikult tähendab väga tõenäolist juhuslikku infoleket.

XFS toimib korrektsemalt - see määrab sellised nullidega plokid. Mis sageli šokeerib kasutajaid. Eriti reiserfide fännid, kes ei kirjuta ette nullidega.

Sellest tulenevalt on reiserfs pigem salvestada muudatusi ja XFS teeb kõik endast oleneva, et vältida failide prügi ja andmelekkeid – lihtsalt veidi erinevad strateegiad. Tulemus on sama – andmed võivad kaduda ja te ei saa sellest isegi teada. Kuni satute faili, mida keegi pole aasta aega puudutanud (see oli arhiivis) ja mis ootamatult osutus prügi või nullidega ummistunud.

ext3, mille andmete logimine on lubatud, selliseid funktsioone ei kannata. Kuid see kaotab jõudluses märgatavalt.

Heas mõttes saab (ja tuleks) kõiki neid probleeme vältida lihtsalt UPS-i ostmisega ning päeviku pidamist on parem kasutada täiendav tase töökindlus ja tootlikkuse suurendamine.

Tulemus

Päevikufailisüsteem teeb haldamise veidi lihtsamaks, kuid see pole nii maagiline vahend andmete kadumise vastu ebanormaalsete taaskäivituste ajal. Seega, kui te UPS-i ei kasuta ja Backupit ei tee, siis varem või hiljem kaetakse teie andmed vaskbasseiniga, mida ma teile siiralt EI soovi. Ja kui soovite, saate jõudluse suurendamiseks kasutada failisüsteeme ajakirjanduses.

Kes ostis UPS-i ja varundamine muudab Togo andmed alati puutumatuks

(C) Deniss Smirnov 5. november 2004
Selle dokumendi paigutamine muudesse Interneti-ressurssidesse ja ka trükitud väljaannetesse ei ole lubatud.

See ülevaade käsitleb üksikasjalikult küsimusi, mida viimases artiklis pealiskaudselt käsitleti või mis puudusid üldse. Tahaksin kohe öelda, et NT-kettasüsteem on nii keeruline, et võime sellest rääkida üsna pikka aega - ja see artikkel ei kirjelda kõike, mida võiks öelda. Nii et see on lihtsalt katse vastata kooskõlastatult ja üksikasjalikult kõigile eelmise postituse poolt tõstatatud küsimustele. 4. osa: NTFS-i ajakirjandus

Selle lihtsa tõsiasja kirjeldus, et NTFS on päevikusüsteem, on paljud teiste faili- ja operatsioonisüsteemide fännid tekitanud siirast nördimust. Paljud mulle adresseeritud e-kirjad on viitanud NTFS-ile kui peaaegu ajakirjade koostamise või isegi mitte-ajakirjade kirjutamise süsteemile, mitte mitmele failile Unixi süsteemid. Sain ka palju kirju, mis viitasid saatuslikele NTFS-i krahhidele, millest ei olnud võimalik taastada – andmed läksid kaduma. Selles osas püüan oma võimaluste ja mõistmise piires selgitada ajakirjanduse ja NTFS-i krahhikaitse filosoofiat, samuti selgitada surmaga lõppevate krahhide põhjuseid. Püüan õigustada Microsofti lähenemist teha seda täpselt nii, nagu ta tegi – vähemalt toon välja ellu viidud tehnoloogiaotsuste põhjused ja kompromissid, mida NTFS-i arendusmeeskond pidi tegema.

Logitud toimingud

Kõigepealt tahaksin rääkida sellest, milliseid toiminguid täpselt logitakse. On üsna ilmne, et täielik tagasivõtmisfail, mida saab tagasi pöörata kõike toimimine on absoluutselt võimatu nii kiiruse kui ka terve mõistuse seisukohalt. Jah, selline logimine võimaldaks taastada rohkem andmeid - näiteks faili keskel kolme megabaidi ülekirjutamisel saaksime esmalt uued andmed logisse salvestada, seejärel faili eelmised kolm megabaiti sinna ümber kirjutada ja alles seejärel tehke toiminguid reaalsete andmetega. Selline lähenemine tagaks täieliku kindluse info saatusega – saaksime alati aru, milline osa andmetest on juba kettale kirjutatud ja milline on algses, uuendamata olekus. Sellel on ainult üks tagasihoidlik puudus - kiiruse osas väike lisakulu: kolme megabaidi kettale kirjutamiseks peame kolm korda suurema mahu jaoks - üheksa megabaidi - tegema erinevaid kettatoiminguid. jah, täielik kasutatakse ka logimist – aga enamasti andmebaasidega töötamisel. Kui soovite mis tahes andmete täielikku logimist, võite installida MS SQL-i või isegi Oracle'i, mis ei kasuta üldse ühegi failisüsteemi võimalusi ja tagab teie andmete ohutuse mis tahes mõistlikel tingimustel. Failisüsteemi täieliku ajakirjanduse toetajatele võin vastata ühele: otsus vähendada kirjutamisoperatsioonide kiirust kolm korda on minu arvates liiga julge, et olla kohustuslik - nii koduarvutites kui ka serverites.

NTFS-i arendajate lähenemine oli põhimõtteliselt erinev. Peamine moto oli ilmselt mitte "usaldusväärsus iga hinna eest", vaid "toimivuse püsivus". Logimine on lihtne ei peaks oli segada failisüsteemi. Esimene loogiline samm on täieliku metsaraie kaotamine, kuna see on jõudluse seisukohast täiesti vastuvõetamatu. NTFS kasutab ajakirjandust loogilised struktuurid, mitte kasutajaandmed – siit ka lause, et ohutus andmeid ei ole garanteeritud, kuid süsteemi enda õige olek säilib siiski. Asjaolu, et NTFS ei salvesta andmeid, viib praktikas ühe andmekao variandini - sama hüpoteetilise kolme megabaidi kirjutamise puhul ei ole kirjutamisprotsessi tõrke korral kunagi võimalik kindlaks teha, milline osa andmed kirjutati ja mis jäid muutumatuks. Operatsioonid, mida süsteem siiski logib, on toimingud süsteemi enda struktuuridega, st failide ja kataloogidega: failide lisamine, ümbernimetamine, teisaldamine, loomine ja kustutamine (vaba ruumi vabastamine). Logitakse ka defragmentimistoiminguid – see tähendab failifragmentide liikumist. Ühesõnaga kõike ajumäng toimingud logitakse.

Laisk kirjutamise ja logimise kontrollpunktid

On teada, et iga kaasaegne süsteem kiirendamiseks failitoimingud sunnitud kasutama vahemällu, sealhulgas kirjutamistoimingute vahemällu. Nn laisk kirjutamine on vahemällu salvestamise põhimõte, mille puhul kettale kirjutamiseks mõeldud andmeid hoitakse mõnda aega vahemällu ja füüsiliselt hoitakse neid ainult muudest tegevustest vabal ajal. Hiline kirjutamine parandab oluliselt tõhusust kettatoimingud, kuna selline vahemällu salvestamine koondab palju toiminguid ühte – see on eriti tõhus, kui salvestamine toimub ketta kompaktsetel aladel. Laisa kirjutamise eeliseks on ka see, et need ei sega rohkem vajalikku lugemist ja kirjutavad ainult siis, kui süsteem on vaba ja ei vaja muuks otstarbeks juurdepääsu kettale. Kuidas ühitada hilinenud kirjutamist päeviku pidamisega? See on üsna keeruline küsimus, nagu seda teeb kirjutamise edasilükkamine võimalik kaotus need andmed, mis olid füüsilises kirjutamisjärjekorras ja mida polnud enne riket aega kettale kirjutada. Kõige ebameeldivam pole siin isegi mitte andmete kadu, vaid asjaolu, et salvestusajas on lahknevus: mõnda teeninduspiirkonda saab värskendada ja mõnda on tähendusega seotud - veel mitte, kuna nende värskendamine võib mõne teise jaoks viibida. paar sekundit ja seda tõrke tõttu ei toimu.

NTFS lahendab need probleemid laiskade kirjutamiste ja ajakirjanduse sisulise integreerimisega. Kui proovite käivitada logitud toimingut, kirjutatakse kavatsus kohe logisse – näiteks faili kustutamiseks. See juhtub viivitamata - praeguses etapis laisk kirjutamine ei tööta: see on metsaraie olemasolu hind, mida ei saa vältida. Kuid kõik muud toimingud juba käivad viivitatud režiimis - see tähendab, et need võivad toimuda osaliselt (võib-olla lisaks ja vales järjekorras) või üldse mitte. Ainus viivitatud toiming, mille toimimine erineb mõnevõrra lihtsast kirjutamisest, on varasemate tehingute edukast sooritamisest logisse kirjutamine, nn. kontrolli punkt. Regulaarsete ajavahemike järel – tavaliselt iga paari sekundi järel – peab süsteem kettale loputama absoluutselt kõik pooleliolevad toimingud. Pärast selle toimingu sooritamist kirjutatakse logi lihtsaim märge- kontrollpunkt - mis seda ütleb Kõik eelnevad toimingud sooritati korrektselt kõigil tasanditel – nii loogilisel kui füüsilisel.

Selline töörežiim – arvestuste ja kontrollpunktide abil – ühelt poolt annab siiski täieliku garantii õige töö metsaraie ja teisest küljest praktiliselt absoluutselt ei aeglusta tööd: kontrollpunktide seadistamine on tehtud, kaaluge, koheselt ja toimingu alguse kohta logisse kirjutamine vastab tööjõukuludelt andmete enda kirjutamisele ilma edasilükatud vahemällu salvestamiseta. Tõeline salvestamine, mis tehakse hiljem, ei sega enamikul juhtudel ühtegi toimingut ega kahjusta süsteemi jõudlust.

Hilinenud logimisprobleemid: dubleeriva teabe kontseptsioon

Kõik ülaltoodud teooria on piisavalt hea, kuid see võib siiski põhjustada väga ebameeldivaid tagajärgi, kui te ei võta arvesse veel mõnda asja, millest arutatakse.

Mõelge sellele juhtumile: me kustutame faili. Logi sai kirje - "fail N kustutatakse." Seejärel otsustas mahajäänud vahemälu esmalt füüsiliselt märkida, et faili poolt hõivatud ruum on vabanenud, ja alles seejärel eemaldada fail MFT füüsilistest struktuuridest ja kataloogist. Oletame, et ketas on aktiivses töös ja vabanenud ruumi kirjutatakse kohe teine ​​fail. Sel hetkel see jookseb kokku. Süsteem uurib laadimisel logi ja näeb lõpetamata toimingut "fail N kustutatakse" - või õigemini, nagu ma eespool kirjeldasin, mitte lõpetamata, vaid lihtsalt toiming, mille järel pole kontrollpunkti, mis näitab automaatselt selle mittetäielikkust. . Järgmine faas oleks "tagastusoperatsioon" - st faili taastamine. Üks halb õnn – faili füüsiliselt hõivatud koht sisaldab juba muid andmeid.

Selliste olukordade vältimiseks on süsteem, mis soovib piirduda loogilise logimisega, sunnitud rakendama „ajutiselt hõivatud ruumi” põhimõtet. Ükskõik millise objekti või seda puudutava kirje vabastatud ruum ei kuulutata vabaks enne, kui kõik loogiliste struktuuridega toimingud on füüsiliselt lõpetatud. See mehhanism NTFS-is pole seda ilmselt sünkroonitud isegi kontrollpunktiga, kuna tüüpiline aeg ajutiselt hõivatud ruumi vabastamiseks on umbes 30 sekundit, kuid punktid lähevad sagedamini.

Seda mehhanismi ei kasutata mitte ainult faili kustutamisel, vaid ka mitmesuguste toimingute jaoks: logimise põhimõte - eemaldatud või uude asukohta teisaldatud objekt peab suutma oma "lahkumist" - st viidatud andmeid - õigesti tagasi pöörata. kustutatud või teisaldatud objekti loogiliste struktuuride tõttu on vaja mõnda aega reserveerida kasutatud ruumina (ketas / kataloog). See on järjekordne NTFS-i samm täieliku ajakirjanduse suunas, kus konkreetne päevik faili teave teenivad vabastatud alade endi andmed, mida füüsiliselt ei hävitata.

Noh, te ütlete, kõik on nii imeline - aga miks siis NTFS-i partitsioonid ikkagi lendavad? .. Nüüd proovin selgitada põhimõtteid, mis viivad selleni, et ülaltoodud mudel suudab pakkuda loogiliste struktuuride täielikku taastatavust.

• kõvaketas, sisse tavaline mood, peab kirjutama täpselt, mida ja kuhu operatsioonisüsteem käskis kirjutada. Seda põhimõtet rikutakse, kui süsteemis on ebausaldusväärne silmus, protsessor, mälu või kontroller - ja see on NTFS-i tõrgete kõige levinum põhjus. See aitab teil: mitte-ülekiirendatud protsessor, kallis (kvaliteetne) mälu, hea emaplaat ja UDMA-protokoll, mis võimaldab kontrolleri-ketta sektsioonis juhtimist ja vigade taastamist.
• Kõvaketas õnnetuse, voolukatkestuse või kontrollerilt lähtestamise signaali saamisel (äkilise taaskäivituse korral emaplaat) peab korrektselt lõpetage voolu andmete salvestamine füüsiline sektor kui see oli õnnetuse ajal kasutusel. Sektori vaheriik ei ole lubatud. Sind aidatakse kaasaegsed kõvakettad, mis suudab seda toimingut teostada ka täieliku voolukatkestuse korral - neil on kondensaatorites piisavalt energiat puhverdatud ning nende loogika on loodud kirjutamisel voolukatkestuse korral korrektselt käituma.
• Ketas on kohustatud viivitamatult kirjutama lipuga "ära vahemällu" saadetud andmed. Fakt on see, et paljud kaasaegsed kettad või kontrollerid pakuvad viivitusega salvestamist. NTFS-metafaile värskendatakse "kirjuta korraga" režiimis ja kontroller/ketas peab sellele nõudele vastama.
• HDD peab tagamaks, et loetakse täpselt need andmed, mis kirjutati. Kui andmeid ei saa lugeda, antakse välja "vea" signaal. Ketas pole õigust tagastada vigased andmed (võib-olla ainult osaliselt valed) ilma veasignaalita. Kõik kaasaegne jäik ketastel on sektori kontrollsummad ja need järgivad rangelt seda käitumisloogikat.

Nende nõuete täpne täitmine täielikult tagab NTFS-i usaldusväärse töö. Failisüsteemi struktuur ei sisalda olulisi vigu isegi pärast krahhi. Mõned väikesed vead ilmnevad endiselt, kuna logiloogika püüab sageli lõpetada lõpetamata toiminguid - näiteks sama faili kustutamist -, kui täielik usaldusväärsus tagaks ainult kõige tingimusteta tagasipööramise pärast viimast kontrollpunkti. Väikesed ebakõlad, mis nendest katsetest välja tulevad, on üleliigne turvateave ega kujuta andmetele tegelikku ohtu – need on tõesti väikesed. Nende ebakõlade olemus seisneb enamasti selles, et kettal on “lisandmed” nende juurdepääsurežiimide kohta, mida süsteem enam ei vaja. Nende puhastamine on puhtalt jõudluse parandamise küsimus, nagu defragmentimine, nii et nende olemasolu pole tegelikult viga. Tõsiste, tõeliste probleemide tuvastamisel seab draiver ise helitugevuse lipu "määrdunud", mis annab süsteemile korralduse järgmisel paigaldamisel helitugevust kontrollida.

Pean kahetsusega tõdema, et valdav enamus fataalseid NTFS-i tõrkeid on põhjustatud riistvarast, mis neile põhinõuetele ei vasta. Jah, ma saan aru, et absoluutset usaldusväärsust pole olemas. Kuid Microsoft valis tööjaotuse – ettevõte ei vastuta teie seadmete töökindluse eest. Minu arvuti on Windows 2000-ga ühilduva riistvara nimekirjast 70% soodsam ja sama võib öelda peaaegu kõigi endises NSVL-is töötavate masinate kohta. See kehtib eriti nende kohta, kellele meeldib arvuteid kiirendada. Pidage meeles üks kord ja kõik: suure tõenäosusega rikute NTFS-i esimesel tööaastal, kui teie protsessor on 333, kiirendatud 415 võrra. Ja isegi rohkem kui üks kord ... Vabandust, aga see on tõesti nii. Igast ebaõnnestumisest õige NTFS kaitseb arvutit, kuid süsteemi juhuslike andmete kirjutamise eest alglaadimissektorisse (mille koopia, muide, salvestatakse partitsiooni lõpus) ​​ja MFT-s. ei ole kindlustatud. Vabandust, 5. osa. Tarkvara RAID

Nagu varem mainitud, ei ole NTFS-i päevikupidamine sugugi garanteeritud kasutajateabe kadumisest tulenevate tõrgete eest. Samal ajal pakub NT mitmeid võimalusi süsteemide loomiseks, kus mõistlikel tingimustel on absoluutselt kõik garanteeritud. Võite kasutada ka suuremat arvu kettaid, et mitte suurendada töökindlust, vaid vastupidi, suurenenud kiirus- või mõlemad korraga. Selliseid konfiguratsioone käsitletakse artikli selles osas.

RAID (redundant Array of Inexpensive Disks) on üleliigne odavate ketaste massiiv. Tehnoloogia, mis samaaegne kasutamine mitu kettaseadmed töökindluse või kiiruse omaduste pakkumiseks, mis pole üksikute draividega saadaval.

Windows NT toetab kolme RAID-i taset tarkvara tasemel (nn operatsioonistrateegiad kettamassiivid), lühikesed omadused mis on kokku võetud järgmises tabelis.

Vaatame lähemalt igat tüüpi RAID-i.

RAID 0 (paralleeldraivid)

See strateegia keskendub puhtalt tootlikkuse parandamisele. Mitu ketast salvestab kettastruktuuri osi, mis kogutakse ühte köitesse ainult siis, kui kõik massiivi kettad on olemas.

Algloomad RAID juurutamine 0 kahest, näiteks kettad – see näitab, et köite iga esimene sektor (või muu teabehulk) asub füüsilisel kettal A ja iga teine ​​kettal B. Selline jäik strateegia võimaldab vältida mis tahes täiendavad struktuurid teabe salvestamiseks andmete asukoha kohta. Lugemiskiirus ja kirjutamiskiirus on võrdsed ja sõltuvad ketaste arvust:

• Juhuslikult paiknevate andmetega töötamise toimingute kiirus sõltub järgmisest skeemist: kõik sõltub tõenäosusest, et ketas, millele tahame järgmise teabe kirjutada, on vaba ja valmis meie taotlust viivitamatult täitma. Näiteks kahe ketta RAID 0: kui üks ketastest sooritab toimingu ja täiendav käsk kettasüsteemiga töötamiseks on tõenäosus, et peame käsu täitmiseks häirima hetkel vaba ketast, 50% – see vastab üldisele jõudluse kasvule juhuslikud toimingud poolteist korda. Kui kasutatakse näiteks kümnest kettast koosnevat massiivi, on tõenäosus, et mis tahes toiming satub juba hõivatud kettale, vaid 10% - see tähendab, et jõudlus suureneb üheksa korda. Range tõenäosusteooria austajatele tahan märkida, et sellised arvutused ei võta arvesse mõningaid tegureid päris töö süsteemid, kuid numbrid on sellegipoolest just sellises järjekorras.
• Järjestikused toimingud – järjestikuste lõikude lugemine või kirjutamine – on peaaegu alati n korda kiiremad kui eraldi füüsilisel kettal, kus n on ketaste arv komplektis. See juhtub seetõttu, et vaba ketta tabamise tõenäosus järgmises toimingus on 100% - toimingud tehakse ju järjestikustes plokkides, mis on ketaste vahel ühtlaselt jaotatud.

Kokkuvõtteks võib öelda, et RAID 0 suurendab igal juhul oluliselt lineaarsete toimingute kiirust ja komplektis olevate ketaste arvu suurenemisega suureneb oluliselt ka juhuslike andmetega töötamise kiirus. Sest tõhus töö RAID 0 režiimis kettasüsteemiga on multitegumtöötluskontrolleri toimimine lihtsalt vajalik ja isegi eelistatavalt erinevad kontrollerid, mis pakub juurdepääsu erinevatele ketastele. Eeltingimus selline töö edasi IDE liidesed on Bus-Masteringu juhid. Windows 2000-l on sisseehitatud draiverid, mis lubavad selle režiimi automaatselt kõigi tavaliste IDE-kontrollerite jaoks, kuid NT4 puhul võib vaja minna lisadraiverid või registrivõtmete muutmine.

RAID 0 töökindlus on madal – iga ketta rike on fataalne rike, nagu ka draivi rike tavaliste partitsioonide puhul.

Süsteemi tõrke tõenäosus tervikuna ainult suureneb - mida rohkem kettaid kasutate, seda suurem on vähemalt ühe neist rikke tõenäosus ja sellest tulenevalt ka mõne mahuandmete osa kadumine.

RAID 1 (peegeldraivid)

Lihtsaim viis andmete turvalisuse tagamiseks on teha kahest kettast koopia. Kirjutamine toimub korraga mõlemale kettale, mis aeglustab seda protsessi, samal ajal kui lugemine toimub parajasti vabal kettalt – kui muidugi süsteem suudab sellist lugemist efektiivselt sooritada (vajalik on Bus-Mastering). NT-s rakendatud algoritm pole kahjuks päris optimaalne ja toob kaasa lugemisjõudluse märksa tagasihoidlikuma tõusu.

RAID 1 tolli keerukusest programmi režiim seisneb selles, et sageli ei saa süsteem kahe ketta andmete identsuses täiesti kindel olla. Kahe füüsilise ketta ühildamine pärast tõsist riket võib võtta tunde ja olla väga sobimatu, seega peaksite tarkvara RAID 1 kasutamisel olema väga ettevaatlik. Kui otsustate töökindluse huvides kettamassiive mitu korda suurendada, peate võib-olla ostma riistvara RAID-kontroller, mis lisaks tagab ebaõnnestunud ketaste asendamise liikvel olles ja jälgib andmete sünkroonimist ise.

Igal juhul ei põhjusta isegi ühe ketta täielik rike andmete kadumist, kuna kettad on täielikult peegeldatud.

RAID 5 (pariteediga paralleelsed kettad)

See strateegia näib praegu olevat kõige edukam ja tõhusam RAID-i toimimise skeem, mis koosneb kolmest või enamast kettast. Infot täiendatakse nn paarsusandmetega, mis asuvad teisel füüsilisel kettal kui selle infoga juhitavad tegelikud andmed.

Pariteedi mõistet saab mõista näiteks nii: oletame, et meil on viis bitti – näiteks hulk (0, 1, 1, 0, 1). Moodustame selle reegli järgi teise biti - paarsusbiti, kuuenda -, kui eelnevate viie bittide arv on paaris, võrdub see 1-ga, kui mitte, siis on see 0. Meie puhul on üheliste arv võrdub kolmega, st paaritu arv - meie hulk liidetakse arvuga 0 ja muudetakse (0, 1, 1, 0, 1, ).

Oletame, et andmekogum on kahjustatud – (0, X, 1, 0, 1, ). Reegliga, mis ütleb meile, et 1-de arv peab olema paaritu (viimane bit), võime arvata, et X oli 1. Meie tulemuseks olev kuuest bitist koosnev komplekt (5 andmebitti ja 1 paarsusbitti) on üleliigne ja suudab arukalt korrigeerida ükskõik millise kuue biti kadu.

Pariteeditehinguid saab sooritada mitte ainult bittide, vaid ka mistahes andmemahuga, mida kasutatakse kõige lihtsamates andmetaastealgoritmides.

Tagasi RAID 5 seadmesse:

Joonisel on kujutatud viiest kettast koosnev massiiv. On näha, et igal kettal on neli (tingimuslikku) reaalset andmete tükki ja üks paarsusandmete plokk. Paarsusühik – ütleme 0 paarsus – suudab taastada ühe fragmendi – mis tahes peale ühe – kaotuse A0, B0, C0 ja D0 hulgast. Koos suudavad nad omakorda taastada 0-paarsuse ploki. Kujutatud RAID-struktuurist on näha, et kogu veeru täielikuks taastamiseks vajalikud andmed – st mis tahes ketta teave rikke korral – asuvad teistel ketastel. Selles seisnebki taastamine - andmete kirjutamisel ükskõik millisele kettale uuendatakse ka praegusele plokile vastava teise ketta paarsusplokki (näiteks A2-le kirjutades uuendatakse ka ploki 2 paarsust). Tervelt kettalt andmete lugemine toimub ilma paarsusplokke kasutamata, st peaaegu samas režiimis kui RAID 0. RAID 5, nagu see on realiseeritud NT-s, on isegi veidi kiirem kui RAID 0.

Ainus lisakulu - tõrke korral väheneb massiivi jõudlus tohutult palju kordi, kuna kui näiteks D4 pole võimalik otse lugeda, on vaja selle ploki andmed taastada kasutades kõiki teisi kettaid samal ajal - meie puhul on need plokid 4 paarsus, B4, C4 ja E4.

Nagu näete, ebaõnnestus üks RAID-draivid 5 on, kuigi mitte surmav, kuid tõsine hädaolukord – vähemalt massiivi kiirlugemise põhjustel. Samuti on lihtne ära arvata, kust tuleb vähemalt kolme draivi nõue – kahe draivi puhul RAID 5 lihtsalt mandub RAID 1-ks, kuna ainus viis loendi paarsusteabe loomine ühest elemendist tähendab selle elemendi kuidagi dubleerimist.

Usaldusväärsuse eeldused

Kuidas, jälle? Jah, veelkord – RAID pole ka imerohi absoluutselt kõikide riistvarahädade vastu. Pean ütlema mõnede inimeste jaoks midagi väga ootamatut: ebausaldusväärses (vales) arvutis jookseb RAID peaaegu sama lihtsalt kokku kui ühe kettaga süsteem. RAID ei salvesta üldse järgmistel juhtudel:

• Valede andmete korrektne kirjutamine, samuti andmete kirjutamine väljaspool eeldatavat piirkonda. Selle põhjuseks on nagu varemgi vigane mälu, protsessor, kaabel, kontroller, draivi toiteallikas.
• Kui draiv ei saa lugemisveast teatada.

RAID on loodud kahju minimeerimiseks vaid ühel juhul – füüsilise rikke korral kõvaketas või võib-olla kontroller (mitme kontrolleriga RAID-i puhul). Mälu, operatsioonisüsteemi ja kõige muu RAID-i tõrked ei ole tagatud- samamoodi nagu ühtne NTFS-strateegia.

Ja lõpuks, ülaltoodud töö aksioom RAID tasemed- süsteemi ühe ketta riket loetakse õnnetuseks, mis tuleb võimalikult kiiresti kõrvaldada. See kehtib eriti RAID 0 ja RAID 5 kohta, mille regulaarne töö on ühe ketta rikke korral peaaegu võimatu.

Lisateavet süsteemitarkvaraga Windows RAID NT leiate programmi (või mooduli - Windows 2000 puhul) kettahalduri spikrist, kus tegelikult seda tüüpi kettaid luuakse. Juhin teie tähelepanu asjaolule, et tööjaamade võimalus RAID-e luua ja kasutada on väga piiratud - tööjaam Näiteks NT4 toetab ainult RAID 0 ( paralleelsed kettad), samas kui kõik kirjeldatud valikud töötavad ainult operatsioonisüsteemide serveriversioonidel Osa 6. NTFS-i mahu taastamise strateegia

NTFS-iga arvuti ei käivitu. Mida sel juhul teha? Kuidas andmeid taastada? On kaks juhtumit, mille puhul toimingud on üksteisest mõnevõrra erinevad. Kahjuks pole NT ja vastavalt ka NTFS-i jaoks lihtsaid taastamisstrateegiaid - süsteem on üsna keeruline ja sellel pole kõige lihtsamat. alglaadimise meedium, nagu DOS või Windows95/98.

1. Esimene võimalus - süsteem oli samal NTFS-kettal. Süsteem lihtsalt lõpetas laadimise. Noh, siis 90% juhtudest peame tõstma mitte NTFS-i, vaid lihtsalt NT-d ennast. See operatsioon läheb palju kaugemale selle artikli ulatusest, seega kirjeldan ainult võimalust, kuidas (samal NTFS-i partitsioon) mõnda teist NT-süsteemi, millega töötada (ja teie andmeid lugeda).

NT4 kasutajad saab panna süsteemi otse NTFS-i, käivitades kuidagi installija.

Teil on vaja CD-d, mis on NT4 õige jaotusega. Neid omadusi leidub tõenäoliselt ketastel, millel NT4 asub juurkataloogis asuvas kataloogis nimega i386. Selles kataloogis töötav käsk winnt /? aitab teil valida võtmeid kolme alglaadimisketta loomiseks, millelt saate käivitada NT4 installi otse NTFS-draiv. Saate valida mõne muu installikataloogi – näiteks winnt2 –, et proovida oma NT4 installi taaselustada, kui näete selle konkreetse probleemi lahendusi, mida saavad teha ainult eksperdid. Äsja installitud operatsioonisüsteem sisestab end õigesti alglaadimisloendisse ja ei sega teie vana NT4 üldse.

Kui sobivas vormingus CD-d pole (sümptomid - kiri "sisestage ketas koos NT4 levikomplektiga", mis ei reageeri teie CD olemasolule) - peate lihtsalt panema NT mõnele muule partitsioonile, kuna NTFS kettale ei pääse juurde muudest süsteemidest peale NT.

Tasub arvestada, et NT4 ei saa installida teisendatud NTFS-i uus formaat alates Windows 2000. NT4 loeb endiselt sellist NTFS-i, kuid ainult siis, kui SP4 või uuem on saadaval.

Windows 2000 kasutajad on sunnitud leidma buutiva Windows2000 CD (see on ametlik distributsioon), mis palub teil kas süsteem nullist installida või proovida vana installi taastada. NTFS-draivi, millega Windows2000 töötas, saab lugeda ainult Windows2000 või NT4 SP4 või uuema versiooniga.

Pidage meeles, et mis tahes NT taastamine ilma hädaolukorra taastamise kettata (NT4-s loodud rdisk /s-ga, Windows2000 varundusprogramm) on peaaegu võimatu – see on spetsialisti töö. Muide, isegi kui teil on taasteketas, ei meeldi teile tõenäoliselt "taastatud" süsteemi töö, seega on kogu süsteemi uuesti installimine peaaegu vältimatu. Kui te ei ole kogenud NT tehnik, soovitan teil mitte proovida kasutada NT installija parandusvõimalusi, kuna Tulemus teid suure tõenäosusega ei rahulda. Katse pole muidugi piinamine, kuid operatsioonide kompleks süsteemi täieõiguslikuks taaselustamiseks on väga suur ja seda pole kuskil kirjeldatud, nii et jääte mõnda vahepealsesse, ehkki tõenäoliselt käivitatavasse olekusse.

2. Süsteem ise töötab, kuid puudub juurdepääs kettale (mitte buutitav, vaid mõnele teisele). Kettaadministraator näitab teie partitsiooni jaoks tundmatut tüüpi. Enamikul juhtudel tähendab see seda, et mingil moel tehti ülekirjutamine. saapaala(boot sektor) partitsiooni ja NT ei tea tegelikult üldse, et see on NTFS. operatsioonisüsteem NT jätab igaks juhuks koopia alles alglaadimissektor partitsiooni lõpus - kui kopeerite selle õigesse asukohta tagasi, tuvastatakse enamikul juhtudel draiv NTFS-ina ja see parandab ennast ise.

Õigete aadresside arvutamise protsess on üsna keeruline, seetõttu ma seda ei kirjelda. Täielike juhiste saamiseks sel juhul peate minema MSDN-i saidile ja leidma sealt teabebaasi artikli Q153973 (tõenäoliselt saate seda teha lihtne otsing) - pärast nende juhiste õiget järgimist tuvastatakse süsteem vähemalt NTFS-ina ja partitsiooni edasine saatus sõltub sisemised vahendid NT taastamine, mis antud juhul võtab selle ringlusse. Abiks on ka tagasihoidliku välimusega käsk chkdsk, mis on omamoodi otsetee NT-kettasüsteemide sisemisele taastesüsteemile.

NTFS-i päevik

NTFS kasutab loogiliste struktuuride, mitte kasutajaandmete ajakirjandust – siit ka lause, et andmete turvalisus pole garanteeritud, kuid sellegipoolest säilib süsteemi enda õige olek. Asjaolu, et NTFS ei salvesta andmeid, viib praktikas ühe andmekao variandini - sama hüpoteetilise kolme megabaidi kirjutamise puhul ei ole kirjutamisprotsessi tõrke korral kunagi võimalik kindlaks teha, milline osa andmed kirjutati ja mis jäid muutumatuks. Operatsioonid, mida süsteem siiski logib, on toimingud süsteemi enda struktuuridega, st failide ja kataloogidega: failide lisamine, ümbernimetamine, teisaldamine, loomine ja kustutamine (vaba ruumi vabastamine). Logitakse ka defragmentimistoiminguid – see tähendab failifragmentide liikumist. Ühesõnaga kõike loogilisi tehteid päevikust.

Hilinenud kirjutamine ja kontrollpunktid päeviku pidamine

On teada, et iga kaasaegne süsteem failitoimingute kiirendamiseks on sunnitud kasutama vahemällu, sealhulgas kirjutamistoimingute vahemällu. Nn laisk kirjutamine on vahemällu salvestamise põhimõte, mille puhul kettale kirjutamiseks mõeldud andmeid hoitakse mõnda aega vahemällu ja füüsiliselt hoitakse neid ainult muudest tegevustest vabal ajal. Laisk kirjutamine suurendab oluliselt kettatoimingute tõhusust, kuna selline vahemällu salvestamine koondab palju toiminguid ühte – see on eriti tõhus, kui kirjutatakse ketta kompaktsetele aladele. Laisa kirjutamise eeliseks on ka see, et need ei sega rohkem vajalikku lugemist ja kirjutavad ainult siis, kui süsteem on vaba ja ei vaja muuks otstarbeks juurdepääsu kettale. Kuidas ühitada hilinenud kirjutamist päeviku pidamisega? See on keeruline küsimus, kuna kirjutamise edasilükkamine võimaldab kaotada andmed, mis olid füüsilise kirjutamise järjekorras ja millel polnud enne tõrget aega kettale kirjutada. Kõige ebameeldivam pole siin isegi mitte andmete kadu, vaid asjaolu, et salvestusajas on lahknevus: mõnda teeninduspiirkonda saab värskendada ja mõnda on tähendusega seotud - veel mitte, kuna nende värskendamine võib mõne teise jaoks viibida. paar sekundit ja seda tõrke tõttu ei toimu.

NTFS lahendab need probleemid laiskade kirjutamiste ja ajakirjanduse sisulise integreerimisega. Kui proovite käivitada logitud toimingut, kirjutatakse kavatsus kohe logisse – näiteks faili kustutamiseks. See juhtub viivitamata - praeguses etapis laisk kirjutamine ei tööta: see on metsaraie olemasolu hind, mida ei saa vältida. Kuid kõik muud toimingud on juba käimas viivitatud režiimis - see tähendab, et need võivad toimuda osaliselt või üldse mitte. Ainus viivitatud toiming, mille töö erineb mõnevõrra lihtsast kirjest, on kirje logis eelnevate tehingute eduka sooritamise kohta ehk nn kontrollpunkt. Regulaarsete ajavahemike järel – tavaliselt iga paari sekundi järel – peab süsteem kettale loputama absoluutselt kõik pooleliolevad toimingud. Pärast selle toimingu sooritamist kirjutatakse logisse lihtne kirje - kontrollpunkt -, mis näitab, et kõik eelnevad toimingud sooritati õigesti kõigil tasanditel - nii loogilistel kui ka füüsilistel.

Selline töörežiim - kirjete ja kontrollpunktide abil - tagab ühelt poolt siiski täiesti korrektse logimise, teisalt aga ei aeglusta tööd praktiliselt üldse: kontrollpunktid tehakse, kaalutakse, koheselt ja kirjutatakse. alguses olevale logile Toiming vastab pingutuse poolest andmete enda kirjutamisele ilma laisa vahemällu salvestamiseta. Tõeline salvestamine, mis tehakse hiljem, ei sega enamikul juhtudel ühtegi toimingut ega kahjusta süsteemi jõudlust.