Microsofti uus ReFS -failisüsteem ilmus algselt serverites, kus töötab Windows 2012. See lisati alles hiljem Windows 10 -sse, kus seda saab kasutada ainult osana kettaruumi funktsioonist Storage Spaces. Microsoft lubab Windows Server 2016 -s oluliselt parandada tööd ReFS -failisüsteemiga, lisaks võib trükitud kuulujuttude kohaselt ReFS asendada vananenud NTFS -failisüsteemi Windows 10 uues versioonis, mida uhkelt nimetatakse Windowsiks 10 Pro (arenenud arvutitele).
Mis on aga ReF -id, kuidas see erineb praegu kasutatavast failisüsteemist NTFS ja mis eeliseid sellel on?
Lühidalt öeldes oli see loodud tõrketaluvaks failisüsteemiks. ReFS on uus failisüsteem, mis on ehitatud koodiga ja on sisuliselt ümber kujundatud ja täiustatud NTFS -failisüsteem. Need hõlmavad teabe salvestamise suuremat usaldusväärsust, stabiilset tööd pingerežiimides, failide suurusi, köiteid, katalooge, köidete ja kataloogide failide arvu piirab ainult 64-bitiste numbrite suurus. Tuletame meelde, et selle väärtuse maksimaalne suurus, maksimaalne failisuurus on 16 eksbibaiti ja helitugevus on 1 jobait.
Praegu ei asenda ReFS NTFS -i. Sellel on eelised ja puudused. Kuid te ei saa näiteks ketast vormindada ja sellele Windowsi värsket koopiat installida nagu NTFS -i puhul.
ReFS kasutab metaandmete kontrollsummasid ja võib kasutada ka andmefailide kontrollsummasid. Iga kord, kui loete või kirjutate faile, kontrollib ReFS kontrollsummat, et veenduda selle õigsuses. See tähendab, et failisüsteemil endal on tööriist, mis suudab rikutud andmeid käigu pealt tuvastada.
ReFS on integreeritud salvestusruumidega. Kui olete konfigureerinud ReFS-toega peegeldamise, saab Windows hõlpsasti tuvastada failisüsteemi riknemise ja selle automaatselt parandada, kopeerides peegeldatud andmed kahjustatud kettale. See funktsioon on saadaval nii Windows 10 kui ka Windows 8.1 jaoks.
Kui ReFS tuvastab rikutud andmed ja nõutav andmete koopia pole taastamiseks saadaval, saab failisüsteem rikutud andmed kohe kettalt eemaldada. Erinevalt NTFS -ist ei vaja see süsteemi taaskäivitamist.
ReFS teeb enamat kui lihtsalt failide terviklikkuse kontrollimist nende lugemise ajal. See kontrollib automaatselt andmete terviklikkust, kontrollides regulaarselt kõiki ketta faile, tuvastades ja parandades rikutud andmed. Sel juhul pole ketta kontrollimiseks käsk chkdsk vaja perioodiliselt käivitada.
Uus failisüsteem on ka muul viisil andmete rikkumise suhtes vastupidav. Näiteks värskendate faili metaandmeid (kuigi faili nime). NTFS -failisüsteem muudab faili metaandmeid otse. Kui sel ajal toimub süsteemi krahh (väljalülitamine), on suure tõenäosusega fail kahjustatud. Kui muudate metaandmeid, loob ReFS -failisüsteem metaandmetest uue koopia. Failisüsteem ei kirjuta vana metaandmeid üle, vaid kirjutab need uude plokki. See välistab faili kahjustamise võimaluse. Seda strateegiat nimetatakse "kopeerimiseks-kirjutamiseks". See strateegia on saadaval teistes kaasaegsetes failisüsteemides, näiteks ZFS ja BtrFS Linuxis, samuti Apple'i uues APFS -failisüsteemis.
ReFS on kaasaegsem kui NTFS ja toetab palju suuremaid andmemahtusid ning pikemaid failinimesid. See on pikas perspektiivis väga oluline.
NTFS -failisüsteemis on failitee piiratud 255 tähemärgiga. ReFS -is on maksimaalne tähemärkide arv muljetavaldav 32 768 tähemärki. Praegu on Windows 10 -s võimalus keelata NTFS -i märgielement. See piirang on vaikimisi keelatud ReFS -ketta köidetel.
ReFS ei toeta DOS 8.3 failinimesid. NTFS -köidete puhul on teil juurdepääs kaustadele “CProgram Files”, “CProgra`1”. Neid on vaja vanaga ühildumiseks tarkvara... ReFS -ist ei leia te harjunud kaustu. Need eemaldatakse.
NTFS -i toetatud teoreetiline maksimaalne andmemaht on 16 eksabaiti, ReFS toetab kuni 262 144 eksabaiti. Nüüd näib see näitaja olevat tohutu.
Arendajate eesmärk ei olnud luua tõhusamat failisüsteemi. Nad tegid sujuvama süsteemi.
Näiteks massiiviga kasutamisel toetab ReFS reaalajas taseme optimeerimist. Teil on kokku pandud kahe kettaseadme bassein. Esimene ketas on valitud suure kiirusega, kiire juurdepääs andmete juurde. Teine ketas valitakse usaldusväärsuse kriteeriumiga andmete pikaajaliseks salvestamiseks. Taustal teisaldab ReFS automaatselt suured andmemahud aeglasemale kettale, tagades seeläbi andmete usaldusväärse salvestamise.
Windows Server 2016 -s lisasid arendajad tööriista, mis pakub jõudluse täiustusi, kasutades virtuaalmasinate spetsiifilisi funktsioone. Näiteks toetab ReFS plokkide kopeerimist, mis kiirendab virtuaalmasinate kopeerimist ja kontrollpunktide ühendamist. Virtuaalse masina koopia loomiseks loob ReFS uue ketta metaandmete koopia ja annab lingi kettale kopeeritud andmetele. Seda selleks, et mitmed failid saaksid ReFS -i abil kettale viidata samadele alusandmetele. Pärast seda, kui olete pärast virtuaalmasinaga töötamist andmeid muutnud, kirjutatakse need teisele kohale kettale ja virtuaalmasina algandmed jäävad kettale. See kiirendab oluliselt koopiate loomise protsessi ja vähendab ketta koormust.
ReFS toetab “hõredat VDL -i” (hõredad failid). Hõre fail on fail, milles nullbaidine jada asendatakse selle jada kohta käiva teabega (aukude loend). Avad on konkreetne nullbaitide jada faili sees, mitte kettale kirjutatud. Aukuteave ise salvestatakse failisüsteemi metaandmetesse.
Hõreda failitoe tehnoloogia võimaldab kiiresti nullid suurele failile kirjutada. See kiirendab oluliselt uue tühja fikseeritud suurusega virtuaalse kõvaketta (VHD) faili loomist. Sellise faili loomine ReFS -is võtab paar sekundit, NTFS -is aga kuni 10 minutit.
Kõik, mida me eespool kirjeldasime, kõlab hästi, kuid te ei saa NTFS -ist ReFS -ile üle minna. Windows ei saa ReFS -ist käivitada, nõudes NTFS -i.
ReFS -il puuduvad paljud NTFS -is saadaolevad tehnoloogiad. Näiteks failisüsteemi tihendamine ja krüptimine, kõvad lingid, laiendatud atribuudid, andmete deduplikatsioon ja kettakvoodid. Samal ajal toetab ReFS erinevalt NTFS -ist andmete täielikku krüptimistehnoloogiat - BitLocker.
Windows 10 -s ei saa te kettapartitsiooni ReFS -iga vormindada. Uus failisüsteem on saadaval ainult salvestussüsteemidele, kus selle peamine ülesanne on kaitsta andmeid kahjustuste eest. Windows Server 2016 -s saate kettapartitsiooni vormindada ReFS -i abil. Saate seda kasutada virtuaalmasinate käitamiseks. Kuid te ei saa seda alglaadimiskettana valida. Windows käivitub ainult NTFS -failisüsteemist.
On ebaselge, milline on Microsofti tulevik uue failisüsteemi jaoks. Võib -olla asendab see ühel päeval NTFS -i täielikult kõigis Windowsi versioonides. Kuid praegu saab ReFS -i kasutada ainult teatud ülesannete täitmiseks.
Eespool on uue operatsioonisüsteemi toetuseks palju öeldud. Kirjeldatakse miinuseid ja plusse. Teen ettepaneku peatuda ja teha kokkuvõte. Millistel eesmärkidel on see võimalik ja võib -olla on vaja kasutada ReFS -i.
Windows 10 puhul on ReFS rakendatav ainult koos salvestusruumide komponendiga. Vormindage oma mäluseade kindlasti ReFS -i ja mitte NTFS -iga. Sellisel juhul saate täielikult hinnata andmete salvestamise usaldusväärsust.
Windows Serveris saate vormindada ReFS -i partitsiooni kettahalduskonsooli tavalise Windowsi tööriista abil. Virtuaalserverite kasutamisel on soovitatav kindlasti vormindada ReFS. Kuid pidage meeles, et alglaadimisketas peab olema NTFS -vormingus. ReFS -failisüsteemist käivitamist ei toetata Windowsi operatsioonisüsteemides.
Uus failisüsteem ReFS ja Windows 10| 2017-06-28 06:34:15 | Superkasutaja | Süsteemi tarkvara | https: //site/media/system/images/new.png | Microsoft ReFS -i uus failisüsteem on asendanud vananenud NTFS -i. Millised on ReFS -i eelised ja kuidas see erineb NTFS -ist | refs, refs või ntfs, viited Windows 10, refs failisüsteem, uued failisüsteemid, ntfs süsteem, ntfs failisüsteem
Miks nutitelefon ei pruugi mälukaardilt programme käivitada? Kuidas erineb ext4 põhimõtteliselt ext3 -st? Miks elab mälupulk kauem, kui see on vormindatud NTFS -ile, mitte FAT -ile? Mis on F2FSi peamine probleem? Vastused peituvad failisüsteemide struktuuri iseärasustes. Me räägime neist.
Failisüsteemid määravad andmete salvestamise viisi. Need määravad kindlaks, milliste piirangutega kasutaja silmitsi seisab, kui kiiresti toimivad lugemis- ja kirjutamistoimingud ning kui kaua draiv tõrgeteta töötab. See kehtib eriti eelarve -SSD -de ja nende nooremate vendade - mälupulkade kohta. Neid funktsioone teades saate igast süsteemist maksimumi välja pigistada ja optimeerida selle kasutamist konkreetsete ülesannete jaoks.
Failisüsteemi tüüp ja parameetrid peate valima iga kord, kui peate tegema midagi ebaolulist. Näiteks soovite kiirendada kõige sagedasemaid failitoiminguid. Failisüsteemi tasemel saab seda teha mitmel viisil: indekseerimine võimaldab kiireid otsinguid ja tasuta plokkide eelbroneerimine hõlbustab sageli muutuvate failide ülekirjutamist. Andmete eeloptimeerimine muutmälu vähendab vajalike sisend- / väljundtoimingute arvu.
Kaasaegsete failisüsteemide omadused, nagu laisk kirjutamine, deduplikatsioon ja muud täiustatud algoritmid aitavad pikendada tööaega. Need on eriti olulised odavate SSD -de jaoks, millel on TLC -mälukiip, mälupulk ja mälukaart.
Eri tasandite kettamassiivide jaoks on olemas eraldi optimeerimised: näiteks võib failisüsteem toetada kerget helitugevuse peegeldamist, hetktõmmiseid või dünaamilist skaleerimist ilma helitugevust võrguühenduseta.
Kasutajad töötavad peamiselt operatsioonisüsteemi vaikimisi pakutava failisüsteemiga. Nad loovad harva uusi kettapartitsioone ja isegi harvem mõtlevad oma seadetele - nad lihtsalt kasutavad soovitatud parameetreid või ostavad isegi eelvormindatud meediat.
Windowsi fännide jaoks on kõik lihtne: NTFS kõigil kettapartitsioonidel ja FAT32 (või sama NTFS) mälupulkadel. Kui on olemas NAS ja selles kasutatakse mõnda muud failisüsteemi, siis enamiku jaoks jääb see arusaamatuks. Nad lihtsalt ühenduvad sellega võrgu kaudu ja laadivad failid alla nagu mustast kastist.
Androidiga mobiilseadmetes leidub ext4 kõige sagedamini sisemälus ja FAT32 microSD -kaartidel. Apple'i jaoks pole üldse oluline, milline failisüsteem neil on: HFS +, HFSX, APFS, WTFS ... nende jaoks on ainult ilusad kaustade ja failide ikoonid, mille on joonistanud parimad disainerid. Linuxi kasutajatel on kõige rikkalikum valik, kuid saate lisada toe failisüsteemidele, mis ei ole nii Windowsi kui ka macOS -i opsüsteemile omased - sellest lähemalt hiljem.
Loodud on üle saja erineva failisüsteemi, kuid asjakohaseks võib nimetada veidi rohkem kui tosinat. Kuigi need kõik olid mõeldud nende konkreetsete rakenduste jaoks, olid paljud lõpuks kontseptuaalselt seotud. Need on sarnased, kuna kasutavad sama tüüpi esitlusstruktuuri (meta) andmeid-B-puud ("bi-puud").
Nagu iga hierarhilise süsteemi puhul, algab ka B -puu juurkirjest ja hargneb edasi kuni lõpuelementideni - failide ja nende atribuutide üksikute kirjete või "lehtede" juurde. Sellise loogilise struktuuri loomise peamine eesmärk oli kiirendada failisüsteemi objektide otsimist suurtel dünaamilistel massiividel - näiteks mitme terabaidise kõvaketta või veelgi muljetavaldavama RAID -massiivi otsimisel.
B-puud nõuavad samade toimingute tegemisel palju vähem juurdepääsu kettale kui muud tüüpi B-puud. See saavutatakse tänu sellele, et B-puude lõplikud objektid asuvad hierarhiliselt samal kõrgusel ja kõigi toimingute kiirus on lihtsalt võrdeline puu kõrgusega.
Nagu teistel tasakaalustatud puudel, on ka B-puudel sama pikk tee juurtest lehtedeni. Kasvamise asemel hargnevad nad rohkem ja laienevad: kõik B-puu hargnemispunktid salvestavad palju viiteid alamobjektidele, mis muudab nende leidmise vähemate kõnedega hõlpsaks. Suur hulk näpunäiteid vähendab pikimate kettaoperatsioonide arvu - pea positsioneerimist suvaliste plokkide lugemisel.
B-puude kontseptsioon sõnastati juba seitsmekümnendatel aastatel ja on sellest ajast alates erinevaid parandusi teinud. Seda rakendatakse ühel või teisel kujul NTFS, BFS, XFS, JFS, ReiserFS ja paljudes DBMSides. Andmete korraldamise aluspõhimõtete poolest on nad kõik nõod. Erinevused puudutavad detaile, mis on sageli üsna olulised. Seotud failisüsteemide puudus on samuti tavaline: need kõik loodi ketastega töötamiseks juba enne SSD -de tulekut.
Tahkis-draivid asendavad tasapisi kettaseadmeid, kuid siiani on nad sunnitud kasutama neile võõraid, päritud failisüsteeme. Need on üles ehitatud välkmälu massiividele, mille põhimõtted erinevad kettaseadmete omadest. Eelkõige tuleb enne kirjutamist kustutada välkmälu ja seda toimingut NAND -kiipides ei saa teha üksikute lahtrite tasemel. See on võimalik ainult suurte plokkide jaoks tervikuna.
See piirang on tingitud asjaolust, et NAND -mälus on kõik lahtrid ühendatud plokkideks, millest igaühel on ainult üks ühine ühendus juhtbussiga. Me ei süvene otsinguregistri üksikasjadesse ja maalime täielikku hierarhiat. Oluline on juba rakkude rühmatoimingute põhimõte ja asjaolu, et välkmälu plokkide suurused on tavaliselt suuremad kui mis tahes failisüsteemis käsitletud plokid. Seetõttu tuleb kõik NAND -välguga draivide aadressid ja käsud tõlkida läbi FTL (Flash Translation Layer) abstraktsioonikihi.
Välkmälu kontrollerid tagavad ühilduvuse kettaseadmete loogikaga ja toetavad nende liideste käske. Tavaliselt rakendatakse FTL -i nende püsivaras, kuid see võib (osaliselt) hostil töötada - näiteks kirjutab Plextor oma SSD -de jaoks draivereid, mis kiirendavad kirjutamist.
Ilma FTLita ei saa üldse hakkama, sest isegi ühe biti kirjutamine konkreetsesse lahtrisse toob kaasa terve rea toiminguid: kontroller otsib vajalikku lahtrit sisaldavat plokki; plokk loetakse täielikult, kirjutatakse vahemällu või vabastatakse, seejärel kustutatakse täielikult, pärast mida kirjutatakse see vajalike muudatustega tagasi.
Selline lähenemine meenutab armee igapäevast elu: ühele sõdurile käsu andmiseks teeb seersant üldmoodustise, kutsub vaese mehe rivist välja ja käsib ülejäänutel laiali minna. Nüüdseks haruldases NOR -mälus oli organisatsioon spetsnaz: iga rakku juhiti iseseisvalt (igal transistoril oli individuaalne kontakt).
Kontrollerite ülesanded suurenevad, kuna iga välkmälu genereerimisega väheneb selle valmistamise tehniline protsess, et suurendada tihedust ja vähendada andmete salvestamise kulusid. Koos tehnoloogiliste standarditega väheneb ka kiipide eeldatav eluiga.
Ühetasandiliste SLC-rakkudega moodulite deklareeritud ressurss oli 100 tuhat ümberkirjutamistsüklit ja isegi rohkem. Paljud neist töötavad endiselt vanades mälupulkades ja CF -kaartides. Ettevõtteklassi MLC (eMLC) nõudis ressurssi vahemikus 10–20 tuhat, tavalises tarbijataseme MLC-s aga hinnanguliselt 3-5 tuhat. Seda tüüpi mälu on aktiivselt täis veelgi odavam TLC, mille ressurss ulatub vaevalt tuhande tsüklini. Välkmälu eluiga vastuvõetaval tasemel hoidmine peab toimuma tarkvaraliste muudatuste abil ja üheks neist on saamas uued failisüsteemid.
Tootjad arvasid esialgu, et failisüsteem ei ole oluline. Kontroller ise peab säilitama lühiajalise mis tahes tüüpi mälurakkude massiivi, jaotades koormuse nende vahel optimaalselt. Failisüsteemi draiveri jaoks simuleerib see tavalist ketast ja teeb igal juurdepääsul madala optimeerimise. Kuid praktikas varieerub optimeerimine erinevate seadmete puhul maagilisest fiktiivseks.
Ettevõtete SSD-des on sisseehitatud kontroller väike arvuti. Sellel on tohutu mälupuhver (pool kontserti ja rohkem) ning see toetab paljusid meetodeid andmetega töötamise tõhususe parandamiseks, mis väldib tarbetuid ümberkirjutamistsükleid. Kiip korraldab kõik vahemälus olevad plokid, täidab laisalt kirjutamist, teeb dubleerimist lennult, reserveerib mõned plokid ja kustutab teised taustal. Kogu see maagia juhtub OS -i, programmide ja kasutaja poolt täiesti märkamatult. Sellise SSD -ga pole tegelikult vahet, millist failisüsteemi kasutatakse. Sisemistel optimeeringutel on jõudlusele ja ressurssidele palju suurem mõju kui välistel.
Eelarve SSD -d (ja veelgi enam - mälupulgad) on varustatud palju vähem intelligentsete kontrolleritega. Nende vahemälu on kärbitud või puudub üldse ja täiustatud serveritehnoloogiaid ei kasutata üldse. Mälukaartides on kontrollerid nii primitiivsed, et sageli väidetakse, et neid pole üldse olemas. Seetõttu on välkmäluga odavate seadmete puhul endiselt asjakohased välised koormuse tasakaalustamise meetodid - peamiselt spetsiaalsete failisüsteemide kasutamine.
Üks esimesi katseid kirjutada failisüsteem, mis arvestaks välkmälu korraldamise põhimõtetega, oli JFFS - Journaling Flash File System. Esialgu oli see Rootsi ettevõtte Axis Communications arendus keskendunud üheksakümnendatel aastatel Axise toodetud võrguseadmete mälutõhususe parandamisele. JFFS -i esimene versioon toetas ainult NOR -mälu, kuid juba teises versioonis sai see NAND -iga sõbraks.
JFFS2 on praegu piiratud kasutusega. Enamasti kasutatakse seda endiselt manustatud süsteemide Linuxi distributsioonides. Seda võib leida ruuteritest, IP -kaameratest, NAS -ist ja muudest asjade Interneti püsiklientidest. Üldiselt kõikjal, kus on vaja väikest kogust usaldusväärset mälu.
JFFS2 edasiarendus oli LogFS, mis salvestas inodes eraldi faili. Selle idee autorid on IBMi Jorn Engeli Saksamaa osakonna töötaja ja Osnabrücki ülikooli professor Robert Mertens. LogFS -i lähtekood on saadaval GitHubis. Otsustades asjaolu, et viimane muudatus selles tehti neli aastat tagasi, pole LogFS populaarsust kogunud.
Kuid need katsed soodustasid teise spetsialiseeritud failisüsteemi - F2FS - tekkimist. Selle töötas välja Samsung Corporation, mis moodustab suure osa maailmas toodetud välkmälust. Samsung valmistab enda ja teiste ettevõtete jaoks NAND Flashi kiipe ning arendab ka pärandketaste asemel põhimõtteliselt uute liidestega SSD -sid. Spetsiaalse välkmälu jaoks optimeeritud failisüsteemi loomine on Samsungi seisukohast olnud ammu vajalik.
Neli aastat tagasi, 2012. aastal, lõi Samsung F2FS (Flash Friendly File System). Selle idee on hea, kuid teostus osutus niiskeks. Põhiülesanne F2FS -i loomisel oli lihtne: vähendada lahtrite ümberkirjutamistoimingute arvu ja jaotada nende koormus võimalikult ühtlaselt. Selleks on vaja teha toiminguid sama ploki mitme lahtriga korraga ja mitte neid ükshaaval vägistada. See tähendab, et me ei vaja OS -i esimesel nõudmisel kohe olemasolevate plokkide ümberkirjutamist, vaid käskude ja andmete vahemällu salvestamist, uute plokkide lisamist vabale ruumile ja lahtrite hilinenud kustutamist.
Tänapäeval on F2FS -i tugi juba ametlikult Linuxis (ja seega ka Androidis) rakendatud, kuid praktikas see veel erilisi eeliseid ei anna. Selle failisüsteemi peamine omadus (edasilükatud ülekirjutamine) on viinud enneaegsete järeldusteni selle tõhususe kohta. Vana vahemällu salvestamise trikk petta isegi võrdlusaluste varajased versioonid, kus F2FS näitas näilist eelist mitte mõne protsendi (nagu oodatud) või isegi mitu korda, vaid suurusjärkude võrra. Lihtsalt F2FS -i draiver teatas operatsiooni teostamisest, mida kontroller just plaanis teha. Kui aga tegelik jõudlus F2FS -is on väike, on rakkude kulumine kindlasti väiksem kui sama ext4 kasutamisel. Need optimeeringud, mida odav kontroller ei saa teha, viiakse läbi failisüsteemi enda tasandil.
Kuigi F2FS -i peetakse geekide jaoks eksootiliseks. Isegi Samsungi enda nutitelefonid kasutavad endiselt ext4. Paljud peavad seda ext3 edasiarenduseks, kuid see pole täiesti tõsi. See on rohkem revolutsioon kui 2 TB failitõkke purustamine ja muude näitajate suurendamine.
Kui arvutid olid suured ja failid väikesed, oli adresseerimine lihtne. Igale failile eraldati teatud arv plokke, mille aadressid sisestati vastavustabelisse. Nii töötas ext3 failisüsteem, mis on kasutusel tänaseni. Kuid ext4 -s ilmus põhimõtteliselt erinev pöördumisviis - ulatused.
Laiendeid võib pidada inoodilaienditeks diskreetsete plokkide komplektidena, mida käsitletakse tervikuna külgnevate järjestustena. Üks ulatus võib sisaldada tervet keskmise suurusega faili ja suurte failide puhul piisab, kui eraldada tosin või kaks ulatust. See on palju tõhusam kui sadade tuhandete nelja kilobaidi väikeste plokkide käsitlemine.
Kirjutamismehhanism ise on ext4 -s muutunud. Nüüd toimub plokkide jaotus kohe ühes taotluses. Ja mitte ette, vaid vahetult enne andmete kettale kirjutamist. Hilinenud mitme ploki eraldamine võimaldab teil vabaneda tarbetutest toimingutest, millega ext3 patustas: selles eraldati uue faili plokid kohe, isegi kui see mahtus täielikult vahemällu ja oli plaanitud ajutiseks kustutada.
Lisaks tasakaalustatud puudele ja nende modifikatsioonidele on ka teisi populaarseid loogilisi struktuure. On failisüsteeme, millel on põhimõtteliselt erinev organisatsioonitüüp - näiteks lineaarne. Tõenäoliselt kasutate vähemalt ühte neist palju.
Arva mõistatust: kaheteistkümneaastaselt hakkas ta kaalus juurde võtma, kuueteistkümneaastaselt oli ta loll paks naine ja kolmekümne kaheaastaselt sai ta paksuks ja jäi lihtsameelseks. Kes ta on?
See on õige, see on lugu FAT -failisüsteemist. Ühilduvusnõuded andsid talle halva pärandi. Disketitel oli see 12-bitine, kõvaketastel esialgu 16-bitine ja on tänaseni 32-bitine. Igas järgnevas versioonis suurenes adresseeritavate plokkide arv, kuid sisuliselt ei muutunud midagi.
Endiselt populaarne FAT32 failisüsteem ilmus kakskümmend aastat tagasi. Täna on see veel primitiivne ega toeta ACL -e, kettakvoote, tausta tihendamist ega muid kaasaegseid andmete optimeerimise tehnoloogiaid.
Miks on FAT32 tänapäeval vajalik? Kõik ainult ühilduvuse eesmärgil. Tootjad usuvad õigesti, et iga operatsioonisüsteem suudab lugeda FAT32 partitsiooni. Seetõttu loovad nad selle välistele kõvaketastele, USB -välkmälule ja mälukaartidele.
Nutitelefonides kasutatavad MicroSD (HC) kaardid on vaikimisi vormindatud FAT32 -vormingus. See on peamine takistus rakenduste installimisel neile ja andmete ülekandmisel sisemälust. Selle ületamiseks peate looma kaardile ext3 või ext4 partitsiooni. Sellele saab üle kanda kõik faili atribuudid (sealhulgas omaniku ja juurdepääsuõigused), nii et iga rakendus võib töötada nii, nagu oleks see sisemälust käivitatud.
Windows ei saa mälupulkadele luua rohkem kui ühte partitsiooni, kuid selleks saate käivitada Linuxi (vähemalt virtuaalmasinas) või täiustatud utiliidi loogilise partitsiooniga töötamiseks - näiteks MiniTool Partition Wizard Free. Olles leidnud kaardilt täiendava esmase sektsiooni ext3 / ext4, pakuvad Link2SD ja muud sarnased rakendused palju rohkem võimalusi kui ühe FAT32 sektsiooni puhul.
Teine argument FAT32 kasuks on ajakirjade puudumine, mis tähendab kiiremaid kirjutamisoperatsioone ja vähem NAND -välkmälu elementide kulumist. Praktikas toob FAT32 kasutamine kaasa vastupidise ja tekitab palju muid probleeme.
Mälupulgad ja mälukaardid surevad lihtsalt kiiresti, sest kõik FAT32 muudatused põhjustavad samade sektorite ülekirjutamise, kus asuvad kaks failitabelite ahelat. Salvestasin kogu veebilehe ja see kirjutati sada korda ümber - iga väikese GIF -i lisamisega mälupulgale. Kas käivitasite kaasaskantava tarkvara? Ta lõi ajutised failid ja muudab neid töö ajal pidevalt. Seetõttu on palju parem kasutada NTFS-i mälupulkadel, millel on tõrkekindel $ MFT tabel. Väikseid faile saab salvestada otse põhifailitabelisse ning selle laiendid ja koopiad kirjutatakse erinevatesse välkmälu piirkondadesse. Lisaks muudab NTFS -i indekseerimine otsingud kiiremaks.
Veel üks probleem, millega enamik kasutajaid silmitsi seisab, on see, et FAT32 -sektsiooni on võimatu kirjutada suuremat kui 4 GB faili. Põhjus on selles, et FAT32 -s kirjeldab faili suurust failide eraldamise tabelis 32 bitti ja 2 ^ 32 (täpsemalt miinus üks) annab vaid neli tulemust. Selgub, et värskelt ostetud mälupulgale ei saa salvestada normaalse kvaliteediga filmi ega DVD -pilti.
Suurte failide kopeerimine on endiselt pool probleemist: kui proovite seda teha, on viga vähemalt kohe nähtav. Muudes olukordades toimib FAT32 viitsütikuga pommina. Näiteks kopeerisite kaasaskantava tarkvara USB -mälupulgale ja saate seda algul ilma probleemideta kasutada. Pika aja pärast on ühel programmil (näiteks raamatupidamine või post) andmebaas paisunud ja ... see lihtsalt lõpetab värskendamise. Faili ei saa üle kirjutada, kuna see on jõudnud 4 GB piiranguni.
Vähem ilmne probleem on see, et FAT32 -s saab faili või kataloogi loomise kuupäeva määrata kahe sekundi täpsusega. Sellest ei piisa paljude krüptograafiliste rakenduste jaoks, mis kasutavad ajatemplit. Kuupäeva atribuudi madal täpsus on veel üks põhjus, miks FAT32 ei loeta turvalisuse seisukohast terviklikuks failisüsteemiks. Selle nõrkusi saab aga kasutada oma eesmärkidel. Näiteks kui kopeerite failid NTFS -partitsioonist FAT32 -köites, kustutatakse need kõikidest metaandmetest, samuti päritud ja spetsiaalselt määratud õigustest. FAT lihtsalt ei toeta neid.
Erinevalt FAT12 / 16/32 -st oli exFAT loodud spetsiaalselt USB -välkmälu ja suurte mälukaartide (≥ 32 GB) jaoks. Laiendatud FAT välistab FAT32 eelnimetatud puuduse - samade sektorite ülekirjutamise mis tahes muudatuse korral. 64-bitise süsteemina pole sellel ühe faili suurusele praktiliselt mingeid piiranguid. Teoreetiliselt võib see olla 2 ^ 64 baiti (16 EB) pikk ja selle suurusega kaarte ei ilmu niipea.
Teine oluline erinevus exFAT -is on selle juurdepääsukontrolli loendite (ACL) tugi. See pole sama lihtsus üheksakümnendatest, kuid suletud formaat takistab exFATi rakendamist. ExFATi tugi on täielikult ja seaduslikult rakendatud ainult Windowsis (alates XP SP2 -st) ja OS X -is (alates 10.6.5). Linuxis ja * BSD -s toetatakse seda kas piirangutega või mitte täielikult seaduslikult. Microsoft nõuab exFAT -i kasutamiseks litsentseerimist ja selles valdkonnas on palju õigusvaidlusi.
Teine silmapaistev näide B-puu failisüsteemidest on Btrfs. See FS ilmus 2007. aastal ja loodi algselt Oracle'is, pidades silmas tööd SSD ja RAID -iga. Näiteks saab seda dünaamiliselt skaleerida: luua reaalajas süsteemis uusi inodeid või jagada köide alammahtudeks, eraldamata neile vaba ruumi.
Btrfs-is rakendatud kopeerimise-kirjutamise mehhanism ja täielik integreerimine seadme kaardistaja tuumamooduliga võimaldavad teil virtuaalsete plokkide kaudu teha peaaegu koheseid hetktõmmiseid. Andmete eelpakkimine (zlib või lzo) ja dubleerimine kiirendavad põhitoiminguid, pikendades samal ajal ka välkmälu kasutusiga. See on eriti märgatav andmebaasidega töötamisel (pakkimine saavutatakse 2–4 korda) ja väikeste failidega (need on kirjutatud korrapäraselt suurtesse plokkidesse ja neid saab salvestada otse lehtedesse).
Btrfs toetab ka täielikku päevikut (andmed ja metaandmed), helitugevuse kontroll ilma lahtivõtmiseta ja palju muid kaasaegseid funktsioone. Btrfs -kood on avaldatud GPL -litsentsi all. Seda failisüsteemi on Linuxis stabiilsena hoitud alates tuumast 4.3.1.
Peaaegu kõik enam -vähem kaasaegsed failisüsteemid (ext3 / ext4, NTFS, HFSX, Btrfs ja teised) kuuluvad ajakirjade üldisesse rühma, kuna nad peavad muudatuste kohta eraldi logis (päevikus) arvestust ja kontrollivad seda ebaõnnestumine kettaoperatsioonide ajal ... Nende failisüsteemide paljusõnalisuse ja tõrketaluvuse tase on aga erinev.
Ext3 toetab kolme logimisrežiimi: loopback, järjestatud ja täielik logimine. Esimene režiim hõlmab ainult üldiste muudatuste (metaandmete) salvestamist, mis tehakse andmete muutuste suhtes asünkroonselt. Teises režiimis tehakse sama metaandmete salvestus, kuid rangelt enne muudatuste tegemist. Kolmas režiim on samaväärne täieliku logimisega (muudatused nii metaandmetes kui ka failides endas).
Ainult viimane võimalus tagab andmete terviklikkuse. Ülejäänud kaks kiirendavad kontrollimisel ainult vigade tuvastamist ja tagavad failisüsteemi enda terviklikkuse, kuid mitte failide sisu taastamise.
NTFS -i logimine sarnaneb ext3 teise logimisrežiimiga. Logisse salvestatakse ainult metaandmete muudatused ja andmed ise võivad ebaõnnestumise korral kaotsi minna. Seda NTFS-i päevikumeetodit ei kavandatud viisina maksimaalse töökindluse saavutamiseks, vaid ainult kompromissina jõudluse ja tõrketaluvuse vahel. Seetõttu peavad inimesed, kes on harjunud töötama täielikult ajakirjastamise süsteemidega, pidama NTFS-i pseudopäevikuks.
NTFS -lähenemine on mõnevõrra parem kui ext3 vaikeseade. NTFS -is luuakse perioodiliselt täiendavalt kontrollpunkte, et tagada kõigi varem ootel olevate kettaoperatsioonide lõpuleviimine. Kontrollpunktidel pole midagi pistmist taastepunktidega jaotises \ System Volume Infromation \. Need on logis vaid üldkulud.
Praktika näitab, et sellisest osalisest NTFS-i päevikust enamikul juhtudel piisab tõrgeteta tööks. Lõppude lõpuks, isegi terava voolukatkestuse korral ei lülitu kettaseadmed koheselt välja. Toiteplokk ja arvukad ajamite kondensaatorid pakuvad just seda minimaalset energiavaru, millest piisab praeguse kirjutamistoimingu lõpuleviimiseks. Kaasaegsetel SSD -del on oma kiiruse ja ökonoomsusega tavaliselt piisavalt energiat ootel toimingute tegemiseks. Täielikule logimisele ülemineku katse vähendaks enamiku toimingute kiirust mitu korda.
Failisüsteemide kasutamist piirab nende tugi OS -i tasandil. Näiteks Windows ei mõista ext2 / 3/4 ja HFS +, kuid mõnikord peate neid kasutama. Seda saab teha sobiva draiveri lisamisega.
Avatud draiver ext2 / 3 partitsioonide lugemiseks ja kirjutamiseks osalise ext4 toega. Viimane versioon toetab laiendusi ja vaheseinu kuni 16 TB. LVM -i, ACL -e ja laiendatud atribuute ei toetata.
Total Commanderi jaoks on tasuta pistikprogramm. Toetab ext2 / 3/4 partitsioonide lugemist.
coLinux on Linuxi kerneli avatud lähtekoodiga ja tasuta port. Koos 32-bitise draiveriga võimaldab see käivitada Linuxi operatsioonisüsteemides Windows 2000 kuni 7 ilma virtualiseerimistehnoloogiaid kasutamata. Toetab ainult 32-bitiseid versioone. 64-bitise modifikatsiooni arendamine tühistati. coLinux võimaldab muu hulgas korraldada Windowsi juurdepääsu ext2 / 3/4 partitsioonidele. Projekti toetus peatati 2014.
Windows 10-l võib juba olla Linuxi-spetsiifiliste failisüsteemide loomulik tugi, see on lihtsalt peidetud. Neid mõtteid soovitavad tuumataseme draiver Lxcore.sys ja teenus LxssManager, mis on Svchost.exe protsessi abil raamatukoguks laaditud. Lisateavet leiate Alex Ionescu kõnest "The Linux Kernel Hidden Inside Windows 10", mille ta esitas Black Hat 2016.
ExtFS for Windows on Paragoni välja antud tasuline draiver. See töötab operatsioonisüsteemides Windows 7 kuni 10, toetab lugemis- / kirjutamisõigust ext2 / 3/4 köidetele. Pakub peaaegu täielikku ext4 tuge Windowsis.
HFS + Windows 10 jaoks on veel üks Paragon Tarkvara patenteeritud draiver. Vaatamata nimele töötab see kõigis Windowsi versioonides alates XP -st. Tagab täieliku juurdepääsu HFS + / HFSX failisüsteemidele mis tahes sektsiooniga (MBR / GPT) kettadel.
WinBtrfs on Windowsi Btrfsi draiveri varajane arendus. Juba versioonis 0.6 toetab see nii lugemis- kui ka kirjutamisõigust Btrfsi köidetele. See suudab hallata raskeid ja sümboolseid linke, toetab alternatiivseid andmevooge, ACL -i, kahte tüüpi tihendamist ja asünkroonset lugemis- / kirjutamisrežiimi. Siiani ei saa WinBtrfs selle failisüsteemi hooldamiseks kasutada mkfs.btrfs, btrfs-balance ja muid utiliite.
| Failisüsteem | Mac-si-mal-ny helitugevuse suurus | Ühe faili eel-del-suurus | Pikkus oma failinime järgi | Faili täisnime pikkus (sealhulgas tee juurest) | Failide ja / või kataloogide eelnev arv | Faili / kataloogi kuupäeva täpsuse täpsus | Õigused dos-tu-pa | Rasked lingid | Simivabad lingid | Pildistamised | Andmete tihendamine taustal | Andmete šifreerimine taustal | Vanaisa-pli-ka-mine andmeid |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| FAT16 | 2 GB 512 baiti sektorites või 4 GB 64 KB klastrites | 2 GB | 255 baiti LFN -iga | - | - | - | - | - | - | - | - | - | - |
| FAT32 | 8 TB 2 KB sektorites | 4 GB (2 ^ 32 - 1 bait) | 255 baiti LFN -iga | kuni 32 CDS -i alamkataloogi | 65460 | 10 ms (loo) / 2 s (muuda) | Ei | Ei | Ei | Ei | Ei | Ei | Ei |
| exFAT | PB 128 PB (2 ^ 32-1 klastrid 2 ^ 25-1 baiti) teoreetiline / 512 TB kolmandate osapoolte piirangute tõttu | 16 EB (2 ^ 64 - 1 bait) | 2796202 kataloogis | 10 ms | ACL | Ei | Ei | Ei | Ei | Ei | Ei | ||
| NTFS | 256 TB 64 KB klastrites või 16 TB 4K klastrites | 16 TB (7. võit) / 256 TB (8. võit) | 255 Unicode'i tähemärki (UTF-16) | 32 760 Unicode'i tähemärki, kuid mitte rohkem kui 255 märki elemendi kohta | 2^32-1 | 100 ns | ACL | Jah | Jah | Jah | Jah | Jah | Jah |
| HFS + | 8 EB (2 ^ 63 baiti) | 8 EB | 255 Unicode'i tähemärki (UTF-16) | ei ole eraldi piiratud | 2^32-1 | 1 sekund | Unix, ACL | Jah | Jah | Ei | Jah | Jah | Ei |
| APFS | 8 EB (2 ^ 63 baiti) | 8 EB | 255 Unicode'i tähemärki (UTF-16) | ei ole eraldi piiratud | 2^63 | 1 ns | Unix, ACL | Jah | Jah | Jah | Jah | Jah | Jah |
| Ext3 | 32 TB (teoreetiline) / 16 TB 4K klastrites (e2fs programmide piirangute tõttu) | 2 TB (teoreetiline) / 16 GB vanemate programmide jaoks | 255 Unicode'i tähemärki (UTF-16) | ei ole eraldi piiratud | - | 1 sekund | Unix, ACL | Jah | Jah | Ei | Ei | Ei | Ei |
| Ext4 | 1 EB (teoreetiline) / 16 TB 4K klastrites (e2fs programmide piirangute tõttu) | 16 TB | 255 Unicode'i tähemärki (UTF-16) | ei ole eraldi piiratud | 4 miljardit | 1 ns | POSIX | Jah | Jah | Ei | Ei | Jah | Ei |
| F2FS | 16 TB | 3,94 TB | 255 baiti | ei ole eraldi piiratud | - | 1 ns | POSIX ACL | Jah | Jah | Ei | Ei | Jah | Ei |
| BTRFS | 16 EB (2 ^ 64 - 1 bait) | 16 EB | 255 ASCII tähemärki | 2 ^ 17 baiti | - | 1 ns | POSIX ACL | Jah | Jah | Jah | Jah | Jah | Jah |
Kuulutasin seda juba kord oma ajaveebis, siis polnud sellest tegelikult midagi teada ja nüüd oli aeg lühikeseks, kuid järjekindlamaks tutvumiseks äsja tehtud ReFSiga.
Igal asjal on aga piir ja ka failisüsteemide võimalustel. Tänaseks on NTFS -i võimalused jõudnud oma piirideni: suurte andmekandjate kontrollimine võtab liiga kaua aega, ajakiri aeglustab juurdepääsu ja maksimaalne failisuurus on peaaegu saavutatud. Sellest aru saades rakendas Microsoft Windows 8 -s uue failisüsteemi - ReFS (Resilient File System). Arvatakse, et ReFS pakub parimat andmekaitset suurte ja kiirete kõvaketaste jaoks. Kindlasti on sellel ka oma puudused, kuid enne tõeliselt massilise kasutamise algust Windows 8 -s on neist raske rääkida.
Nii et proovime praegu mõista ReFS -i sisemust ja eeliseid.
ReFS kandis algselt koodnime "Protogon". Esimest korda rääkis temast laiemale avalikkusele umbes aasta tagasi Stephen Sinofsky- Microsofti Windowsi osakonna president, vastutav Windowsi ja Internet Explorer.
Ta ütles nende sõnadega:
„NTFS on tänapäeval kõige laialdasemalt kasutatav, täiustatud ja funktsioonirikas failisüsteem. Kuid Windowsi ümbermõtestamisel ja praegu arendame Windows 8, ei peatu me sellega. Seetõttu tutvustame koos Windows 8 -ga ka täiesti uut failisüsteemi. ReFS on ehitatud NTFS -i peale, nii et see säilitab kriitilise koostalitlusvõime, olles samal ajal projekteeritud ja konstrueeritud vastama järgmise põlvkonna salvestustehnoloogiate ja stsenaariumide vajadustele.
Windows 8 -s võetakse ReFS kasutusele ainult Windows Server 8 osana, sama lähenemisviisi kasutasime kõigi varasemate failisüsteemide rakendamisel. Loomulikult antakse rakenduste tasemel klientidele juurdepääs ReFS -i andmetele samamoodi nagu NTFS -i andmetele. Pidage meeles, et NTFS on endiselt PC -failisüsteemide valdkonnas juhtiv tehnoloogia. ”
Tõepoolest, nägime esimest korda ReFS -i serveri operatsioonisüsteemis Windows Server 8. Uut failisüsteemi ei arendatud nullist. Näiteks kasutab ReFS failide avamiseks, sulgemiseks, lugemiseks ja kirjutamiseks samu API -sid nagu NTFS. Samuti rändasid NTFS -ist üle paljud tuttavad funktsioonid - näiteks ketta krüptimine Bitlukustaja ja sümboolsed lingid raamatukogude jaoks. Kuid see kadus näiteks andmete pakkimine ja mitmeid muid funktsioone.
ReFS -i peamised uuendused on keskendunud faili- ja kaustastruktuuride loomisele ja haldamisele. Nende ülesanne on pakkuda automaatset veaparandust, maksimaalset skaleerimist ja toimimist alati võrgurežiimis.
ReFS -i struktuuride kettarakendus erineb põhimõtteliselt teistest Microsofti failisüsteemidest. Microsofti arendajad suutsid oma ideid realiseerida, rakendades ReFS-i andmebaasidest hästi tuntud B-puu kontseptsiooni. Failisüsteemi kaustad on üles ehitatud tabeliteks, kus failid on kirjed. Need omakorda saavad teatud atribuudid lisatud alamtabeliteks, luues hierarhilise puustruktuuri. Isegi vaba kettaruum on paigutatud tabelitesse.
Koos kõigi süsteemielementide tegeliku 64-bitise numeratsiooniga välistab see "kitsaskohtade" ilmumise selle edasise skaleerimise ajal
Selle tulemusena on ReFS -süsteemi tuum objektitabel - keskne kataloog, mis loetleb kõik süsteemi tabelid. Sellel lähenemisel on oluline eelis: ReFS on loobunud keerulisest logihaldusest ja pühendab uue failiteabe vabale ruumile - see hoiab ära selle ülekirjutamise.
« Lehtede kataloog"Kas trükitud kirjed. Kaustaobjekti jaoks on kolm põhitüüpi kirjet: kataloogikirjeldus, registrikirje ja pesastatud objekti kirjeldus. Kõik sellised kirjed on pakitud eraldi B ± puuna koos kausta identifikaatoriga; selle puu juur on puu “Kataloog” leht B ±, mis võimaldab peaaegu kõik kirjed kausta pakkida. Alumisel tasemel, kaustapuu lehtedel B ± on peamiselt kataloogikirjelduse kirje, mis sisaldab kausta põhiandmeid (nimi, "standardteave", failinime atribuut jne).
Edasi on kataloogis paigutatud registrikirjed: lühikesed struktuurid, mis sisaldavad teavet kaustas sisalduvate üksuste kohta. Need kirjed on oluliselt lühemad kui NTFS, mis muudab mahu metaandmete ülekoormamiseks vähem.
Lõpus on kataloogikirjed. Kaustade puhul sisaldavad need elemendid pakendi nime, kataloogi kataloogi identifikaatorit ja „standardteabe” struktuuri. Failide puhul pole identifikaatorit - selle asemel sisaldab struktuur kõiki faili põhiandmeid, sealhulgas faili tükkpuu juurt B ±. Sellest tulenevalt võib fail koosneda peaaegu suvalisest arvust fragmentidest.
Nagu NTFS, eristab ReFS põhimõtteliselt failiteavet (metaandmeid) ja failisisu (kasutajaandmeid). Kaitsefunktsioone pakutakse aga mõlemale ühtemoodi. Metaandmed on vaikimisi kaitstud kontrollsummadega - sama kaitse (soovi korral) saab kasutajaandmetele. Need kontrollsummad asuvad kettal üksteisest ohutus kauguses - nii on tõrke korral lihtsam andmeid taastada.
Tühja failisüsteemi metaandmete suurus on umbes 0,1% failisüsteemi enda suurusest (st umbes 2 GB 2 TB mahu kohta). Mõned põhilised metaandmed on dubleeritud, et tagada parem kokkupõrge
ReFS -i variant, mida me nägime Windows Server 8 beeta, toetab ainult 64KB andmekogumeid ja 16KB metaandmete klastreid. Praegu ignoreeritakse ReFS -köite loomisel parameetrit "Klastri suurus" ja seda eeldatakse alati vaikimisi. Failisüsteemi vormindamisel on 64 kB ka ainus klastri suuruse valik.
Olgem ausad, see klastri suurus on enam kui piisav mis tahes suurusega failisüsteemide korraldamiseks. Kõrvalmõju on aga märgatav üleliigne andmesalvestus (1-baidine fail kettal võtab täieliku 64 KB ploki).
Failisüsteemi ülesehituse osas on ReFS -il olemas kõik tööriistad, mida vajate failide turvaliseks taastamiseks isegi pärast suuremat riistvaratõrkeid. NTFS -failisüsteemi jms ajakirjade süsteemi peamine puudus on see, et ketta värskendamine võib salvestamise ajal elektrikatkestuse korral kahjustada varem salvestatud metaandmeid - see efekt on juba saanud stabiilse nime: nn. " rippuv salvestus».
Ennetama rippuvad rekordid, Microsoft valis uue lähenemisviisi, kus metaandmete struktuuride osad sisaldavad oma identifikaatoreid, mis võimaldab teil kontrollida struktuuride omandiõigust; metaandmete lingid sisaldavad viidatud plokkide 64-bitiseid kontrollsummasid.
Metaandmete struktuuri muutmine toimub kahes etapis. Esiteks luuakse vabale kettaruumile metaandmete uus (muudetud) koopia ja alles pärast seda edastab aatomi uuendamise toiming lingi vanalt (muutmata) uuele (muudetud) metaandmete alale. Siin välistab see logimise vajaduse, säilitades automaatselt andmete terviklikkuse.
Kirjeldatud skeem ei kehti aga kasutajaandmete kohta, seega kirjutatakse faili sisu kõik muudatused otse faili. Fail kustutatakse metaandmete struktuuri uuesti üles ehitades, mis salvestab metaandmete ploki eelmise versiooni kettale. See lähenemisviis võimaldab kustutatud faile taastada seni, kuni need uute kasutajaandmetega üle kirjutatakse.
Eraldi teema on ReFS tõrketaluvus kettakahjustuste korral. Süsteem on võimeline tuvastama kõiki plaadikahjustuste vorme, sealhulgas kadunud või valesse salvestuskohta salvestatud, samuti nn. natuke lagunemist(andmete halvenemine meedias)
Kui suvand "Integreeritud voog" on lubatud, kontrollib ReFS ka failide sisu kontrollsummade suhtes ja kirjutab alati muudatused failidesse kolmanda osapoole asukohas. See annab kindluse, et olemasolevad andmed ei lähe ülekirjutamisel kaduma. Kontrollsummasid värskendatakse andmete kirjutamisel automaatselt, nii et kui kirjutamine ebaõnnestub, on kasutajal kontrollimiseks faili versioon.
Veel üks huvitav ReFS -i turvalisuse teema on suhtlemine Panipaigad... ReFS ja Panipaigad kavandatud üksteist täiendama ühe salvestussüsteemi kahe komponendina. Lisaks jõudluse parandamisele Panipaigad kaitsta andmeid ketta osalise ja täieliku tõrke eest, salvestades koopiad mitmele kettale. Lugemisvigade ajal Panipaigad oskab koopiaid lugeda ja kirjutamisvigade korral (isegi meediaandmete täieliku kadumise korral lugemise / kirjutamise ajal) on võimalik andmeid "läbipaistvalt" ümber jagada. Nagu näitab praktika, ei ole sellisel rikkeel enamasti meediumiga mingit pistmist - see ilmneb andmete riknemise või andmete kadumise või vales kohas salvestamise tõttu.
Seda tüüpi tõrkeid saab ReFS tuvastada kontrollsummade abil. Rikke tuvastamisel suhtleb ReFS Panipaigad et lugeda kõiki võimalikke andmete koopiaid, ja valib kontrollsumma kontrollimise põhjal õige koopia. Süsteem annab siis Panipaigad käsk kahjustatud koopiate taastamiseks tõeliste koopiate põhjal. Kõik see toimub rakendatud vaatenurgast läbipaistvalt.
Nagu Microsofti veebisaidil öeldud Windows Server 8, kontrollsummad on alati lubatud ReFS -i metaandmete jaoks ja eeldades, et helitugevus on peegeldatud Panipaigad, on lubatud ka automaatne parandus. Kõiki sidusaid vooge kaitstakse ühtemoodi. See loob kasutajale suure terviklikkusega lõpplahenduse, mille abil saab suhteliselt ebausaldusväärse salvestusruumi muuta väga usaldusväärseks.
Mainitud terviklikkuse voogud kaitsevad failide sisu igasuguse andmete rikkumise eest. Seda omadust ei saa aga mõnel juhul kasutada.
Näiteks eelistavad mõned rakendused kena failide salvestamise haldamist koos mingisuguse failide sortimisega kettal. Kuna sidusad voogud jagavad plokid ümber iga kord, kui faili sisu muutub, on failide paigutus nende rakenduste jaoks liiga ettearvamatu. Andmebaasisüsteemid on selle ehe näide. Reeglina jälgivad sellised rakendused iseseisvalt failide sisu kontrollsummasid ning neil on võimalus API -dega suheldes andmeid kontrollida ja parandada.
Ma arvan, et see on selge, kuidas ReFS töötab ketta riknemise või salvestusrikke korral. Andmete kadumise tuvastamine ja ületamine võib olla raskem, kui natuke lagunemist"Kui ketta harva loetavate osade avastamata kahjustused hakkavad kiiresti kasvama. Sellise kahjustuse lugemise ja avastamise ajaks võib see olla juba koopiaid mõjutanud või andmed võivad muude rikete tõttu kaduda.
Protsessi ületamiseks natuke lagunemist, Microsoft on lisanud taustsüsteemi ülesande, mis perioodiliselt loputab metaandmeid ja andmeid järjepidevatest voogudest ReFS -köites peegelmälus. Puhastamine toimub kõigi üleliigsete koopiate lugemisega ja ReFS -i kontrollsummade abil nende õigsuse kontrollimisega. Kui kontrollsummad ei ühti, parandatakse ekslikud koopiad heade koopiatega.
Jääb oht, mida võib tavapäraselt nimetada "süsadmini õudusunenäoks". On juhtumeid, kuigi harva, kui isegi peegelpildis olev helitugevus võib kahjustuda. Näiteks võib ebaõnnestunud süsteemi mälu rikkuda andmeid, mis võivad seejärel kettale sattuda ja üleliigseid koopiaid kahjustada. Lisaks võivad paljud kasutajad otsustada mitte kasutada peegelpildis salvestusruume ReFS -i jaoks.
Sellistel juhtudel, kui helitugevus on kahjustatud, teostab ReFS "parandust" - funktsiooni, mis eemaldab andmed töömahu nimeruumist. Selle ülesanne on vältida korvamatut kahju, mis võib mõjutada õigete andmete kättesaadavust. Näiteks kui üks kataloogi fail on kahjustatud ja seda ei saa automaatselt parandada, eemaldab ReFS selle faili failisüsteemi nimeruumist, taastades ülejäänud mahu.
Oleme harjunud, et failisüsteem ei saa kahjustatud faili avada ega kustutada ning administraator ei saa sellega midagi ette võtta.
Kuid kuna ReFS suudab rikutud andmeid taastada, saab administraator selle faili varukoopiast taastada või rakenduse abil selle uuesti luua, vältides vajadust süsteemi välja lülitada. See tähendab, et kasutaja või administraator ei pea enam kontrollimis- ja parandusprotseduure võrguühenduseta tegema. Serverite puhul võimaldab see juurutada suuri andmemahtusid, ilma et oleks oht kahjustada pikka aku.
Loomulikult saab ReFS -i praktilisuse ja mugavuse (või vastupidiste omaduste) üle otsustada alles pärast seda, kui Windows 8 -ga arvutid on laialt levinud ja vähemalt pool aastat aktiivset tööd nendega on möödas. Vahepeal on potentsiaalsetel G8 kasutajatel rohkem küsimusi kui vastuseid.
Näiteks see: kas Windows 8 -s on võimalik andmeid hõlpsalt ja lihtsalt teisendada NTFS -ist ReFS -i ja vastupidi? Microsoft ütleb, et sisseehitatud vormingu teisendamise funktsiooni pole oodata, kuid teavet saab siiski kopeerida. ReFS -i ulatus on ilmne: esialgu saab seda kasutada ainult serveri suure andmehaldurina (tegelikult on see juba kasutusel). ReFS -iga väliseid draive veel pole - ainult sisemised. Ilmselgelt varustatakse ReFS aja jooksul rohkemate funktsioonidega ja suudab asendada pärandsüsteemi.
Microsoft ütleb, et tõenäoliselt juhtub see esimese Windows 8 hoolduspaketi väljaandmisega.
Microsoft väidab ka, et on testinud ReFS -i:
"Kasutades keerulist, ulatuslikku kümnete tuhandete testide komplekti, mis on NTFS -i jaoks kirjutatud rohkem kui kaks aastakümmet. Need testid loovad keerukaid kasutustingimusi, mis meie arvates võivad tekkida näiteks voolukatkestuse ajal ja mille probleemid on sageli seotud mastaapsuse ja jõudlusega. Seetõttu võime öelda, et ReFS -süsteem on kontrollitud keskkonnas testide jaoks valmis. "
Kuid samal ajal tunnistavad arendajad, et suure failisüsteemi esimese versioonina nõuab ReFS tõenäoliselt ettevaatust:
"Me ei iseloomusta ReFS -i Windows 8 jaoks beetaversioonina. Uus failisüsteem on vabastamiseks valmis, kui Windows 8 saab beetaversioonist välja, sest miski pole olulisem kui andmete usaldusväärsus. Seega, erinevalt süsteemi muudest aspektidest, nõuab see konservatiivset lähenemist esialgsele kasutamisele ja testimisele. "
Paljudel põhjustel võetakse ReFS kasutusele järkjärgulise plaani kohaselt. Esmalt Windows Serveri salvestussüsteemina, seejärel kasutajate salvestusruumina ja lõpuks alglaadimismahuna. Samasugust „ettevaatlikku lähenemist” on varem kasutatud ka uute failisüsteemide väljaandmisel.
Selles artiklis me selgitame selle välja milliseid funktsioone pakub ReFS ja kuidas see on parem kui NTFS -failisüsteem... Kuidas taastada andmeid ReFS -i kettaruumist. Microsofti uus ReFS -failisüsteem tutvustati algselt Windows Server 2012. See on ka kettaruumi tööriista osana Windows 10 -sse kaasatud. ReFS -i saab kasutada ajamite kogumi jaoks. Windows Server 2016 väljaandmisega on failisüsteemi täiustatud ja see on peagi saadaval ka Windows 10 uues versioonis.
Milliseid funktsioone pakub ReFS ja kuidas see on parem kui praegune NTFS -süsteem?
Sisu:Lühend Vastupidav failisüsteem ReFS on uus süsteem, mis põhineb NTFS -il. Praeguses etapis ei paku ReFS kodukasutajatele NTFS -i terviklikku asendust. Failisüsteemil on oma eelised ja puudused.
ReFS on mõeldud NTFS -i põhiprobleemide lahendamiseks. See on andmete rikkumise suhtes vastupidavam, käsitleb paremini suurenenud töökoormust ja skaleerub kergesti väga suurte failisüsteemide jaoks. Vaatame, mida see tähendab?
Failisüsteem kasutab metaandmete kontrollsummasid ja saab kasutada ka failiandmete kontrollsummasid. Faili lugedes või kirjutades kontrollib süsteem kontrollsummat, et veenduda selle õigsuses. Seega tuvastatakse rikutud andmed reaalajas.
ReFS on integreeritud kettaruumi funktsiooniga. Kui olete konfigureerinud peegelandmete salvestusruumi, kasutab Windows ReFS -i failisüsteemi rikete tuvastamiseks ja automaatseks parandamiseks, kopeerides andmed teisest kettast. See funktsioon on saadaval nii operatsioonisüsteemides Windows 10 kui ka Windows 8.1.
Kui failisüsteem tuvastab kahjustatud andmed, millel pole taastamiseks alternatiivset koopiat, kustutab ReFS need andmed kohe kettalt. See ei nõua süsteemi taaskäivitamist ega mäluseadme lahtiühendamist, nagu see on NTFS -i puhul.
Vajadus utiliidi chkdsk kasutamiseks kaob täielikult, kuna failisüsteem parandatakse tõrke hetkel automaatselt kohe. Uus süsteem on vastupidav muud tüüpi andmete riknemisele. NTFS kirjutab faili metaandmeid kirjutades otse faili metaandmeid. Kui selle aja jooksul toimub elektrikatkestus või arvuti krahh, saate andmete rikkumise.
Kui metaandmed muutuvad, loob ReFS andmetest uue koopia ja seob andmed failiga alles pärast metaandmete kettale kirjutamist. See välistab andmete rikkumise võimaluse. Seda funktsiooni nimetatakse kopeerimiseks kirjutamiseks ja see on olemas teistes populaarsetes Linuxi operatsioonisüsteemides: ZFS, BtrFS ja Apple'i APFS-failisüsteem.
ReFS on kaasaegsem ja toetab palju suuremaid köiteid ja pikemaid failinimesid kui NTFS. Pikemas perspektiivis on need olulised parandused. NTFS -is on failinimi piiratud 255 tähemärgiga, ReFS -is võib failinimi olla kuni 32768 tähemärki. Windows 10 võimaldab teil keelata NTFS -failisüsteemide tähemärgipiirangu, kuid see on ReFS -köidetel alati keelatud.
ReFS ei toeta enam DOS 8.3 vormingus lühikesi failinimesid. NTFS -i köites pääsete juurde C: \ Program Files \ v C: \ PROGRA ~ 1 \ et tagada ühilduvus vana tarkvaraga.
NTFS -i teoreetiline maksimaalne suurus on 16 eksabaiti, samas kui ReFS -i teoreetiline maksimaalne suurus on 262 144 eksabaiti. Kuigi praegu pole see tegelikult oluline, arenevad arvutid pidevalt.
ReFS ei olnud mõeldud failisüsteemi jõudluse parandamiseks võrreldes NTFS -iga. Microsoft on väga konkreetsetel juhtudel muutnud ReFSi palju tõhusamaks.
Näiteks kettaruumi kasutamisel toetab ReFS reaalajas optimeerimist. Oletame, et teil on ajamibassein, millel on kaks ketast, üks maksimaalse jõudluse ja teine mahutavuse jaoks. Maksimaalse jõudluse tagamiseks kirjutab ReFS alati andmed kiiremale kettale. Taustal teisaldab failisüsteem suured andmemahud automaatselt aeglasematele ketastele pikaajaliseks säilitamiseks.
Windows Server 2016 -s on Microsoft täiustanud ReFS -i, et tagada virtuaalmasina funktsioonide parem jõudlus. Microsoft Hyper-V virtuaalmasin kasutab neid eeliseid ära (teoreetiliselt saab iga virtuaalmasin kasutada ReFS-i).
Näiteks toetab ReFS plokkide kloonimist, mis kiirendab virtuaalmasina kloonimise ja kontrollpunktide liitmise protsessi. Virtuaalmasina koopia loomiseks peab ReFS kirjutama ainult uued metaandmed kettale ja pakkuma lingi olemasolevatele andmetele. Selle põhjuseks on asjaolu, et ReFS -is võivad mitu faili osutada kettale samadele aluseks olevatele andmetele.
Kui virtuaalmasin kirjutab uued andmed kettale, kirjutatakse need teise kohta ja virtuaalse masina esialgsed andmed jäävad kettale. See kiirendab oluliselt kloonimisprotsessi ja nõuab palju vähem ketta ribalaiust.
ReFS pakub ka uut funktsiooni "Harv VDL" mis võimaldab ReFS -il suurele failile kiiresti nulle kirjutada. See kiirendab oluliselt uue tühja fikseeritud suurusega virtuaalse kõvaketta (VHD) faili loomist. NTFS -is võib see toiming kesta 10 minutit, ReFS -is mitu sekundit.
Hoolimata paljudest eelistest ei saa ReFS veel NTFS -i asendada. Windows ei saa ReFS -partitsioonilt käivitada ja nõuab NTFS -i. ReFS ei toeta selliseid NTFS -i funktsioone nagu andmete pakkimine, failisüsteemi krüptimine, kõvad lingid, laiendatud atribuudid, andmete deduplikatsioon ja kettakvoodid. Kuid erinevalt NTFS -ist võimaldab ReFS BitLockeriga täielikku draivi krüptimist, sealhulgas süsteemi draivistruktuure.
Windows 10 ei luba partitsiooni vormindamist ReFS -iga, see failisüsteem on saadaval ainult kettaruumis. ReFS kaitseb mitme kõvaketta basseinides kasutatavaid andmeid kahjustuste eest. Windows Server 2016 -s saate köiteid vormindada, kasutades NTFS -i asemel ReFS -i. Sellist helitugevust saab kasutada virtuaalmasinate salvestamiseks, kuid operatsioonisüsteem saab ikkagi käivitada ainult NTFS -ist.
Hetman Partition Recovery võimaldab allkirjaanalüüsi algoritmi abil analüüsida ReFS -failisüsteemi hallatavat kettaruumi. Analüüsides seadmesektorit sektorite kaupa, leiab programm kindlad baitjärjestused ja kuvab need kasutajale. Andmete taastamine ReFS -i kettaruumist ei erine NTFS -failisüsteemiga töötamisest:
Uue failisüsteemi tulevik on üsna udune. Microsoft võib ReFS-i peenhäälestada, et asendada vananenud NTFS kõigis Windowsi versioonides. Praegu ei saa ReFS -i universaalselt kasutada ja see toimib ainult teatud ülesannete jaoks.
Kui olete juba Microsofti uued operatsioonisüsteemid installinud ja nendega töötanud: Windows Server 2012 ja Windows 8, olete ilmselt juba märganud, et uusi köiteid saab nüüd ReFS -failisüsteemis vormindada. Mis on failisüsteem ReFS? ReFS tähistab Vastupidav failisüsteem, st. vene keeles "Veakindel failisüsteem".
Microsoft näeb ReFS -failisüsteemi praeguse kõige populaarsema failisüsteemi NTFS järglasena, mille tehnoloogilised võimalused on juba piirini jõudnud. Eriti suurte andmekandjatega töötamisel tekivad nende tööga raskused: see on veakontrolli toimingu tegemisel liiga pikk ja ajakirja aeglane toimimine ning NTFS -failisüsteemi maksimaalse failisuuruse piirangute saavutamine.
Enamik ReFSi uuendusi seisneb faili- ja kaustastruktuuride loomises ja haldamises. Neid funktsioone rakendatakse automaatseks veaparanduseks, suureks mastaapsuseks ja alati võrgus töötamiseks. ReFS-failisüsteemi kaustad on üles ehitatud tabeliteks, kus failid on kirjed, mis omakorda võivad omada oma atribuute, mis on korraldatud alamtabelidena, rakendades andmebaasidest tuttavat hierarhilist B + puustruktuuri. Vaba kettaruum on organiseeritud ka tabelitesse.
ReFSi väljatöötamisel järgiti järgmisi eesmärke:
ReFS -i põhijooned
ReFS -failisüsteemi piirangud
ReFS pärib paljusid oma eelkäija NTFS funktsioone ja semantikat, sealhulgas:
Kõik ReFS -failisüsteemi andmed on juurdepääsetavad samade API -de kaudu, mida praegu kasutatakse NTFS -i partitsioonidele juurdepääsemiseks.
ReFS katkestas järgmised NTFS -i funktsioonid:
ReFS -i tugi võeti kasutusele operatsioonisüsteemides Windows 8 ja Windows Server 2012 ning ainult andmemahtude jaoks. See tähendab, et ReFS -i partitsioone ei saa kasutada opsüsteemi installimiseks ja käivitamiseks. Aja jooksul varustatakse ReFS rohkemate funktsioonidega ja suudab täielikult asendada vananenud NTFS -süsteemi. Kõik uued funktsioonid ilmuvad tõenäoliselt esimeses Windows 8 hoolduspaketis.
Lisaks ei saa ReFS -i veel kasutada eemaldatavate ja kaasaskantavate mäluseadmete jaoks (ReFS -i kasutatakse praegu ainult sisekandjate jaoks).
Masendav on see, et olemasolevaid NTFS -mahte ei saa vahepeal ReFS -iks teisendada. Andmed tuleb edastada tavalise kopeerimise teel.
Helitugevust saab vormindada ReFS -failisüsteemi kettahalduskonsooli kaudu. Kuid lisavalikuid, näiteks järjepidevuse kontrollimise lubamist, saab lubada ainult käsurealt.
Näiteks saate lubada ReFS -i järjepidevuse kontrollimise käsuga:
Vorming / fs: refs / q / i: lubage
Keelake järjepidevuse kontroll.
