Microsoftin uusi ReFS -tiedostojärjestelmä ilmestyi alun perin Windows 2012 -palvelimille. Se sisällytettiin vasta myöhemmin Windows 10: een, jossa sitä voidaan käyttää vain osana levyvarannon tallennustilaominaisuutta. Windows Server 2016: ssa Microsoft lupaa parantaa merkittävästi ReFS -tiedostojärjestelmän käyttöä, ja lisäksi painettujen huhujen mukaan ReFS voi korvata vanhentuneen NTFS -tiedostojärjestelmän uudessa Windows 10 -versiossa, jota kutsutaan ylpeänä Windowsiksi 10 Pro (kehittyneille tietokoneille).
Mutta mikä tarkalleen on ReF -tiedosto, miten se eroaa tällä hetkellä käytetystä tiedostojärjestelmästä NTFS ja mitä etuja sillä on?
Lyhyesti sanottuna se on suunniteltu vikasietoiseksi tiedostojärjestelmäksi. ReFS on uusi tiedostojärjestelmä, joka on rakennettu koodilla ja joka on pohjimmiltaan uusittu ja parannettu NTFS -tiedostojärjestelmä. Näitä ovat tietojen tallennuksen luotettavuus, vakaa toiminta stressitilassa, tiedostojen koot, asemat, hakemistot, taltioissa olevien tiedostojen ja hakemistojen määrää rajoittaa vain 64-bittisten numeroiden koko. Muista, että tämän arvon enimmäismäärä, suurin tiedostokoko on 16 exbibytes ja äänenvoimakkuus on 1 yobyte.
Tällä hetkellä ReFS ei korvaa NTFS: ää. Siinä on etuja ja haittoja. Mutta et voi esimerkiksi muotoilla levyä ja asentaa sille uutta Windows -kopiota kuten NTFS: ssä.
ReFS käyttää metatietojen tarkistussummia ja voi käyttää myös datatiedostojen tarkistussummia. Aina kun luet tai kirjoitat tiedostoja, ReFS tarkistaa tarkistussumman ja varmistaa, että se on oikein. Tämä tarkoittaa, että itse tiedostojärjestelmässä on työkalu, joka pystyy havaitsemaan vioittuneet tiedot lennossa.
ReFS on integroitu tallennustilaan. Jos olet määrittänyt ReFS-peilauksen, Windows voi helposti havaita tiedostojärjestelmän vioittumisen ja korjata sen automaattisesti kopioimalla peilatut tiedot vaurioituneelle levylle. Tämä ominaisuus on saatavana sekä Windows 10: lle että Windows 8.1: lle.
Jos ReFS havaitsee vioittuneet tiedot ja vaadittu kopio tiedoista ei ole käytettävissä palautettavaksi, tiedostojärjestelmä pystyy poistamaan vioittuneet tiedot levyltä välittömästi. Tämä ei vaadi järjestelmän uudelleenkäynnistystä, toisin kuin NTFS.
ReFS tekee enemmän kuin vain tarkistaa tiedostojen eheyden, kun niitä luetaan. Se tarkistaa automaattisesti tietojen eheyden tarkistamalla säännöllisesti kaikki levyn tiedostot, tunnistamalla ja korjaamalla vioittuneet tiedot. Tässä tapauksessa sinun ei tarvitse suorittaa ajoittain chkdsk -komentoa levyn tarkistamiseksi.
Uusi tiedostojärjestelmä on myös vastustuskykyinen muilla tavoin. Päivität esimerkiksi tiedoston metatiedot (vaikka tiedostonimen). NTFS -tiedostojärjestelmä muokkaa suoraan tiedoston metatietoja. Jos järjestelmä kaatuu (virta katkeaa) tällä hetkellä, tiedosto on todennäköisesti vahingoittunut. Kun muutat metatietoja, ReFS -tiedostojärjestelmä luo uuden kopion metatiedoista. Tiedostojärjestelmä ei korvaa vanhoja metatietoja, vaan kirjoittaa ne uuteen lohkoon. Tämä eliminoi mahdollisuuden vahingoittaa tiedostoa. Tätä strategiaa kutsutaan "kopioi ja kirjoita". Tämä strategia on käytettävissä muissa nykyaikaisissa tiedostojärjestelmissä, kuten ZFS ja BtrFS Linuxissa, sekä Applen uudessa APFS -tiedostojärjestelmässä.
ReFS on nykyaikaisempi kuin NTFS ja tukee paljon suurempia tietomääriä ja pidempiä tiedostonimiä. Tämä on erittäin tärkeää pitkällä aikavälillä.
NTFS -tiedostojärjestelmässä tiedostopolku on rajoitettu 255 merkkiin. ReFS: ssä enimmäismäärä merkkejä on jo vaikuttava 32 768 merkkiä. Tällä hetkellä Windows 10: ssä on mahdollisuus poistaa NTFS -merkkielementti käytöstä. Tämä raja on oletusarvoisesti poissa käytöstä ReFS -levyasemissa.
ReFS ei tue DOS 8.3 -tiedostonimiä. NTFS -taltioissa sinulla on pääsy kansioihin "CProgram Files", "CProgra`1". Niitä tarvitaan yhteensopivuuteen vanhan kanssa ohjelmisto... ReFS: stä et löydä tottuneita kansioita. Ne poistetaan.
NTFS: n tukema teoreettinen enimmäismäärä dataa on 16 eksatavua, ReFS tukee jopa 262 144 eksatavua. Nyt tämä luku näyttää olevan valtava.
Kehittäjät eivät pyrkineet luomaan tehokkaampaa tiedostojärjestelmää. He tekivät virtaviivaisemman järjestelmän.
Esimerkiksi kun sitä käytetään yhdessä taulukon kanssa, ReFS tukee reaaliaikaista tason optimointia. Sinulla on koottu kahden levyn asema. Ensimmäinen levy valitaan suurelle nopeudelle, nopea pääsy tietoihin. Toinen levy valitaan luotettavuuskriteerillä tietojen pitkäaikaiseen tallentamiseen. Taustalla ReFS siirtää automaattisesti suuria datapaloja hitaammalle levylle, mikä varmistaa tietojen tallentamisen luotettavasti.
Windows Server 2016: ssa kehittäjät lisäsivät työkalun, joka parantaa suorituskykyä käyttämällä virtuaalikoneiden tiettyjä ominaisuuksia. Esimerkiksi ReFS tukee lohkojen kopiointia, mikä nopeuttaa virtuaalikoneiden kopiointia ja tarkistuspisteiden yhdistämistä. Luokseen kopion virtuaalikoneesta ReFS luo uuden kopion levyn metatiedoista ja tarjoaa linkin levylle kopioituun dataan. Tämä johtuu siitä, että useat tiedostot voivat viitata samoihin taustalla oleviin tietoihin levyllä ReFS: n avulla. Kun olet muuttanut tietoja virtuaalikoneen kanssa, tiedot kirjoitetaan levylle eri paikkaan ja virtuaalikoneen alkuperäiset tiedot jäävät levylle. Tämä nopeuttaa huomattavasti kopioiden luomista ja vähentää levyn kuormitusta.
ReFS tukee ”Sparse VDL” (harvat tiedostot). Ohut tiedosto on tiedosto, jossa nolla tavua sisältävä sekvenssi korvataan kyseisen sekvenssin tiedoilla (reikien luettelo). Reiät ovat erityinen nolla tavun sekvenssi tiedoston sisällä, ei kirjoitettu levylle. Reiätiedot itse tallennetaan tiedostojärjestelmän metatietoihin.
Harva tiedostotukitekniikka mahdollistaa nopean nollien kirjoittamisen suurelle tiedostolle. Tämä nopeuttaa huomattavasti uuden tyhjän, kiinteän kokoisen virtuaalisen kiintolevytiedoston (VHD) luomista. Tällaisen tiedoston luominen ReFS: ssä kestää muutaman sekunnin, kun taas NTFS: ssä se kestää jopa 10 minuuttia.
Kaikki edellä kuvatut asiat kuulostavat hyviltä, mutta et voi vaihtaa ReFS: ään NTFS: stä. Windows ei voi käynnistyä ReFS: stä, mikä vaatii NTFS: n.
ReFS: stä puuttuu monia NTFS -tekniikoita. Esimerkiksi tiedostojärjestelmien pakkaus ja salaus, kovat linkit, laajennetut määritteet, tietojen deduplikointi ja kiintiöt. Toisin kuin NTFS, ReFS tukee täyden datan salaustekniikkaa - BitLocker.
Windows 10: ssä et voi alustaa levyosioa ReFS: llä. Uusi tiedostojärjestelmä on saatavana vain tallennusjärjestelmille, joiden päätehtävänä on suojata tiedot vaurioilta. Windows Server 2016: ssa voit alustaa levyosion ReFS: llä. Voit käyttää sitä virtuaalikoneiden suorittamiseen. Mutta et voi valita sitä käynnistyslevyksi. Windows käynnistyy vain NTFS -tiedostojärjestelmästä.
On epäselvää, mitä Microsoftilla on tulevaisuudessa varaa uudelle tiedostojärjestelmälle. Ehkä jonain päivänä se korvaa NTFS: n kokonaan kaikissa Windows -versioissa. Mutta tällä hetkellä ReFS: ää voidaan käyttää vain tiettyihin tehtäviin.
Edellä on puhuttu paljon uuden käyttöjärjestelmän tueksi. Haitat ja edut on kuvattu. Ehdotan lopettamista ja yhteenvedon tekemistä. Mihin tarkoituksiin se on mahdollista, ja ehkä se on tarpeen käyttää ReFS: ää.
Windows 10: ssä ReFS on käytettävissä vain yhdessä Storage Spaces -komponentin kanssa. Muista alustaa tallennusasema ReFS: llä eikä NTFS: llä. Tässä tapauksessa voit täysin arvostaa tietojen tallennuksen luotettavuutta.
Windows Serverissä voit alustaa ReFS -osion levynhallintakonsolin Windows -vakiotyökalulla. On suositeltavaa varmuuskopioida ReFS, jos käytät virtuaalipalvelimia. Muista kuitenkin, että käynnistyslevyn on oltava NTFS -alustettu. ReFS -tiedostojärjestelmästä käynnistämistä ei tueta Windows -käyttöjärjestelmissä.
Uusi tiedostojärjestelmä ReFS ja Windows 10| 2017-06-28 06:34:15 | Pääkäyttäjä | Järjestelmäohjelmisto | https: //site/media/system/images/new.png | Microsoft ReFS: n uusi tiedostojärjestelmä on korvannut vanhentuneen NTFS: n. Mitkä ovat ReFS: n edut ja miten se eroaa NTFS: stä | refs, refs tai ntfs, refs windows 10, refs tiedostojärjestelmä, uudet tiedostojärjestelmät, ntfs -järjestelmä, ntfs -tiedostojärjestelmä
Miksi älypuhelin ei voi käynnistää ohjelmia muistikortilta? Miten ext4 eroaa pohjimmiltaan ext3: sta? Miksi flash -asema elää pidempään, jos se on alustettu NTFS: ään FAT: n sijasta? Mikä on F2FS: n suurin ongelma? Vastaukset löytyvät tiedostojärjestelmien rakenteen erityispiirteistä. Puhumme heistä.
Tiedostojärjestelmät määrittävät, miten tiedot tallennetaan. Ne määrittävät, mitä rajoituksia käyttäjä kohtaa, kuinka nopeasti luku- ja kirjoitusoperaatiot tulevat olemaan ja kuinka kauan asema toimii ilman häiriöitä. Tämä koskee erityisesti budjetti -SSD -levyjä ja heidän nuorempia veljiään - flash -asemia. Kun tiedät nämä ominaisuudet, voit purkaa minkä tahansa järjestelmän maksimin ja optimoida sen käytön tiettyihin tehtäviin.
Sinun on valittava tiedostojärjestelmän tyyppi ja parametrit aina, kun sinun on tehtävä jotain ei-triviaalia. Haluat esimerkiksi nopeuttaa yleisimpiä tiedostooperaatioita. Tiedostojärjestelmän tasolla tämä voidaan saavuttaa useilla tavoilla: indeksointi tarjoaa nopeat haut ja ilmaisten lohkojen ennakkovaraus helpottaa usein muuttuvien tiedostojen korvaamista. Tietojen optimointi sisään RAM-muisti vähentää vaadittujen I / O -toimintojen määrää.
Nykyaikaisten tiedostojärjestelmien ominaisuudet, kuten laiska kirjoittaminen, deduplikointi ja muut kehittyneet algoritmit, pidentävät käytettävyyttä. Ne ovat erityisen tärkeitä halvoille SSD -asemille, joissa on TLC -muistisirut, flash -asemat ja muistikortit.
On olemassa eri optimointeja eri tasojen levyjärjestelmille: esimerkiksi tiedostojärjestelmä voi tukea kevyttä äänenvoimakkuuden peilausta, tilannekuvia tai dynaamista skaalausta ottamatta asemaa offline -tilaan.
Käyttäjät työskentelevät pääasiassa käyttöjärjestelmän tarjoaman tiedostojärjestelmän kanssa oletuksena. He luovat harvoin uusia levyosioita ja vielä harvemmin ajattelevat asetuksiaan - he käyttävät vain suositeltuja parametreja tai jopa ostavat esimuodostettua mediaa.
Windows -faneille kaikki on yksinkertaista: NTFS kaikilla levyosioilla ja FAT32 (tai sama NTFS) flash -asemilla. Jos siinä on NAS ja jotakin muuta tiedostojärjestelmää, niin se jää useimmille käsittämättömäksi. He yksinkertaisesti muodostavat yhteyden verkkoon ja lataavat tiedostoja ikään kuin mustasta laatikosta.
Mobiililaitteissa, joissa on Android, ext4 löytyy useimmiten sisäisestä muistista ja FAT32 microSD -korteista. Applelle ei ole väliä, millainen tiedostojärjestelmä heillä on: HFS +, HFSX, APFS, WTFS ... heille on vain kauniita kansioiden ja tiedostojen kuvakkeita, jotka on piirtänyt parhaat suunnittelijat. Linux -käyttäjillä on rikkain vaihtoehto, mutta voit lisätä tuen tiedostojärjestelmille, jotka eivät ole alkuperäisiä käyttöjärjestelmälle sekä Windowsissa että macOS: ssa - siitä lisää myöhemmin.
Yli sata eri tiedostojärjestelmää on luotu, mutta hieman yli tusinaa voidaan kutsua asiaankuuluvaksi. Vaikka ne kaikki oli suunniteltu erityissovelluksiinsa, monet päätyivät käsitteellisesti toisiinsa. Ne ovat samankaltaisia, koska ne käyttävät samantyyppisiä esitysrakenne (meta) tietoja-B-puut ("bi-puut").
Kuten mikä tahansa hierarkkinen järjestelmä, B -puu alkaa juuritietueesta ja haarautuu edelleen viimeisiin elementteihin - yksittäisiin tietueisiin tiedostoista ja niiden määritteistä tai "lehdistä". Tällaisen loogisen rakenteen luomisen päätarkoitus oli nopeuttaa tiedostojärjestelmäobjektien etsimistä suurilta dynaamisilta matriiseilta - kuten useiden teratavujen kiintolevyiltä tai jopa vaikuttavammilta RAID -ryhmiltä.
B-puut vaativat paljon vähemmän levyn käyttöoikeuksia kuin muunlaiset B-puut, kun ne suorittavat samoja toimintoja. Tämä saavutetaan, koska B-puiden lopulliset kohteet sijaitsevat hierarkkisesti samalla korkeudella ja kaikkien toimintojen nopeus on vain verrannollinen puun korkeuteen.
Kuten muillakin tasapainoisilla puilla, B-puilla on sama polun pituus juurista mihin tahansa lehtiin. Kasvamisen sijaan ne haarautuvat enemmän ja kasvavat leveämmäksi: kaikki B-puun haarakohdat sisältävät paljon viittauksia aliobjekteihin, mikä helpottaa niiden löytämistä vähemmän puheluita. Suuri määrä osoittimia vähentää pisimpien levytoimintojen määrää - pään asemointia mielivaltaisia lohkoja luettaessa.
B-puiden käsite muotoiltiin jo 1970-luvulla, ja sen jälkeen on tehty useita parannuksia. Se toteutetaan tavalla tai toisella NTFS-, BFS-, XFS-, JFS-, ReiserFS- ja monissa DBMS -järjestelmissä. He ovat kaikki serkkuja tietojen järjestämisen perusperiaatteiden kannalta. Erot koskevat yksityiskohtia, jotka ovat usein varsin tärkeitä. Asiaan liittyvien tiedostojärjestelmien haitta on myös yleinen: ne kaikki luotiin toimimaan levyjen kanssa jo ennen SSD -levyjen ilmaantumista.
SSD-asemat korvaavat vähitellen levyasemia, mutta toistaiseksi niiden on pakko käyttää heille vieraita tiedostojärjestelmiä, perittyjä. Ne on rakennettu flash -muistiryhmille, joiden periaatteet poikkeavat levylaitteiden periaatteista. Erityisesti flash -muisti on poistettava ennen kirjoittamista, eikä tätä toimintoa NAND -siruilla voida suorittaa yksittäisten solujen tasolla. Se on mahdollista vain suurille lohkoille kokonaisuutena.
Tämä rajoitus johtuu siitä, että NAND -muistissa kaikki solut yhdistetään lohkoiksi, joista jokaisella on vain yksi yhteinen yhteys ohjausväylään. Emme mene haun yksityiskohtiin ja kuvaamme koko hierarkiaa. Pelkkä solutoimintojen toimintaperiaate ja se, että flash -muistilohkojen koot ovat yleensä suurempia kuin missä tahansa tiedostojärjestelmässä käsitellyt lohkot, ovat tärkeitä. Siksi kaikki osoitteet ja komennot NAND -flash -asemille on käännettävä FTL (Flash Translation Layer) -kerroskerroksen kautta.
Flash -muistiohjaimet tarjoavat yhteensopivuuden levylaitteiden logiikan kanssa ja tukevat niiden käyttöliittymien komentoja. Yleensä FTL toteutetaan heidän laiteohjelmistossaan, mutta se voi (osittain) toimia isäntänä - esimerkiksi Plextor kirjoittaa SSD -levyilleen ohjaimet, jotka nopeuttavat kirjoittamista.
Et voi tehdä ilman FTL: ää ollenkaan, koska jopa yhden bitin kirjoittaminen tiettyyn soluun johtaa useiden toimintojen käynnistämiseen: ohjain etsii vaaditun solun sisältävän lohkon; lohko luetaan kokonaan, kirjoitetaan välimuistiin tai vapaaseen tilaan, poistetaan sitten kokonaan, minkä jälkeen se kirjoitetaan takaisin tarvittavilla muutoksilla.
Tämä lähestymistapa muistuttaa armeijan jokapäiväistä elämää: antaakseen käskyn yhdelle sotilaalle kersantti muodostaa yleisen kokoonpanon, kutsuu köyhän miehen epäjärjestykseen ja käskee loput hajottamaan. Nyt harvinaisessa NOR -muistissa organisaatio oli spetsnaz: jokaista solua hallittiin itsenäisesti (jokaisella transistorilla oli yksilöllinen yhteys).
Ohjaimilla on yhä enemmän tehtäviä, koska jokaisen flash -muistin sukupolven aikana sen valmistuksen tekninen prosessi vähenee, jotta lisätään tiheyttä ja pienennetään tallennuskustannuksia. Teknisten standardien ohella myös sirujen arvioitu käyttöikä lyhenee.
Yksitason SLC-soluilla varustetuilla moduuleilla oli ilmoitettu resurssi 100 tuhatta uudelleenkirjoitusjaksoa ja jopa enemmän. Monet heistä toimivat edelleen vanhoissa flash -asemissa ja CF -korteissa. Yritysluokan MLC (eMLC) väitti resurssin olevan 10–20 tuhatta, kun taas tavanomaisessa kuluttajatason MLC: ssä sen arvioidaan olevan 3–5 tuhatta. Tämän tyyppinen muisti on aktiivisesti täynnä vielä halvempaa TLC: tä, jonka resurssi tuskin saavuttaa tuhat kierrosta. Flash -muistin käyttöiän pitäminen hyväksyttävällä tasolla on tehtävä ohjelmiston hienosäädön avulla, ja uusista tiedostojärjestelmistä on tulossa yksi niistä.
Valmistajat olettivat aluksi, että tiedostojärjestelmällä ei ole merkitystä. Ohjaimen itsensä on ylläpidettävä lyhytikäisiä kaikentyyppisiä muistisoluja, jotka jakavat kuormituksen optimaalisesti. Tiedostojärjestelmäohjaimelle se simuloi tavallista levyä ja itse suorittaa matalan tason optimointeja kaikilla käyttöoikeuksilla. Käytännössä optimointi vaihtelee kuitenkin eri laitteiden maagisista kuvitteellisiin.
Yritysten SSD-levyissä sisäänrakennettu ohjain on pieni tietokone. Siinä on valtava muistipuskuri (puoli keikkaa ja enemmän), ja se tukee monia menetelmiä tietojen käsittelyn tehostamiseksi, mikä välttää tarpeettomat uudelleenkirjoitusjaksot. Siru järjestää kaikki välimuistin lohkot, kirjoittaa laiskoja kirjoituksia, suorittaa kaksoiskappaleita lennossa, varaa joitakin lohkoja ja tyhjentää muita taustalta. Kaikki tämä taikuus tapahtuu täysin huomaamatta käyttöjärjestelmä, ohjelmat ja käyttäjä. Tällaisen SSD -aseman kanssa ei todellakaan ole väliä mitä tiedostojärjestelmää käytetään. Sisäisellä optimoinnilla on paljon suurempi vaikutus suorituskykyyn ja resursseihin kuin ulkoisella.
Budget SSD -asemat (ja vielä enemmän - flash -asemat) on varustettu paljon vähemmän älykkäillä ohjaimilla. Niiden välimuisti on katkaistu tai puuttuu, ja kehittyneitä palvelintekniikoita ei käytetä lainkaan. Muistikorteissa ohjaimet ovat niin alkeellisia, että usein väitetään, että niitä ei ole ollenkaan. Siksi halvoille laitteille, joissa on flash -muisti, ulkoiset kuormituksen tasapainotusmenetelmät ovat edelleen tärkeitä - pääasiassa käyttämällä erikoistuneita tiedostojärjestelmiä.
Yksi ensimmäisistä yrityksistä kirjoittaa tiedostojärjestelmä, jossa otettaisiin huomioon flash -muistin järjestämisperiaatteet, oli JFFS - Journaling Flash File System. Alun perin ruotsalaisen Axis Communications -yrityksen kehitys keskittyi Axisin 1990 -luvulla tuottamien verkkolaitteiden muistitehokkuuden parantamiseen. Ensimmäinen JFFS -versio tuki vain NOR -muistia, mutta jo toisessa versiossa se ystävystyi NANDin kanssa.
JFFS2: n käyttö on tällä hetkellä rajoitettua. Useimmiten sitä käytetään edelleen sulautettujen järjestelmien Linux -jakeluissa. Se löytyy reitittimistä, IP -kameroista, NAS: sta ja muista esineiden Internetin säännöllisistä käyttäjistä. Yleensä aina, kun tarvitaan pieni määrä luotettavaa muistia.
JFFS2: n lisäkehitystyö oli LogFS, joka tallensi inodes erilliseen tiedostoon. Tämän idean kirjoittajat ovat IBM Jorn Engelin saksalaisen osaston työntekijä ja Osnabrückin yliopiston professori Robert Mertens. LogFS: n lähdekoodi on saatavilla GitHubissa. Sen perusteella, että viimeinen muutos siihen tehtiin neljä vuotta sitten, LogFS ei ole saavuttanut suosiota.
Mutta nämä yritykset kannustivat toisen erikoistuneen tiedostojärjestelmän - F2FS - syntymiseen. Sen on kehittänyt Samsung Corporation, joka muodostaa suuren osan maailmassa tuotetusta flash -muistista. Samsung valmistaa NAND Flash -siruja omille laitteilleen ja muille yrityksille sekä kehittää SSD -asemia, joissa on täysin uusia käyttöliittymiä vanhojen levyasemien sijaan. Flash -muistille optimoidun erikoistuneen tiedostojärjestelmän luominen on ollut Samsungin näkökulmasta kauan sitten tarpeen.
Neljä vuotta sitten, vuonna 2012, Samsung loi F2FS: n (Flash Friendly File System). Sen idea on hyvä, mutta toteutus osoittautui kosteaksi. Keskeinen tehtävä F2FS: n luomisessa oli yksinkertainen: vähentää solujen uudelleenkirjoitustoimintojen määrää ja jakaa niiden kuormitus mahdollisimman tasaisesti. Tämä edellyttää toimintojen suorittamista useiden solujen kanssa samassa lohkossa samanaikaisesti eikä raiskausta niitä yksi kerrallaan. Tämä tarkoittaa, että emme tarvitse olemassa olevien lohkojen välitöntä uudelleenkirjoittamista käyttöjärjestelmän ensimmäisestä pyynnöstä, vaan komentojen ja datan välimuistiin tallentamista, uusien lohkojen lisäämistä vapaaseen tilaan ja solujen poistamisen viivästymistä.
Nykyään F2FS -tuki on jo virallisesti otettu käyttöön Linuxissa (ja siten Androidissa), mutta se ei tarjoa käytännössä mitään erityisiä etuja. Tämän tiedostojärjestelmän pääominaisuus (lykätty korvaus) on johtanut ennenaikaisiin johtopäätöksiin sen tehokkuudesta. Vanha välimuistitemppu huijasi jopa vertailuarvojen varhaisia versioita, joissa F2FS osoitti näennäistä etua muutamalla prosentilla (kuten odotettiin) tai jopa useita kertoja, mutta suuruusluokkia. Se on vain, että F2FS -ohjain ilmoitti suorittaneensa operaation, jonka ohjain juuri aikoi tehdä. Kuitenkin, jos F2FS: n todellinen suorituskyvyn kasvu on pieni, kennojen kuluminen on varmasti pienempi kuin käytettäessä samaa ext4: ää. Optimoinnit, joita halpa ohjain ei voi tehdä, suoritetaan itse tiedostojärjestelmän tasolla.
Vaikka F2FS pidetään eksoottisena geeksille. Jopa Samsungin omat älypuhelimet käyttävät edelleen ext4: tä. Monet pitävät sitä ext3: n jatkokehityksenä, mutta tämä ei ole täysin totta. Tämä on enemmän vallankumous kuin 2 TB: n tiedostoesteen rikkominen ja muiden mittareiden lisääminen.
Kun tietokoneet olivat suuria ja tiedostot pieniä, osoite oli helppoa. Jokaiselle tiedostolle annettiin tietty määrä lohkoja, joiden osoitteet syötettiin vastaavuustaulukkoon. Näin toimi ext3 -tiedostojärjestelmä, joka on edelleen käytössä. Mutta ext4: ssä ilmestyi perustavanlaatuisesti erilainen tapa käsitellä - ulottuvuudet.
Laajennuksia voidaan ajatella inode -laajennuksina erillisinä lohkojoukkoina, joita käsitellään kokonaisuudessaan vierekkäisinä jaksoina. Yksi laajuus voi sisältää koko keskikokoisen tiedoston, ja suurille tiedostoille riittää, kun varaat tusinan tai kaksi laajuutta. Tämä on paljon tehokkaampaa kuin käsitellä satoja tuhansia pieniä neljän kilotavun lohkoja.
Itse kirjoitusmekanismi on muuttunut ext4: ssä. Nyt lohkojen jakautuminen tapahtuu välittömästi yhdessä pyynnössä. Eikä etukäteen, vaan juuri ennen tietojen kirjoittamista levylle. Viivästyneen monilohkoisen allokoinnin avulla voit päästä eroon tarpeettomista operaatioista, joita ext3 teki: siinä uuden tiedoston lohkot jaettiin välittömästi, vaikka se mahtuisi kokonaan välimuistiin ja oli tarkoitus poistaa väliaikaisesti.
Tasapainoisten puiden ja niiden muokkausten lisäksi on muitakin suosittuja loogisia rakenteita. On tiedostojärjestelmiä, joilla on perustavanlaatuisesti erilainen organisaatio - esimerkiksi lineaarinen. Käytät luultavasti ainakin yhtä niistä paljon.
Arvaa arvoitus: kaksitoista-vuotiaana hän alkoi saada painoa, kuusitoistavuotiaana hän oli tyhmä lihava nainen, ja kolmekymmentäkaksi-vuotiaana hän tuli lihavaksi ja pysyi yksinkertaisena. Kuka hän on?
Aivan oikein, tämä on tarina FAT -tiedostojärjestelmästä. Yhteensopivuusvaatimukset varmistivat hänelle huonon perinnön. Levykkeillä se oli 12-bittinen, kiintolevyillä alun perin 16-bittinen ja on tähän päivään asti 32-bittinen. Kussakin seuraavassa versiossa osoitettavien lohkojen määrä kasvoi, mutta itse asiassa mikään ei muuttunut.
Vielä suosittu FAT32 -tiedostojärjestelmä ilmestyi kaksikymmentä vuotta sitten. Nykyään se on edelleen alkeellinen eikä tue ACL -tiedostoja, kiintiöitä, taustan pakkaamista tai muita nykyaikaisia tietojen optimointitekniikoita.
Miksi FAT32 tarvitaan nykyään? Kaikki sama vain yhteensopivuustarkoituksiin. Valmistajat uskovat perustellusti, että mikä tahansa käyttöjärjestelmä voi lukea FAT32 -osion. Siksi he luovat sen ulkoisille kiintolevyille, USB -muistille ja muistikorteille.
Älypuhelimissa käytettävät MicroSD (HC) -kortit on alustettu oletuksena FAT32 -muotoon. Tämä on suurin este sovellusten asentamiselle ja tietojen siirtämiselle sisäisestä muistista. Voit voittaa sen luomalla kortille ext3- tai ext4 -osion. Kaikki tiedostomääritteet (mukaan lukien omistaja ja käyttöoikeudet) voidaan siirtää siihen, joten mikä tahansa sovellus voi toimia ikään kuin se olisi käynnistetty sisäisestä muistista.
Windows ei voi luoda useampaa kuin yhtä osiota flash -asemille, mutta tätä varten voit käyttää Linuxia (ainakin virtuaalikoneessa) tai edistynyttä apuohjelmaa loogisen osion käsittelemiseksi - esimerkiksi MiniTool Partition Wizard Free. Löydettyään kortilta ylimääräisen ensisijaisen osion, jossa on ext3 / ext4, Link2SD -sovellus ja vastaavat tarjoavat paljon enemmän vaihtoehtoja kuin yksittäisen FAT32 -osion tapauksessa.
Toinen argumentti FAT32: n puolesta on päiväkirjojen puute, mikä tarkoittaa nopeampia kirjoitusoperaatioita ja vähemmän NAND Flash -muistisolujen kulumista. Käytännössä FAT32: n käyttö johtaa päinvastaiseen ja aiheuttaa monia muita ongelmia.
Flash -asemat ja muistikortit kuolevat vain nopeasti, koska kaikki FAT32: n muutokset aiheuttavat samojen sektoreiden korvaamisen, joilla on kaksi tiedostotaulukkoketjua. Tallensin koko verkkosivun, ja se kirjoitettiin uudelleen sata kertaa - lisäämällä joka kerta toinen pieni GIF -muistitikku. Käynnistitkö kannettavan ohjelmiston? Hän loi väliaikaisia tiedostoja ja muuttaa niitä jatkuvasti työn aikana. Siksi on paljon parempi käyttää NTFS: ää flash-asemissa, joissa on vikasietoinen $ MFT-taulukko. Pienet tiedostot voidaan tallentaa suoraan päätiedostotaulukkoon, ja niiden laajennukset ja kopiot kirjoitetaan flash -muistin eri alueille. Lisäksi NTFS -indeksointi nopeuttaa hakuja.
Toinen ongelma, jonka useimmat käyttäjät kohtaavat, on se, että on mahdotonta kirjoittaa yli 4 Gt: n tiedostoa FAT32 -osioon. Syynä on se, että FAT32: ssa tiedoston kokoa kuvaavat 32 bittiä tiedostojen varaustaulukossa, ja 2 ^ 32 (miinus yksi, tarkalleen) antaa vain neljä keikkaa. On käynyt ilmi, että normaalilaatuista elokuvaa tai DVD -kuvaa ei voi tallentaa vastikään ostetulle flash -asemalle.
Suurten tiedostojen kopioiminen on edelleen puoli ongelmaa: kun yrität tehdä tämän, virhe näkyy ainakin heti. Muissa tilanteissa FAT32 toimii aikapommina. Esimerkiksi kopioit kannettavan ohjelmiston USB -muistitikulle ja voit aluksi käyttää sitä ilman ongelmia. Pitkän ajan kuluttua yhden ohjelman (esimerkiksi kirjanpidon tai postin) tietokanta on paisunut, ja ... se vain lakkaa päivittämästä. Tiedostoa ei voi korvata, koska se on saavuttanut 4 Gt: n rajan.
Vähemmän ilmeinen ongelma on, että FAT32: ssa tiedoston tai hakemiston luontipäivämäärä voidaan määrittää kahden sekunnin tarkkuudella. Tämä ei riitä monille salausohjelmille, jotka käyttävät aikaleimoja. Päivämäärän määritteen alhainen tarkkuus on toinen syy siihen, miksi FAT32: ta ei pidetä täydellisenä tiedostojärjestelmänä turvallisuuden kannalta. Sen heikkouksia voidaan kuitenkin käyttää omiin tarkoituksiin. Jos esimerkiksi kopioit tiedostoja NTFS -osiosta FAT32 -taltioon, ne poistetaan kaikista metatiedoista sekä perinnöllisistä ja erityisesti asetetuista käyttöoikeuksista. FAT ei vain tue niitä.
Toisin kuin FAT12 / 16/32, exFAT on suunniteltu erityisesti USB -muistitikulle ja suurille muistikorteille (≥ 32 Gt). Laajennettu FAT eliminoi edellä mainitun FAT32: n haitan - korvata samat sektorit kaikissa muutoksissa. 64-bittisenä järjestelmänä sillä ei käytännössä ole merkityksellisiä rajoituksia yksittäisen tiedoston koolle. Teoriassa se voi olla 2 ^ 64 tavua (16 EB) pitkä, eikä tämän kokoisia kortteja näy pian.
Toinen merkittävä ero exFATissa on sen tuki pääsylistoille (ACL). Tämä ei ole sama yksinkertaisuus 1990 -luvulta, mutta suljettu muoto estää exFAT: n toteuttamisen. ExFAT -tuki on täysin ja laillisesti otettu käyttöön vain Windowsissa (alkaen XP SP2: sta) ja OS X: ssä (alkaen 10.6.5). Linuxissa ja * BSD: ssä sitä tuetaan joko rajoituksin tai ei täysin laillisesti. Microsoft vaatii lisenssin exFAT: n käyttämiseen, ja tällä alalla on monia oikeudellisia kiistoja.
Toinen merkittävä esimerkki B-puun tiedostojärjestelmistä on nimeltään Btrfs. Tämä FS ilmestyi vuonna 2007 ja se luotiin alun perin Oraclessa SSD: n ja RAID: n kanssa työskentelemiseksi. Sitä voidaan esimerkiksi skaalata dynaamisesti: luoda uusia inodeja live -järjestelmään tai jakaa äänenvoimakkuus osaosuuksiin jakamatta heille vapaata tilaa.
Btrfs: ssä toteutettu kopiointi-kirjoittamismekanismi ja täydellinen integrointi Device Mapper -ydinmoduuliin mahdollistavat lähes välittömän tilannekuvan ottamisen virtuaalisten lohkolaitteiden kautta. Tietojen esipakkaus (zlib tai lzo) ja kaksoiskappaleminen nopeuttavat perustoimintoja ja pidentävät samalla flash -muistin käyttöikää. Tämä on erityisen havaittavissa käsiteltäessä tietokantoja (pakkaus saavutetaan 2–4 kertaa) ja pieniä tiedostoja (ne on kirjoitettu järjestyksessä oleviin suuriin lohkoihin ja ne voidaan tallentaa suoraan "lehtiin").
Btrfs tukee myös täydellistä päiväkirjausta (dataa ja metatietoja), äänenvoimakkuuden tarkistusta ilman irrotusta ja monia muita nykyaikaisia ominaisuuksia. Btrfs -koodi julkaistaan GPL -lisenssillä. Tätä tiedostojärjestelmää on pidetty vakaana Linuxissa ytimen 4.3.1 jälkeen.
Lähes kaikki enemmän tai vähemmän nykyaikaiset tiedostojärjestelmät (ext3 / ext4, NTFS, HFSX, Btrfs ja muut) kuuluvat yleiseen päiväkirjaryhmään, koska ne pitävät kirjaa tehdyistä muutoksista erillisessä lokissa (päiväkirjassa) ja tarkistavat sen vika levyn käytön aikana ... Näiden tiedostojärjestelmien monisanaisuus ja vikasietoisuus ovat kuitenkin erilaisia.
Ext3 tukee kolmea kirjautumistilaa: loopback, sekvensoitu ja täysi loki. Ensimmäinen tila edellyttää vain yleisten muutosten (metatietojen) tallentamista, jotka suoritetaan asynkronisesti itse tietojen muutosten suhteen. Toisessa tilassa sama metatietojen tallennus suoritetaan, mutta ehdottomasti ennen muutoksia. Kolmas tila vastaa täydellistä kirjaamista (muutokset sekä metatietoihin että itse tiedostoihin).
Vain jälkimmäinen vaihtoehto varmistaa tietojen eheyden. Kaksi muuta nopeuttavat vain virheiden tunnistamista tarkistuksen aikana ja takaavat itse tiedostojärjestelmän eheyden palauttamisen, mutta eivät tiedostojen sisällön.
NTFS -kirjaus on samanlainen kuin ext3: n toinen lokitila. Vain muutokset metatietoihin tallennetaan lokiin, ja itse tiedot voivat kadota vian sattuessa. Tätä NTFS -päiväkirjausmenetelmää ei pidetty keinona saavuttaa suurin luotettavuus, vaan vain kompromissina suorituskyvyn ja vikasietoisuuden välillä. Siksi ihmiset, jotka ovat tottuneet työskentelemään täysin päiväkirjajärjestelmien kanssa, pitävät NTFS: ää pseudopäiväkirjana.
NTFS -lähestymistapa on jonkin verran parempi kuin ext3: n oletus. NTFS -järjestelmässä tarkistuspisteitä luodaan lisäksi säännöllisesti sen varmistamiseksi, että kaikki aiemmin odottavat levytoiminnot on suoritettu loppuun. Tarkistuspisteillä ei ole mitään tekemistä \ System Volume Infromation \ -järjestelmän palautuspisteiden kanssa. Nämä ovat vain ylimääräisiä merkintöjä lokissa.
Käytäntö osoittaa, että tällainen osittainen NTFS-päiväkirjaus useimmissa tapauksissa riittää ongelmattomaan toimintaan. Loppujen lopuksi, vaikka terävä sähkökatko, levylaitteet eivät katkaise virtaa välittömästi. Virtalähde ja lukuisat taajuusmuuttajien kondensaattorit tarjoavat juuri sen vähimmäisvarannon, joka riittää nykyisen kirjoitustoiminnon suorittamiseen. Nykyaikaisilla SSD -levyillä on nopeudellaan ja taloudellisuudellaan yleensä riittävästi energiaa vireillä olevien toimintojen suorittamiseen. Yritys siirtyä täydelliseen kirjaamiseen vähentäisi useimpien toimintojen nopeutta useita kertoja.
Tiedostojärjestelmien käyttöä rajoittaa niiden tuki käyttöjärjestelmä tasolla. Esimerkiksi Windows ei ymmärrä ext2 / 3/4 ja HFS +, mutta joskus sinun on käytettävä niitä. Tämä voidaan tehdä lisäämällä sopiva ohjain.
Avoin ajuri ext2 / 3 -osioiden lukemiseen ja kirjoittamiseen osittaisella ext4 -tuella. Uusin versio tukee laajennuksia ja osioita jopa 16 Tt asti. LVM-, ACL- ja laajennettuja määritteitä ei tueta.
Total Commanderille on ilmainen laajennus. Tukee ext2 / 3/4 -osioiden lukemista.
coLinux on avoimen lähdekoodin ja vapaa portti Linux -ytimestä. Yhdessä 32-bittisen ohjaimen kanssa voit käyttää Linuxia Windows 2000: ssa 7 ilman virtualisointitekniikoita. Tukee vain 32-bittisiä versioita. 64-bittisen muutoksen kehittäminen peruutettiin. coLinuxin avulla voit muun muassa järjestää pääsyn Windowsista ext2 / 3/4 -osioihin. Hankkeen tuki keskeytettiin vuonna 2014.
Windows 10: llä voi olla jo alkuperäinen tuki Linux-erityisille tiedostojärjestelmille, se on vain piilotettu. Näitä ajatuksia ehdottaa ytimetason ajuri Lxcore.sys ja LxssManager-palvelu, joka ladataan kirjastoksi Svchost.exe-prosessin avulla. Lisätietoja on Alex Ionescun puheessa "The Linux Kernel Hidden Inside Windows 10", jonka hän esitteli Black Hat 2016 -tapahtumassa.
ExtFS for Windows on Paragonin julkaisema maksettu ohjain. Se toimii Windows 7-10: ssä, tukee luku- / kirjoitusoikeutta ext2 / 3/4 -taltioille. Tarjoaa lähes täydellisen ext4 -tuen Windowsissa.
HFS + Windows 10 on toinen Paragon -ohjelmiston oma ajuri. Nimestä huolimatta se toimii kaikissa Windows -versioissa XP: stä alkaen. Tarjoaa täyden pääsyn HFS + / HFSX -tiedostojärjestelmiin levyillä, joissa on mikä tahansa osio (MBR / GPT).
WinBtrfs on Btrfs -ajurin varhainen kehitys Windowsille. Jo versiossa 0.6 se tukee sekä luku- että kirjoitusoikeutta Btrfs -taltioihin. Se pystyy käsittelemään kovia ja symbolisia linkkejä, tukee vaihtoehtoisia datavirtoja, ACL: ää, kahdenlaisia pakkauksia ja asynkronista luku- / kirjoitustilaa. Toistaiseksi WinBtrfs ei voi käyttää mkfs.btrfs, btrfs-balance ja muita apuohjelmia tämän tiedostojärjestelmän ylläpitämiseen.
| Tiedostojärjestelmä | Mac-si-mal-ny volyymikoko | Yhden tiedoston pre-del-koko | Pituus oman tiedostonimen mukaan | Koko tiedostonimen pituus (mukaan lukien polku juurista) | Tiedostojen ja / tai luetteloiden ennakkoluku | Tiedoston / luettelon päivämäärän määrittämisen tarkkuus | Oikeudet dos-tu-pa | Kovat linkit | Sim-free linkit | Pikakuvat | Tietojen pakkaaminen taustalla | Tietojen salaustekniikka taustalla | Isoisä-pli-ka-cio tietoja |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| FAT16 | 2 Gt 512 tavun sektorilla tai 4 Gt 64 kt: n klustereilla | 2 Gt | 255 tavua LFN: llä | - | - | - | - | - | - | - | - | - | - |
| FAT32 | 8 Tt 2 kt: n sektoreilla | 4 Gt (2 ^ 32 - 1 tavu) | 255 tavua LFN: llä | jopa 32 CD -alihakemistoa | 65460 | 10 ms (luo) / 2 s (muuta) | Ei | Ei | Ei | Ei | Ei | Ei | Ei |
| exFAT | PB 128 PB (2 ^ 32-1 klusteria 2 ^ 25-1 tavua) teoreettista / 512 Tt kolmannen osapuolen rajoitusten vuoksi | 16 EB (2 ^ 64-1 tavua) | 2796202 luettelossa | 10 ms | ACL | Ei | Ei | Ei | Ei | Ei | Ei | ||
| NTFS | 256 Tt 64 kt: n klustereissa tai 16 Tt 4K -klustereissa | 16 Tt (voitto 7) / 256 teratavua (voitto 8) | 255 Unicode-merkkiä (UTF-16) | 32 760 Unicode -merkkiä, mutta enintään 255 merkkiä per elementti | 2^32-1 | 100 ns | ACL | Joo | Joo | Joo | Joo | Joo | Joo |
| HFS + | 8 EB (2 ^ 63 tavua) | 8 EB | 255 Unicode-merkkiä (UTF-16) | ei ole rajoitettu erikseen | 2^32-1 | 1 sekunti | Unix, ACL | Joo | Joo | Ei | Joo | Joo | Ei |
| APFS | 8 EB (2 ^ 63 tavua) | 8 EB | 255 Unicode-merkkiä (UTF-16) | ei ole rajoitettu erikseen | 2^63 | 1 ns | Unix, ACL | Joo | Joo | Joo | Joo | Joo | Joo |
| Ext3 | 32 Tt (teoreettinen) / 16 Tt 4K -klustereissa (e2fs -ohjelmien rajoitusten vuoksi) | 2 Tt (teoreettinen) / 16 Gt vanhemmille ohjelmille | 255 Unicode-merkkiä (UTF-16) | ei ole rajoitettu erikseen | - | 1 sekunti | Unix, ACL | Joo | Joo | Ei | Ei | Ei | Ei |
| Ext4 | 1 EB (teoreettinen) / 16 Tt 4K -klustereissa (e2fs -ohjelmien rajoitusten vuoksi) | 16 TB | 255 Unicode-merkkiä (UTF-16) | ei ole rajoitettu erikseen | 4 miljardia | 1 ns | POSIX | Joo | Joo | Ei | Ei | Joo | Ei |
| F2FS | 16 TB | 3,94 teratavua | 255 tavua | ei ole rajoitettu erikseen | - | 1 ns | POSIX ACL | Joo | Joo | Ei | Ei | Joo | Ei |
| BTRFS | 16 EB (2 ^ 64-1 tavua) | 16 EB | 255 ASCII -merkkiä | 2 ^ 17 tavua | - | 1 ns | POSIX ACL | Joo | Joo | Joo | Joo | Joo | Joo |
Ilmoitin sen jo kerran blogissani, silloin siitä ei oikeastaan tiedetty mitään, ja nyt oli aika lyhyelle mutta johdonmukaisemmalle tutustumiselle hiljattain tehtyyn ReFS: ään.
Kaikella on kuitenkin rajansa, samoin myös tiedostojärjestelmien ominaisuuksilla. Nykyään NTFS: n ominaisuudet ovat saavuttaneet rajansa: suurten tallennusvälineiden tarkistaminen kestää liian kauan, "Lehti" hidastaa pääsyä ja tiedoston maksimikoko on melkein saavutettu. Tämän ymmärtäessään Microsoft otti käyttöön uuden tiedostojärjestelmän Windows 8: ssa - ReFS (Resilient File System). ReFS: n katsotaan tarjoavan parhaan tietosuojan suurille ja nopeille kiintolevyille. Varmasti sillä on myös haittoja, mutta ennen todella massiivisen käytön alkua Windows 8: ssa on vaikea puhua niistä.
Joten yritämme nyt ymmärtää ReFS: n sisäosat ja edut.
ReFS oli alun perin koodinimeltään "Protogon". Kerroin hänestä ensimmäistä kertaa suurelle yleisölle noin vuosi sitten Stephen Sinofsky- Microsoftin Windows -divisioonan johtaja, vastuussa Windowsin ja Internet Explorer.
Hän sanoi näillä sanoilla:
”NTFS on nykyään laajimmin käytetty, kehittynein ja monipuolisin tiedostojärjestelmä. Mutta ajattelemalla Windowsia uudelleen ja kehitämme parhaillaan Windows 8: ta, emme pysähdy tähän. Siksi esittelemme Windows 8: n ohella myös täysin uuden tiedostojärjestelmän. ReFS on rakennettu NTFS: n päälle, joten se säilyttää tärkeät yhteentoimivuusominaisuudet ja on samalla suunniteltu ja suunniteltu vastaamaan seuraavan sukupolven tallennustekniikoiden ja -skenaarioiden tarpeita.
Windows 8: ssa ReFS otetaan käyttöön vain osana Windows Server 8 -käyttöjärjestelmää. Tietenkin sovellustasolla asiakkaat saavat ReFS -datan käyttöoikeuden samalla tavalla kuin NTFS -tiedot. Muista, että NTFS on edelleen alan johtava PC -tiedostojärjestelmien tekniikka. ”
Itse asiassa näimme ensimmäisen kerran ReFS: n palvelimen käyttöjärjestelmässä Windows Server 8. Uutta tiedostojärjestelmää ei kehitetty tyhjästä. Esimerkiksi ReFS käyttää tiedostojen avaamiseen, sulkemiseen, lukemiseen ja kirjoittamiseen samoja sovellusliittymiä kuin NTFS. Lisäksi monet tutut ominaisuudet siirtyivät NTFS -palvelusta - esimerkiksi levyn salaus Bitlocker ja symbolisia linkkejä kirjastoja varten. Mutta se katosi mm. tietojen pakkaus ja useita muita toimintoja.
ReFS: n tärkeimmät innovaatiot keskittyvät tiedosto- ja kansiorakenteiden luomiseen ja hallintaan. Heidän tehtävänsä on tarjota automaattinen korjaus virheet, suurin skaalaus ja toiminta aina online -tilassa (Always Online).
ReFS -rakenteiden levytoteutus eroaa pohjimmiltaan muista Microsoftin tiedostojärjestelmistä. Microsoftin kehittäjät pystyivät toteuttamaan ideansa soveltamalla B-puu-konseptia, joka tunnetaan ReFS: n tietokannoista. Tiedostojärjestelmän kansiot on rakennettu taulukoiksi, joissa tiedostot ovat merkintöjä. Nämä puolestaan saavat tiettyjä määritteitä, jotka on lisätty alitaulukoiksi, mikä luo hierarkkisen puurakenteen. Jopa vapaa levytila on järjestetty taulukoiksi.
Yhdessä kaikkien järjestelmäelementtien todellisen 64-bittisen numeroinnin kanssa tämä eliminoi "pullonkaulojen" esiintymisen sen lisäskaalausvaiheessa
Tämän seurauksena ReFS -järjestelmän ydin on objektitaulukko - keskushakemisto, joka luettelee kaikki järjestelmän taulukot. Tällä lähestymistavalla on tärkeä etu: ReFS on luopunut monimutkaisesta lokinhallinnasta ja sitoo uusia tiedostoja vapaaseen tilaan - tämä estää sen korvaamisen.
« Lehtiluettelo"Onko kirjoitettuja merkintöjä. Kansion objektille on kolme perustietuetta: hakemistonkuvaaja, hakemistotietue ja sisäkkäisen objektin kuvaaja. Kaikki tällaiset tietueet on pakattu erilliseksi B ± puuksi, jossa on kansiotunniste; Tämän puun juuri on "Catalog" -puun lehti B ±, joka mahdollistaa lähes minkä tahansa määrän tietueiden pakkaamista kansioon. Alemmalla tasolla kansiopuun arkeilla B ± on ensisijaisesti hakemiston kuvaustietue, joka sisältää perustiedot kansiosta (nimi, "vakiotiedot", tiedostonimen määrite jne.).
Edelleen luettelossa on sijoitettu hakemistotietueet: lyhyet rakenteet, jotka sisältävät tietoja kansion sisältämistä kohteista. Nämä tietueet ovat huomattavasti lyhyempiä kuin NTFS, mikä tekee volyymistä vähemmän metatietoja ylikuormitetuksi.
Lopussa luettelomerkinnät. Kansioiden osalta nämä elementit sisältävät pakkauksen nimen, luettelon kansion tunnisteen ja "vakiotietojen" rakenteen. Tiedostoille ei ole tunnistetta - sen sijaan rakenne sisältää kaikki tiedoston perustiedot, mukaan lukien tiedoston paksuisen puun juuri B ±. Näin ollen tiedosto voi koostua lähes mistä tahansa määrästä fragmentteja.
Kuten NTFS, ReFS erottaa olennaisesti tiedostotiedot (metatiedot) ja tiedoston sisältö (käyttäjätiedot). Suojaustoiminnot tarjotaan kuitenkin molemmille samalla tavalla. Metatiedot on oletusarvoisesti suojattu tarkistussummilla - sama suojaus (haluttaessa) voidaan antaa myös käyttäjätiedoille. Nämä tarkistussummat sijaitsevat levyllä turvallisella etäisyydellä toisistaan - joten tietojen palauttaminen on helpompaa virheen sattuessa.
Tyhjän tiedostojärjestelmän metatietokoko on noin 0,1% itse tiedostojärjestelmän koosta (eli noin 2 Gt 2 Tt: n tilavuudelta). Jotkin ydinmetatiedot on kopioitu kaatumiskestävyyden parantamiseksi
ReFS -variantti, jonka näimme Windows Server 8 Beta, tukee vain 64 kt tietoklustereita ja 16 kt metatietoklustereita. Toistaiseksi "Klusterin koko" -parametri ohitetaan, kun luodaan ReFS -asemaa, ja sen oletetaan aina olevan oletusarvo. Kun tiedostojärjestelmää alustetaan, 64 kt on myös ainoa käytettävissä oleva klusterin koko.
Olkaamme rehellisiä, tämä klusterin koko on enemmän kuin tarpeeksi kaiken kokoisten tiedostojärjestelmien järjestämiseen. Sivuvaikutus on kuitenkin huomattava redundanssi tietojen tallennuksessa (1-tavuinen tiedosto levylle vie koko 64 kt: n lohkon).
Tiedostojärjestelmäarkkitehtuurin osalta ReFS: llä on kaikki työkalut, joita tarvitset tiedostojen turvalliseen palauttamiseen myös suuren laitevian jälkeen. NTFS -tiedostojärjestelmän ja vastaavien päiväkirjajärjestelmän suurin haittapuoli on, että levyn päivittäminen voi vahingoittaa aiemmin tallennettuja metatietoja sähkökatkon sattuessa tallennuksen aikana - tämä vaikutus on jo saanut vakaan nimen: ns. " roikkuva tallenne».
Estää roikkuvat ennätykset, Microsoft otti uuden lähestymistavan, jossa metatietorakenteiden osat sisältävät omia tunnisteitaan, minkä avulla voit vahvistaa rakenteiden omistajuuden; metatietolinkit sisältävät viitattujen lohkojen 64-bittiset tarkistussummat.
Kaikki muutokset metatietojen rakenteessa tapahtuvat kahdessa vaiheessa. Ensinnäkin metatiedoista luodaan uusi (muokattu) kopio vapaalle levytilalle, ja vasta sen jälkeen, jos se onnistuu, atomipäivitys siirtää linkin vanhasta (muuttumattomasta) uuteen (muutettuun) metatietoalueeseen. Täällä se poistaa lokin tarpeen säilyttämällä tietojen eheyden automaattisesti.
Kuvattu järjestelmä ei kuitenkaan koske käyttäjätietoja, joten kaikki tiedoston sisällön muutokset kirjoitetaan suoraan tiedostoon. Tiedosto poistetaan rakentamalla uudelleen metatietorakenne, joka tallentaa metatietolohkon edellisen version levylle. Tämän lähestymistavan avulla voit palauttaa poistetut tiedostot, kunnes ne korvataan uusilla käyttäjätiedoilla.
Erillinen aihe on ReFS -vikasietoisuus levyn vaurioitumisen yhteydessä. Järjestelmä pystyy tunnistamaan kaikenlaiset levyvauriot, mukaan lukien kadonneet tai väärään tallennuspaikkaan tallennetut, sekä ns. vähän rappeutumista(median tietojen heikkeneminen)
Kun "Integral Streams" -vaihtoehto on käytössä, ReFS tarkistaa myös tiedostojen sisällön tarkistussummien suhteen ja kirjoittaa aina muutokset tiedostoihin kolmannen osapuolen sijaintiin. Tämä antaa varmuuden siitä, että olemassa olevat tiedot eivät menetä, kun ne korvataan. Tarkistussummat päivitetään automaattisesti, kun tietoja kirjoitetaan, joten jos kirjoitus epäonnistuu, käyttäjä voi tarkistaa tiedoston version.
Toinen mielenkiintoinen aihe ReFS -turvallisuudesta on vuorovaikutus Säilytystilat... ReFS ja Säilytystilat on suunniteltu täydentämään toisiaan kahden tallennusjärjestelmän osana. Suorituskyvyn parantamisen lisäksi Säilytystilat suojata tietoja osittaiselta ja täydelliseltä levyvirheeltä tallentamalla kopioita useille levyille. Lukuvirheiden aikana Säilytystilat voi lukea kopioita, ja kirjoitusongelmien sattuessa (vaikka mediatiedot katoaisivat kokonaan lukemisen / kirjoittamisen aikana), on mahdollista jakaa tiedot "läpinäkyvästi". Kuten käytäntö osoittaa, useimmiten tällaisella vialla ei ole mitään tekemistä tietovälineen kanssa - se johtuu tietojen vioittumisesta tai tietojen menetyksestä tai väärästä paikasta.
Tällaisia vikoja ReFS voi havaita tarkistussummien avulla. Vian havaittuaan ReFS kommunikoi Säilytystilat kaikkien mahdollisten tietojen kopioiden lukemiseksi ja valitsee oikean kopion tarkistussummatarkistuksen perusteella. Järjestelmä sitten antaa Säilytystilat komento palauttaa vaurioituneet kopiot todellisten kopioiden perusteella. Kaikki tämä tapahtuu läpinäkyvästi sovelletusta näkökulmasta.
Kuten Microsoftin verkkosivustolla todetaan Windows Server 8, tarkistussummat ovat aina käytössä ReFS -metatiedoille ja olettaen, että äänenvoimakkuus on peilattu Säilytystilat, automaattinen korjaus on myös käytössä. Kaikki yhtenäiset virrat on suojattu samalla tavalla. Tämä luo käyttäjälle kokonaisratkaisun, jolla on korkea eheysaste, jonka avulla suhteellisen epäluotettavasta tallennuksesta voidaan tehdä erittäin luotettava.
Mainitut eheysvirrat suojaavat tiedoston sisältöä kaikenlaisilta tietojen vioilta. Tätä ominaisuutta ei kuitenkaan voida soveltaa joissakin tapauksissa.
Esimerkiksi jotkut sovellukset suosivat siistiä tiedostojen tallennuksen hallintaa ja jonkinlaista tiedostojen lajittelua levyllä. Koska yhtenäiset virrat jakavat lohkot uudelleen aina, kun tiedoston sisältö muuttuu, tiedostojen asettelu on liian arvaamaton näille sovelluksille. Tietokantajärjestelmät ovat tästä hyvä esimerkki. Tällaiset sovellukset seuraavat pääsääntöisesti itsenäisesti tiedostojen sisällön tarkistussummia ja voivat tarkistaa ja korjata tiedot suoraan vuorovaikutuksessa sovellusliittymien kanssa.
Mielestäni on selvää, kuinka ReFS toimii levyvirheiden tai tallennusvirheiden sattuessa. Tietojen menetyksen tunnistaminen ja voittaminen voi olla vaikeampaa " vähän rappeutumista"Kun levyn harvoin luettavien osien havaitsemat vauriot alkavat kasvaa nopeasti. Kun tällaiset vauriot luetaan ja havaitaan, ne voivat jo vaikuttaa kopioihin tai tiedot voivat kadota muiden vikojen vuoksi.
Voittaa prosessi vähän rappeutumista, Microsoft on lisännyt taustatehtävätehtävän, joka ajoittain huuhtelee metatiedot ja tiedot johdonmukaisista virroista ReFS -aseman peilivarastossa. Puhdistus suoritetaan lukemalla kaikki tarpeettomat kopiot ja tarkistamalla niiden oikeellisuus käyttämällä ReFS -tarkistussummia. Jos tarkistussummat eivät täsmää, virheelliset kopiot korjataan hyvillä kopioilla.
On edelleen uhka, jota voidaan perinteisesti kutsua "sysadminin painajaiseksi". On tapauksia, vaikkakin harvinaisia, kun jopa peilitilan tilavuus voi vahingoittua. Esimerkiksi epäonnistuneen järjestelmän muisti voi vioittaa tietoja, jotka voivat päätyä levylle ja vahingoittaa tarpeettomia kopioita. Lisäksi monet käyttäjät voivat päättää olla käyttämättä peilattua tallennustilaa ReFS: ään.
Tällaisissa tapauksissa, kun levy vaurioituu, ReFS suorittaa "korjauksen" - toiminnon, joka poistaa tiedot työlevyn nimitilasta. Sen tehtävänä on estää korjaamattomat vahingot, jotka voivat vaikuttaa oikeiden tietojen saatavuuteen. Jos esimerkiksi yksittäinen tiedosto hakemistossa on vaurioitunut eikä sitä voida korjata automaattisesti, ReFS poistaa kyseisen tiedoston tiedostojärjestelmän nimitilasta ja palauttaa loput taltiosta.
Olemme tottuneet siihen, että tiedostojärjestelmä ei voi avata tai poistaa vioittunutta tiedostoa, eikä järjestelmänvalvoja voi tehdä asialle mitään.
Mutta koska ReFS voi palauttaa vioittuneet tiedot, järjestelmänvalvoja voi palauttaa tämän tiedoston varmuuskopiosta tai käyttää sovellusta sen luomiseen välttäen järjestelmän sammuttamisen. Tämä tarkoittaa, että käyttäjän tai järjestelmänvalvojan ei enää tarvitse suorittaa vahvistus- ja korjaustoimenpiteitä offline -tilassa. Palvelimille tämä mahdollistaa suuren datamäärän käyttöönoton ilman vaaraa, että akku kestää pitkään.
Tietenkin ReFS: n käytännöllisyys ja mukavuus (tai päinvastaiset ominaisuudet) voidaan arvioida vasta sen jälkeen, kun Windows 8 -tietokoneet ovat yleistyneet ja vähintään kuusi kuukautta aktiivista työtä heidän kanssaan on kulunut. Sillä välin mahdollisilla G8 -käyttäjillä on enemmän kysymyksiä kuin vastauksia.
Esimerkiksi tämä: onko Windows 8: ssa mahdollista helposti ja yksinkertaisesti muuntaa tiedot NTFS: stä ReFS: ksi ja päinvastoin? Microsoft sanoo, että sisäänrakennettua muodonmuuntotoimintoa ei odoteta, mutta tiedot voidaan silti kopioida. ReFS: n laajuus on ilmeinen: aluksi sitä voidaan käyttää vain palvelimen suurena datanhallintana (itse asiassa se on jo käytössä). ReFS: llä ei vielä ole ulkoisia asemia - vain sisäisiä. On selvää, että ajan myötä ReFS varustetaan useilla ominaisuuksilla ja pystyy korvaamaan vanhan järjestelmän.
Microsoft sanoo, että todennäköisesti tämä tapahtuu, kun ensimmäinen Windows 8 -palvelupaketti julkaistaan.
Microsoft väittää myös testaneensa ReFS: n:
”Käyttämällä monimutkaista, laajaa kymmenien tuhansien testien sarjaa, jotka on kirjoitettu NTFS: lle yli kahden vuosikymmenen ajan. Nämä testit luovat uudelleen kehittyneet käyttöönotto -olosuhteet, joita uskomme järjestelmän kohtaavan esimerkiksi sähkökatkon aikana, ja ongelmat liittyvät usein skaalautuvuuteen ja suorituskykyyn. Siksi voimme sanoa, että ReFS -järjestelmä on valmis testisovellukseen kontrolloidussa ympäristössä. "
Samaan aikaan kehittäjät kuitenkin myöntävät, että koska ReFS on suuren tiedostojärjestelmän ensimmäinen versio, se vaatii todennäköisesti varovaisuutta käsittelyssä:
”Emme luonnehdi Windows 8: n ReFS: ää beetajulkaisuksi. Uusi tiedostojärjestelmä on valmis julkaistavaksi, kun Windows 8 poistuu betasta, koska mikään ei ole tärkeämpää kuin tietojen luotettavuus. Joten, toisin kuin mikään muu järjestelmän osa, tämä edellyttää varovaista lähestymistapaa ensimmäiseen käyttöön ja testaukseen. "
Lähinnä tästä syystä ReFS otetaan käyttöön vaiheittaisen suunnitelman mukaisesti. Ensin Windows Serverin tallennusjärjestelmäksi, sitten käyttäjien tallennustilaksi ja lopuksi käynnistyslevyksi. Kuitenkin samanlaista "varovaista lähestymistapaa" on käytetty aiemmin julkaistessaan uusia tiedostojärjestelmiä.
Tässä artikkelissa selvitämme sen mitä ominaisuuksia ReFS tarjoaa ja miten se on parempi kuin NTFS -tiedostojärjestelmä... Tietojen palauttaminen ReFS -levytilasta. Microsoftin uusi ReFS -tiedostojärjestelmä esiteltiin alun perin Windows Server 2012. Se sisältyy myös Windows 10: een osana Levytila -työkalua. ReFS: ää voidaan käyttää taajuusmuuttajien joukkoon. Windows Server 2016: n julkaisun myötä tiedostojärjestelmää on parannettu ja se on pian saatavana Windows 10: n uudessa versiossa.
Mitä ominaisuuksia ReFS tarjoaa ja miten se on parempi kuin nykyinen NTFS -järjestelmä?
Sisältö:Lyhenne sanalle Joustava tiedostojärjestelmä ReFS on uusi NTFS -pohjainen järjestelmä. Tässä vaiheessa ReFS ei tarjoa kattavaa korvausta NTFS: lle kotikäyttäjille. Tiedostojärjestelmässä on etunsa ja haittansa.
ReFS on suunniteltu ratkaisemaan NTFS -perusongelmat. Se kestää paremmin tietojen vioittumista, käsittelee lisääntyneen työmäärän paremmin ja skaalautuu helposti erittäin suuriin tiedostojärjestelmiin. Katsotaanpa mitä tämä tarkoittaa?
Tiedostojärjestelmä käyttää metatietojen tarkistussummia ja voi käyttää myös tiedostojen tietojen tarkistussummia. Kun luet tai kirjoitat tiedostoa, järjestelmä tarkistaa tarkistussumman varmistaakseen, että se on oikein. Siten vioittuneet tiedot havaitaan reaaliajassa.
ReFS on integroitu levytila -ominaisuuteen. Jos olet määrittänyt peilatun tietovaraston, Windows havaitsee ja korjaa automaattisesti tiedostojärjestelmän vioittumisen käyttämällä ReFS -tiedostoa kopioimalla tiedot toiselta asemalta. Tämä ominaisuus on käytettävissä sekä Windows 10: ssä että Windows 8.1: ssä.
Jos tiedostojärjestelmä havaitsee vahingoittuneet tiedot, joista ei ole vaihtoehtoista kopiota palautettavaksi, ReFS poistaa tällaiset tiedot välittömästi levyltä. Tämä ei vaadi järjestelmän uudelleenkäynnistystä tai tallennuslaitteen irrottamista, kuten NTFS: n tapauksessa.
Tarve käyttää chkdsk -apuohjelmaa katoaa kokonaan, koska tiedostojärjestelmä korjataan automaattisesti heti virheen aikaan. Uusi järjestelmä kestävät muun tyyppistä tietojen vioittumista. NTFS kirjoittaa tiedoston metatietoja suoraan kirjoittaessaan tiedoston metatietoja. Jos sähkökatkos tai tietokoneen kaatuminen tapahtuu tänä aikana, saat tiedon vioittumisen.
Kun metatiedot muuttuvat, ReFS luo datasta uuden kopion ja liittää tiedot tiedostoon vasta sen jälkeen, kun metatiedot on kirjoitettu levylle. Tämä poistaa mahdollisuuden tietojen vioittumiseen. Tätä ominaisuutta kutsutaan copy-to-write, ja se on läsnä muissa suosituissa Linux-käyttöjärjestelmissä: ZFS, BtrFS ja Applen APFS-tiedostojärjestelmä.
ReFS on nykyaikaisempi ja tukee paljon suurempia määriä ja pidempiä tiedostonimiä kuin NTFS. Pitkällä aikavälillä nämä ovat tärkeitä parannuksia. NTFS: ssä tiedostonimi voi olla enintään 255 merkkiä; ReFS: ssä tiedostonimi voi olla enintään 32 768 merkkiä. Windows 10: n avulla voit poistaa merkkirajoituksen käytöstä NTFS -tiedostojärjestelmissä, mutta se on aina poistettu käytöstä ReFS -taltioissa.
ReFS ei enää tue lyhyitä tiedostonimiä DOS 8.3 -muodossa. Voit käyttää NTFS -asemaa C: \ Ohjelmatiedostot \ v C: \ PROGRA ~ 1 \ varmistaa yhteensopivuus vanhojen ohjelmistojen kanssa.
NTFS: n teoreettinen enimmäiskoko on 16 eksatavua, kun taas ReFS: n teoreettinen enimmäiskoko on 262 144 eksatavua. Vaikka sillä ei ole nyt väliä, tietokoneet kehittyvät jatkuvasti.
ReFS: ää ei ole suunniteltu parantamaan tiedostojärjestelmän suorituskykyä NTFS: n yli. Microsoft on tehnyt ReFS: stä paljon tehokkaamman hyvin erityistapauksissa.
Esimerkiksi levytilan kanssa käytettäessä ReFS tukee "reaaliaikaista optimointia". Oletetaan, että sinulla on tallennustila, jossa on kaksi levyä, toinen parhaan suorituskyvyn ja toinen kapasiteetin saavuttamiseksi. ReFS kirjoittaa tiedot aina nopeammalle levylle parhaan suorituskyvyn saavuttamiseksi. Taustalla tiedostojärjestelmä siirtää automaattisesti suuria datapaloja hitaammille asemille pitkäaikaista tallennusta varten.
Windows Server 2016: ssa Microsoft on parantanut ReFS -palvelua parantaakseen virtuaalikoneen toimintojen suorituskykyä. Microsoft Hyper-V-virtuaalikone hyödyntää näitä etuja (teoriassa mikä tahansa virtuaalikone voi hyödyntää ReFS: ää).
Esimerkiksi ReFS tukee lohkokloonausta, mikä nopeuttaa virtuaalikoneen kloonausta ja tarkistuspisteiden yhdistämistä. Voidakseen luoda kopion virtuaalikoneesta ReFS tarvitsee vain kirjoittaa uudet metatiedot levylle ja antaa linkin olemassa oleviin tietoihin. Tämä johtuu siitä, että ReFS: ssä useat tiedostot voivat osoittaa samaan levyn taustalla olevaan tietoon.
Kun virtuaalikone kirjoittaa uusia tietoja levylle, se kirjoitetaan toiseen paikkaan ja alkuperäiset virtuaalikoneen tiedot jäävät levylle. Tämä nopeuttaa suuresti kloonausprosessia ja vaatii paljon vähemmän levyn kaistanleveyttä.
ReFS tarjoaa myös uuden ominaisuuden "Harvinainen VDL" jonka avulla ReFS voi nopeasti kirjoittaa nollia suurelle tiedostolle. Tämä nopeuttaa merkittävästi uuden tyhjän, kiinteän kokoisen virtuaalisen kiintolevytiedoston (VHD) luomista. NTFS: ssä tämä toiminto voi kestää 10 minuuttia, ReFS: ssä se voi kestää useita sekunteja.
Useista eduista huolimatta ReFS ei voi vielä korvata NTFS: ää. Windows ei voi käynnistyä ReFS -osiosta ja vaatii NTFS -protokollan. ReFS ei tue NTFS -ominaisuuksia, kuten tietojen pakkaamista, tiedostojärjestelmän salausta, kovia linkkejä, laajennettuja määritteitä, tietojen deduplikointia ja kiintiöitä. Mutta toisin kuin NTFS, ReFS sallii täyden aseman salauksen BitLockerilla, mukaan lukien järjestelmän asemarakenteet.
Windows 10 ei salli osion muotoilua ReFS -muotoon, tämä tiedostojärjestelmä on käytettävissä vain levytilassa. ReFS suojaa useiden kiintolevyjen altaissa käytettyjä tietoja vaurioilta. Windows Server 2016: ssa voit muotoilla taltioita käyttämällä ReFS: ää NTFS: n sijasta. Tällaista asemaa voidaan käyttää virtuaalikoneiden tallentamiseen, mutta käyttöjärjestelmä voi silti käynnistyä vain NTFS: stä.
Hetman Partition Recovery -ohjelman avulla voit analysoida ReFS -tiedostojärjestelmän hallinnoimaa levytilaa allekirjoitusanalyysialgoritmin avulla. Analysoimalla laitealoja sektoreittain ohjelma löytää tietyt tavusekvenssit ja näyttää ne käyttäjälle. Tietojen palauttaminen ReFS -levytilasta ei eroa NTFS -tiedostojärjestelmän kanssa toimimisesta:
Uuden tiedostojärjestelmän tulevaisuus on melko hämärä. Microsoft voi viimeistellä ReFS: n korvaamaan vanhentuneen NTFS: n kaikissa Windows -versioissa. Tällä hetkellä ReFS: ää ei voida käyttää yleisesti, ja se palvelee vain tiettyjä tehtäviä.
Jos olet jo asentanut ja käyttänyt Microsoftin uusia käyttöjärjestelmiä: Windows Server 2012 ja Windows 8, olet todennäköisesti jo huomannut, että uudet asemat voidaan nyt muotoilla ReFS -tiedostojärjestelmässä. Mikä on tiedostojärjestelmä ReFS? ReFS tarkoittaa Joustava tiedostojärjestelmä eli venäjäksi "Vikasietoinen tiedostojärjestelmä".
Microsoft näkee ReFS -tiedostojärjestelmän nykyisen suosituimman tiedostojärjestelmän NTFS: n seuraajana, jonka tekniset ominaisuudet ovat jo saavuttaneet rajansa. Erityisesti suurten tietovälineiden kanssa työskentelyssä ilmenee vaikeuksia heidän työssään: tämä on liian pitkä suoritettaessa virheentarkistustoimintoa ja päiväkirjan hidasta toimintaa ja saavuttaessa NTFS -tiedostojärjestelmän maksimikokorajoitukset.
Suurin osa ReFS: n innovaatioista liittyy tiedosto- ja kansiorakenteiden luomiseen ja hallintaan. Nämä ominaisuudet on toteutettu automaattista virheenkorjausta, suurta skaalautuvuutta ja aina online -käyttöä varten. ReFS-tiedostojärjestelmän kansiot on rakennettu taulukoiksi, joissa tiedostot ovat tietueita, ja niillä voi puolestaan olla omia määritteitään, jotka on järjestetty alitaulukoiksi ja jotka toteuttavat tietokannoista tutun hierarkkisen B + -puurakenteen. Vapaa levytila on myös järjestetty taulukoiksi.
ReFS: ää kehitettäessä pyrittiin seuraaviin tavoitteisiin:
ReFS: n tärkeimmät ominaisuudet
ReFS -tiedostojärjestelmän rajoitukset
ReFS perii monia edeltäjänsä NTFS: n ominaisuuksia ja semantiikkaa, mukaan lukien:
Kaikki ReFS -tiedostojärjestelmän tiedot ovat käytettävissä samojen sovellusliittymien kautta, joita käytetään tällä hetkellä NTFS -osioiden käyttämiseen.
ReFS poisti käytöstä seuraavat NTFS -ominaisuudet:
ReFS -tuki otettiin käyttöön Windows 8: ssa ja Windows Server 2012: ssa, ja vain tietomäärille. Toisin sanoen ReFS -osioita ei voida asentaa ja käynnistää käyttöjärjestelmästä. Ajan myötä ReFS varustetaan useilla ominaisuuksilla ja pystyy korvaamaan vanhentuneen NTFS -järjestelmän kokonaan. Kaikki uudet ominaisuudet näkyvät todennäköisesti ensimmäisessä Windows 8: n Service Pack -paketissa.
Lisäksi ReFS: ää ei voi vielä käyttää siirrettävissä ja kannettavissa tallennuslaitteissa (ReFS: ää käytetään tällä hetkellä vain sisäiseen tietovälineeseen).
Turhauttavaa on se, että olemassa olevia NTFS -levyjä ei voi muuttaa ReFS: ksi lennossa. Tiedot on siirrettävä tavallisella kopioinnilla.
Asema voidaan alustaa ReFS -tiedostojärjestelmään Levynhallintakonsolin kautta. Mutta Lisävaihtoehdot esimerkiksi johdonmukaisuuden tarkistamisen salliminen voidaan ottaa käyttöön vain komentoriviltä.
Voit esimerkiksi ottaa ReFS -johdonmukaisuuden tarkistuksen käyttöön komennolla:
Muoto / fs: refs / q / i: ota käyttöön
Poista johdonmukaisuuden tarkistus käytöstä.
