A Microsoft új ReFS fájlrendszere eredetileg Windows 2012 operációs rendszert futtató szervereken jelent meg, és csak később került bele a Windows 10-be, ahol csak a Storage Spaces (lemezterület virtualizációs technológia) lemeztár funkciójának részeként használható. V Windows Server 2016-ra a Microsoft azt ígéri, hogy jelentősen javítja a munkát a ReFS fájlrendszerrel, ráadásul a nyomtatásba kerülő pletykák szerint a ReFS leválthatja az elavult NTFS fájlrendszert a Windows 10 új verziójában, amelyet büszkén Windows 10 Pro-nak hívnak. (fejlett számítógépekhez).
De mi is pontosan a ReFs, miben különbözik a jelenleg használt NTFS fájlrendszertől, és milyen előnyökkel jár?
Röviden, hibatűrő fájlrendszernek tervezték. A ReFS egy kóddal létrehozott új fájlrendszer, és lényegében egy újratervezett és továbbfejlesztett NTFS fájlrendszer. Ide tartozik az információtárolás fokozott megbízhatósága, a stabil működés stressz módokban, a fájlok, kötetek, könyvtárak mérete, a kötetekben és könyvtárakban lévő fájlok számát csak egy 64 bites szám karaktereinek mérete korlátozza. Emlékezzünk rá, hogy ennél az értéknél a maximális fájlméret 16 exbibyte, a kötet mérete pedig 1 jobibyte.
A ReFS jelenleg nem helyettesíti az NTFS-t. Ennek megvannak a maga előnyei és hátrányai. De mondjuk nem lehet formázni egy meghajtót és telepíteni rá egy friss Windows-példányt, ahogy az NTFS-en tenné.
A ReFS ellenőrző összegeket használ a metaadatokhoz, és ellenőrző összegeket is használhat az adatfájlokhoz. Minden alkalommal, amikor fájlokat olvas vagy ír, a ReFS ellenőrzi az ellenőrző összeget, hogy megbizonyosodjon arról, hogy helyes-e. Ez azt jelenti, hogy maga a fájlrendszer rendelkezik egy olyan eszközzel, amely képes a sérült adatokat menet közben észlelni.
A ReFS integrálva van a Storage Spaces funkcióval. Ha ReFS-kompatibilis tükrözést állít be, a Windows könnyen észleli a fájlrendszer sérülését, és automatikusan kijavítja a tükrözött adatok sérült meghajtóra másolásával. Ez a funkció Windows 10 és Windows 8.1 rendszeren is elérhető.
Abban az esetben, ha a ReFS sérült adatokat észlel, és nincs szükség a visszaállításhoz szükséges másolatra, a fájlrendszer azonnal képes törölni a sérült adatokat a lemezről. Ehhez nem szükséges a rendszer újraindítása, ellentétben az NTFS-szel.
A ReFS nem csak a fájlok integritását ellenőrzi írás/olvasás közben. Automatikusan ellenőrzi az adatok integritását azáltal, hogy rendszeresen ellenőrzi a lemezen lévő összes fájlt, azonosítja és kijavítja a sérült adatokat. Ebben az esetben nincs szükség a chkdsk parancs rendszeres futtatására a lemez ellenőrzéséhez.
Az új fájlrendszer más módon is ellenáll az adatok sérülésének. Például egy fájl metaadatait frissíti (legyen ez a fájl neve). Az NTFS fájlrendszer közvetlenül módosítja a fájl metaadatait. Ha a rendszer ekkor összeomlik (kikapcsolás), nagy az esélye annak, hogy a fájl megsérül. Amikor módosítja a metaadatokat, a ReFS létrehozza a metaadatok új másolatát. A fájlrendszer nem írja felül a régi metaadatokat, hanem egy új blokkba írja. Ez megakadályozza, hogy a fájl megsérüljön. Ezt a stratégiát "írásra másolásnak" (copy-on-write, select-on-write) nevezik. Ez a stratégia elérhető más modern fájlrendszerekben, mint például a ZFS és a BtrFS Linuxon, valamint az új Apple APFS fájlrendszer.
A ReFS modernebb, mint az NTFS, és sokkal nagyobb adatmennyiséget és hosszabb fájlneveket támogat. Hosszú távon ez nagyon fontos.
Az NTFS fájlrendszerben a fájl elérési útja 255 karakterre korlátozódik. A ReFS-ben a maximális karakterszám már lenyűgöző 32768 karakter. A Windows 10 rendszerben jelenleg van lehetőség a karakterelem letiltására az NTFS-hez. ReFS lemezkötetek esetén ez a korlátozás alapértelmezés szerint le van tiltva.
A ReFS nem támogatja a DOS 8.3 fájlneveket. NTFS köteteken a „CPrgram Files”, „CProgra`1” mappák állnak az Ön rendelkezésére. A régivel való kompatibilitás miatt szükségesek szoftver. A ReFS-ben nem találja meg azokat a mappákat, amelyeket megszoktunk. El lettek távolítva.
Az NTFS által támogatott elméleti maximális adatmennyiség 16 exabájt, a ReFS legfeljebb 262144 exabájtot támogat. Most ez a szám hatalmasnak tűnik.
A fejlesztők nem tűzték ki célul egy produktívabb fájlrendszer létrehozását. Optimalizáltabb rendszert készítettek.
Például, ha tömbbel használjuk, a ReFS támogatja a valós idejű szintű optimalizálást. Van egy meghajtókészlete, amely két meghajtóból áll. Az első lemez kiválasztása nagy sebességű, gyors adathozzáférés elvárása mellett történik. A második lemezt a megbízhatóság kritériumával választják ki, hosszú távú adattárolásra. A háttérben a ReFS automatikusan áthelyezi a nagy adattömeget egy lassabb meghajtóra, így biztosítva az adattárolás megbízhatóságát.
A Windows Server 2016 rendszerben a fejlesztők egy olyan eszközt adtak hozzá, amely bizonyos funkciókon keresztül javítja a teljesítményt virtuális gépek. Például a ReFS támogatja a blokkmásolást, amely felgyorsítja a virtuális gépek másolását és az összevonási ellenőrzőpontokat. A virtuális gép másolatának létrehozásához a ReFS létrehozza a metaadatok új másolatát a lemezen, és a lemezen lévő másolt adatokra mutató hivatkozásra mutat. Ez azért van így, hogy a ReFS segítségével több fájl is hivatkozhasson ugyanarra a háttérben lévő adatra a lemezen. A virtuális géppel végzett munka és az adatok módosítása után az egy másik helyre kerül a lemezre, miközben a virtuális gép eredeti adatai a lemezen maradnak. Ez nagymértékben felgyorsítja a másolatok létrehozásának folyamatát és csökkenti a lemez terhelését.
A ReFS támogatja a "Sparse VDL"-t (ritka fájlok). A ritka fájl egy olyan fájl, amelyben egy null byte-os sorozatot lecseréltek az adott sorozatra vonatkozó információra (lyukak listája). A lyukak egy bizonyos nulla bájtok sorozata egy fájlban, amely nem íródik lemezre. Magát a lyukinformációt a fájlrendszer metaadatai tárolják.
A ritka fájltámogatási technológia lehetővé teszi, hogy gyorsan nullákat írjon egy nagy fájlba. Ez nagymértékben felgyorsítja egy új, üres virtuális fájl létrehozásának folyamatát. merevlemez fix méretű (VHD). Egy ilyen fájl létrehozása ReFS-ben néhány másodpercig tart, míg NTFS-ben egy ilyen művelet legfeljebb 10 percig tart.
Minden, amit fent leírtunk, jól hangzik, de nem fog tudni átváltani ReFS-re NTFS-ről. A Windows nem indul el ReFS fájlrendszerről, miközben NTFS-re van szüksége.
A ReFS-ből hiányzik az NTFS-ben elérhető számos technológia. Például a fájlrendszer tömörítése és titkosítása, merev hivatkozások, kiterjesztett attribútumok, adatduplikáció és lemezkvóták. Ugyanakkor az NTFS-től eltérően a ReFS támogatja a teljes adattitkosítási technológiát - a BitLockert.
Windows 10 rendszeren nem lehet meghajtópartíciót formázni ReFS segítségével. Az új fájlrendszer csak azokhoz a tárolórendszerekhez érhető el, ahol elsődleges feladata az adatok védelme a sérüléstől. A Windows Server 2016 rendszerben a lemezpartíciót ReFS-re formázhatja. Használhatja majd virtuális gépek futtatására. De nem fogja tudni kiválasztani rendszerindító meghajtóként. A Windows csak az NTFS fájlrendszerről indul el.
Nem világos, hogy a Microsoft milyen jövőt tartogat az új fájlrendszerrel kapcsolatban. Talán egy napon teljesen felváltja az NTFS-t a Windows összes verziójában. De egyelőre a ReFS csak bizonyos feladatokra használható.
Sok szó esett fent az új mellett operációs rendszer. Leírják az előnyöket és hátrányokat. Azt javaslom, álljunk meg és vegyünk számot. Milyen célokra lehet, és talán szükség van a ReFS használatára.
Windows 10 rendszeren a ReFS csak a Tárolóterületek összetevővel együtt használható. Ügyeljen arra, hogy az adattárolásra szánt lemezt ReFS-ben formázza, ne NTFS-ben. Ebben az esetben teljes mértékben értékelheti az adattárolás megbízhatóságát.
A Windows Server rendszerben a partíciót ReFS-re formázhatja a Lemezkezelő konzol szabványos Windows eszközével. Virtuális szerverek használata esetén ajánlatos ReFS alatt formázni. De ne feledje, hogy a rendszerindító meghajtót NTFS-re kell formázni. A ReFS fájlrendszerről történő indítást a Windows operációs rendszerek nem támogatják.
Az új ReFS fájlrendszer és a Windows 10| 2017-06-28 06:34:15 | Szuper felhasználó | Rendszerszoftver | https://site/media/system/images/new.png | A Microsoft ReFS új fájlrendszere váltotta fel az elavult NTFS-t. Mik a ReFS előnyei és miben különbözik az NTFS-től | refs, refs vagy ntfs, refs windows 10, refs fájlrendszer, új fájlrendszerek, ntfs rendszer, ntfs fájlrendszer
Miért nem tud egy okostelefon programokat futtatni memóriakártyáról? Miben különbözik alapvetően az ext4 az ext3-tól? Miért tart tovább egy flash meghajtó, ha NTFS-ben van formázva és nem FAT-ban? Mi a fő probléma az F2FS-sel? A válaszok a fájlrendszerek felépítésében rejlenek. Beszélni fogunk róluk.
A fájlrendszerek határozzák meg az adatok tárolásának módját. Meghatározzák, hogy a felhasználó milyen korlátokkal szembesül, milyen gyorsak lesznek az olvasási és írási műveletek, és mennyi ideig működik a meghajtó hiba nélkül. Ez különösen igaz a költségvetési SSD-kre és öccseikre - flash meghajtókra. Ezen funkciók ismeretében minden rendszerből a legtöbbet hozhatja ki, és optimalizálhatja annak használatát bizonyos feladatokhoz.
Ki kell választani a fájlrendszer típusát és paramétereit, amikor valami nem triviális dolgot kell tennie. Például fel akarja gyorsítani a leggyakoribb fájlműveleteket. Fájlrendszer szinten ezt többféleképpen lehet elérni: az indexelés gyors keresést tesz lehetővé, a szabad blokkok előzetes lefoglalása pedig megkönnyíti a gyakran változó fájlok felülírását. Az adatok előzetes optimalizálása véletlen hozzáférésű memória csökkenti a szükséges I/O mennyiséget.
A modern fájlrendszerek olyan tulajdonságai, mint a lusta írás, a deduplikáció és más fejlett algoritmusok, hozzájárulnak a működési idő növeléséhez. Különösen fontosak a TLC memóriachippel, flash meghajtókkal és memóriakártyákkal ellátott olcsó SSD-k esetében.
Külön optimalizálások léteznek a különböző szintű lemeztömbökhöz: például a fájlrendszer támogatja az egyszerűsített kötettükrözést, az azonnali pillanatfelvételeket vagy a dinamikus skálázást a kötet letiltása nélkül.
A felhasználók főként az operációs rendszer által alapértelmezés szerint kínált fájlrendszerrel dolgoznak. Ritkán hoznak létre új lemezpartíciókat, és még ritkábban gondolkodnak el a beállításaikról – csak használja az ajánlott beállításokat, vagy vásároljon előre formázott adathordozót.
A Windows rajongói számára minden egyszerű: NTFS az összes lemezpartíción és FAT32 (vagy ugyanaz az NTFS) a flash meghajtókon. Ha van NAS és valamilyen más fájlrendszert használnak benne, akkor ez a többség számára felfoghatatlan marad. Egyszerűen csatlakoznak hozzá a hálózaton keresztül, és letöltik a fájlokat, mintha egy fekete dobozból lennének.
Android rendszerű mobil kütyükön az ext4 leggyakrabban a belső memóriában, a FAT32 pedig a microSD-kártyákon található. A Yablokot egyáltalán nem érdekli, hogy milyen fájlrendszerük van: HFS +, HFSX, APFS, WTFS ... számukra csak a legjobb tervezők által készített gyönyörű mappa és fájl ikonok vannak. A Linux-felhasználóknak van a leggazdagabb választásuk, de a nem natív operációs rendszerű fájlrendszerek támogatását a Windows és a macOS rendszerben is összekapcsolhatja – erről később.
Több mint száz különböző fájlrendszert hoztak létre, de valamivel több mint egy tucat nevezhető relevánsnak. Bár mindegyiket a sajátos alkalmazásukra tervezték, sokan végül fogalmi szinten kapcsolódnak egymáshoz. Hasonlóak, mert azonos típusú (meta)adat-ábrázolási struktúrát használnak - B-fák ("b-fák").
Mint minden hierarchikus rendszer, a B-fa is egy gyökérbejegyzéssel kezdődik, majd leágazik a végső elemekig – a fájlokról és azok attribútumairól szóló egyedi bejegyzésekig vagy "levelekig". Az ilyen logikai struktúra létrehozásának fő oka a fájlrendszer-objektumok keresésének felgyorsítása volt nagy dinamikus tömbökön – például több terabájt kapacitású merevlemezeken vagy még lenyűgözőbb RAID-tömbökön.
A B-fák sokkal kevesebb lemezelérést igényelnek, mint más típusú kiegyensúlyozott fák ugyanazon műveletek végrehajtásához. Ez annak köszönhető, hogy a B-fák végső objektumai hierarchikusan azonos magasságban helyezkednek el, és az összes művelet sebessége éppen arányos a fa magasságával.
Más kiegyensúlyozott fákhoz hasonlóan a B-fák is azonos hosszúságú útvonalakkal rendelkeznek a gyökértől bármely levélig. Ahelyett, hogy felnőnének, inkább elágaznak és szélesednek: a B-fa minden elágazási pontja sok hivatkozást tárol gyermekobjektumaikra, így könnyen megtalálhatóak kevesebb találatnál. A nagyszámú mutató csökkenti a leghosszabb lemezműveletek számát – a fej pozicionálását tetszőleges blokkok olvasásakor.
A B-fák fogalmát még a hetvenes években fogalmazták meg, és azóta számos fejlesztésen ment keresztül. Ilyen vagy olyan formában, NTFS, BFS, XFS, JFS, ReiserFS és számos DBMS-ben valósul meg. Mindannyian rokonok az adatszervezés alapelveit tekintve. A különbségek a részletekre vonatkoznak, gyakran nagyon fontosakra. A kapcsolódó fájlrendszerek hátránya is gyakori: már az SSD-k megjelenése előtt mind lemezekkel való együttműködésre készültek.
A szilárdtestalapú meghajtók fokozatosan felváltják a lemezmeghajtókat, de egyelőre kénytelenek a tőlük idegen, örökölt fájlrendszereket használni. Flash memória tömbökre épülnek, amelyek elve eltér a lemezes eszközökétől. Különösen a flash memóriát kell törölni az írás előtt, és ez a művelet a NAND chipekben nem hajtható végre az egyes cellák szintjén. Csak nagy blokkok egészére lehetséges.
Ez a korlátozás annak a ténynek köszönhető, hogy a NAND memóriában minden cella blokkba van egyesítve, amelyek mindegyikének csak egy közös kapcsolata van a vezérlőbusszal. Nem megyünk bele az oldal felépítésének részleteibe, és nem festjük le a teljes hierarchiát. Ami fontos, az a cellákkal végzett csoportműveletek elve, és az a tény, hogy a flash memória blokkok mérete általában nagyobb, mint bármely fájlrendszerben megcímzett blokkok. Ezért a NAND flash meghajtókhoz tartozó összes címet és parancsot az FTL (Flash Translation Layer) absztrakciós rétegen keresztül kell lefordítani.
A flash memóriavezérlők kompatibilisek a lemezeszközök logikájával, és támogatják a natív interfész parancsait. Általában az FTL-t a firmware-ükben implementálják, de (részben) végrehajtható a gazdagépen – például a Plextor írási sebességet növelő illesztőprogramokat ír az SSD-ihez.
Egyáltalán nem nélkülözheti az FTL-t, hiszen már egy bitet is egy adott cellába írunk egy egész műveletsor elindításához: a vezérlő megkeresi a kívánt cellát tartalmazó blokkot; a blokkot teljes egészében beolvassa, a gyorsítótárba vagy a szabad területre írja, majd teljes egészében törli, majd a szükséges változtatásokkal visszaírja.
Ez a megközelítés a hadsereg mindennapi életére emlékeztet: az őrmester, hogy parancsot adjon egy katonának, tábornoki alakzatot állít fel, a szegényt leállítja, a többit pedig oszlani meg. A ma már ritka NOR-memóriában a szervezet specnaz volt: minden cellát egymástól függetlenül vezéreltek (minden tranzisztornak volt egyéni kontaktusa).
Egyre több feladat hárul a vezérlőkre, mert a flash memória minden egyes generációjával csökken annak gyártási folyamata az adattárolás sűrűségének növelése és költségcsökkentés érdekében. A technológiai szabványokkal együtt a chipek becsült élettartama is csökken.
Az egyszintű SLC cellákkal rendelkező modulok deklarált erőforrása 100 ezer újraírási ciklus volt és még több. Sokuk még mindig működik régi flash meghajtókban és CF-kártyákban. Egy vállalati szintű MLC (eMLC) 10-20 ezer közötti erőforrást igényelt, míg egy normál fogyasztói MLC esetében 3-5 ezerre becsülik. Ezt a típusú memóriát aktívan szorítja a még olcsóbb TLC, amelynek erőforrása alig éri el az ezer ciklust. A flash memória élettartamának elfogadható szinten tartása a szoftveres trükköknek köszönhető, és ezek közé az új fájlrendszerek válnak be.
Kezdetben a gyártók azt feltételezték, hogy a fájlrendszer nem fontos. Magának a vezérlőnek bármilyen típusú memóriacella rövid élettartamú tömbjét kell kiszolgálnia, optimális módon elosztva a terhelést közöttük. A fájlrendszer-illesztőprogram esetében egy normál lemezt utánoz, és maga is alacsony szintű optimalizálást végez bármilyen hozzáférésnél. A gyakorlatban azonban a különböző eszközökre történő optimalizálás mágikustól fiktívig változik.
A vállalati SSD-kben az integrált vezérlő egy kis számítógép. Hatalmas memóriapufferrel rendelkezik (fél giga vagy több), és számos módszert támogat az adatokkal való munka hatékonyságának javítására, ami lehetővé teszi a felesleges írási ciklusok elkerülését. A chip elrendezi az összes blokkot a gyorsítótárban, lusta írásokat hajt végre, menet közbeni deduplikációt hajt végre, egyes blokkokat lefoglal, másokat pedig töröl a háttérben. Mindez a varázslat teljesen észrevétlenül történik az operációs rendszer, a programok és a felhasználó számára. Egy ilyen SSD-nél nagyon nem mindegy, hogy melyik fájlrendszert használjuk. A belső optimalizálás sokkal nagyobb hatással van a teljesítményre és az erőforrásokra, mint a külső.
A költségvetési SSD-kbe (és még inkább a flash meghajtókba) sokkal kevesebb intelligens vezérlőt helyeznek el. A bennük lévő gyorsítótár csonka vagy hiányzik, és a fejlett szervertechnológiákat egyáltalán nem használják. A memóriakártyákban a vezérlők annyira primitívek, hogy gyakran azt állítják, hogy egyáltalán nem léteznek. Ezért a flash memóriával rendelkező olcsó eszközök esetében a külső terheléselosztási módszerek továbbra is relevánsak - elsősorban speciális fájlrendszerek segítségével.
Az egyik első kísérlet olyan fájlrendszer megírására, amely figyelembe veszi a flash memória rendszerezésének alapelveit, a JFFS – Journaling Flash File System volt. A svéd Axis Communications cég fejlesztése kezdetben az Axis által a kilencvenes években gyártott hálózati eszközök memóriahatékonyságának javítására irányult. A JFFS első verziója csak a NOR memóriát támogatta, de már a második verzióban megbarátkozott a NAND-dal.
A JFFS2 jelenleg korlátozottan használható. Még mindig leginkább a beágyazott rendszerek Linux disztribúcióiban használják. Megtalálható útválasztókban, IP-kamerákban, NAS-okban és a dolgok internetének egyéb szokásaiban. Általában mindenhol, ahol kis mennyiségű megbízható memóriára van szükség.
A JFFS2 továbbfejlesztése a LogFS volt, amely külön fájlban tárolta az inode-jait. Az ötlet szerzői az IBM Jörn Engel német részlegének munkatársa és az Osnabrücki Egyetem tanára, Robert Mertens. A LogFS forráskódja elérhető a GitHubon. Abból a tényből ítélve, hogy a legutóbbi változtatás négy éve történt, a LogFS nem tett szert népszerűségre.
De ezek a próbálkozások egy másik speciális fájlrendszer, az F2FS megjelenését is ösztönözték. A Samsung Corporation fejlesztette ki, amely a világ előállított flash memóriájának nagy részét adja. A Samsung saját készülékeihez és más cégek megrendelésére is gyárt NAND Flash chipeket, valamint fejleszti a régebbi lemezesek helyett alapvetően új interfészekkel ellátott SSD-ket. A Samsung szemszögéből régóta esedékes szükség volt egy speciális, flash memóriára optimalizált fájlrendszer létrehozására.
Négy éve, 2012-ben a Samsung létrehozta az F2FS-t (Flash Friendly File System). Az ötlete jó, de a megvalósítás kicsit durva volt. Az F2FS létrehozásakor a kulcsfeladat egyszerű volt: csökkenteni kell a cella-újraírási műveletek számát, és a lehető legegyenletesebben elosztani a rájuk nehezedő terhelést. Ehhez egy blokkon belül több cellán kell egyszerre műveleteket végrehajtani, ahelyett, hogy egyenként kényszerítené őket. Ez azt jelenti, hogy nem a meglévő blokkokat kell azonnal felülírnunk az operációs rendszer első kérésére, hanem a parancsok és adatok gyorsítótárazására, új blokkokkal való felszabadításra és a cellák halasztott törlésére.
Ma az F2FS támogatást már hivatalosan is implementálták a Linuxban (és így az Androidban is), de ez még mindig nem ad különösebb előnyt a gyakorlatban. Ennek a fájlrendszernek a fő jellemzője (késleltetett felülírás) korai következtetésekhez vezetett a hatékonyságával kapcsolatban. A régi gyorsítótárazási trükk még a benchmarkok korábbi verzióit is megbolondította, ahol az F2FS nem néhány százalékos (a várakozásoknak megfelelően) és nem is többszöröse képzeletbeli előnyt mutatott, hanem nagyságrendekkel. Csupán arról van szó, hogy az F2FS driver beszámolt arról a műveletről, amit a vezérlő éppen tervezett. Ha azonban az F2FS valódi teljesítménynövekedése kicsi, akkor a cellakopás határozottan kisebb lesz, mint ugyanazon ext4 használatakor. Azokat az optimalizálásokat, amelyeket egy olcsó vezérlő nem képes elvégezni, magának a fájlrendszernek a szintjén hajtják végre.
Míg az F2FS-t egzotikusnak tartják a stréberek számára. Még a sajátjukban is Samsung okostelefonok Az ext4 továbbra is érvényes. Sokan az ext3 továbbfejlesztésének tartják, de ez nem teljesen igaz. Sokkal inkább forradalomról van szó, mint a fájlonkénti 2 TB-os korlát áttöréséről és más mennyiségi mutatók egyszerű növeléséről.
Amikor a számítógépek nagyok és a fájlok kicsik, a címzés egyszerű volt. Minden fájlhoz bizonyos számú blokkot rendeltek, amelyek címét beírták a megfelelési táblázatba. Így működött az eddig szolgálatban lévő ext3 fájlrendszer. Az ext4 azonban egy alapvetően más megszólítási módot vezetett be – a kiterjedést.
A kiterjedések az inódok kiterjesztéseként is felfoghatók, mint különálló blokkok halmazai, amelyek egészében összefüggő sorozatokként vannak megcímezve. Egy terjedelem egy egész közepes méretű fájlt tartalmazhat, nagy fájlokhoz pedig elegendő egy tucat-két kiterjedést lefoglalni. Ez sokkal hatékonyabb, mint több százezer, négy kilobájtos kis blokk megcímzése.
Megváltozott az ext4 és maga a rögzítési mechanizmus. Most a blokkok elosztása azonnal megtörténik egy kérésben. És nem előre, hanem közvetlenül az adatok lemezre írása előtt. A halasztott többblokkos kiosztás lehetővé teszi, hogy megszabaduljon az ext3 által elkövetett szükségtelen műveletektől: ebben az új fájl blokkjait azonnal kiosztották, még akkor is, ha az teljesen belefért a gyorsítótárba, és ideiglenesen törölni tervezték.
A kiegyensúlyozott fák és azok módosításai mellett más népszerű logikai struktúrák is léteznek. Vannak alapvetően eltérő típusú fájlrendszerek - például lineáris. Valószínűleg gyakran használja legalább az egyiket.
Találd meg a rejtvényt: tizenkét évesen hízni kezdett, tizenhat évesen hülyén kövér volt, harminckettőre pedig kövér lett, és egyszerű maradt. Ki ő?
Ez igaz, ez a történet a FAT fájlrendszerről szól. A kompatibilitási követelmények rossz öröklődést biztosítottak számára. Hajlékonylemezeken 12 bites volt, merevlemezeken - eleinte 16 bites, és napjainkban 32 bitesként érte el. Minden további verzióban nőtt a címezhető blokkok száma, de lényegében semmi sem változott.
A továbbra is népszerű FAT32 fájlrendszer már húsz éve megjelent. Ma még primitív, és nem támogatja a hozzáférés-vezérlési listákat, a lemezkvótákat, a háttértömörítést vagy más modern adatoptimalizálási technológiákat.
Miért van szükség manapság a FAT32-re? Még mindig csak a kompatibilitás miatt. A gyártók joggal gondolják, hogy bármely operációs rendszer képes olvasni a FAT32 partíciót. Ezért külső merevlemezeken, USB Flash-eken és memóriakártyákon hozzák létre.
Az okostelefonokban használt microSD(HC) kártyák alapértelmezés szerint FAT32 formátumban vannak formázva. Ez a fő akadálya az alkalmazások telepítésének és a belső memóriából való adatátvitelnek. Ennek leküzdéséhez létre kell hoznia egy partíciót a kártyán ext3 vagy ext4 használatával. Az összes fájlattribútum (beleértve a tulajdonosi és hozzáférési jogokat is) átvihető rá, így bármely alkalmazás úgy működhet, mintha a belső memóriából indult volna el.
A Windows nem tudja, hogyan készítsen egynél több partíciót a flash meghajtókon, de ehhez futtathat Linuxot (legalábbis virtuális gépen) vagy egy fejlett segédprogramot a logikai particionáláshoz - például a MiniTool Partition Wizard Free-t. Miután talált egy további elsődleges partíciót ext3 / ext4-gyel a kártyán, a Link2SD alkalmazás és a hasonló alkalmazások sokkal több lehetőséget kínálnak, mint egyetlen FAT32 partíció esetében.
A FAT32 melletti másik érvként gyakran nevezik a bejelentkezés hiányát, ami gyorsabb írási műveleteket és a NAND Flash memóriacellák kisebb kopását jelenti. A gyakorlatban a FAT32 használata ennek ellenkezőjéhez vezet, és sok egyéb problémát is felvet.
A flash meghajtók és a memóriakártyák gyorsan elhalnak, mivel a FAT32 bármilyen változása ugyanazokat a szektorokat írja felül, ahol két fájltábla-lánc található. Az egész weboldalt elmentettem, és százszor felülírták – minden egyes újabb kis gif hozzáadásával a pendrive-hoz. Elindított hordozható szoftvert? Ideiglenes fájlokat hozott létre, és munka közben folyamatosan módosítja azokat. Ezért sokkal jobb az NTFS használata a flash meghajtókon a hibatűrő $MFT táblával. A kisméretű fájlok közvetlenül a fő fájltáblázatban tárolhatók, kiterjesztései és másolatai a flash memória különböző területeire íródnak. Ezenkívül az NTFS-en történő indexelésnek köszönhetően a keresés gyorsabb.
Egy másik probléma, amellyel a legtöbb felhasználó szembesül, az, hogy lehetetlen 4 GB-nál nagyobb fájlt FAT32-partícióra írni. Ennek az az oka, hogy a FAT32-ben a fájlméretet 32 bit írja le a fájlkiosztási táblázatban, a 2^32 (pontosabban mínusz egy) pedig pontosan négy gigabájt. Kiderült, hogy a frissen vásárolt pendrive-ra sem normál minőségben filmet, sem DVD-képet nem lehet írni.
A nagy fájlok másolása nem olyan rossz: amikor megpróbálja ezt megtenni, a hiba legalább azonnal látható. Más helyzetekben a FAT32 időzített bombaként működik. Például hordozható szoftvert másolt egy flash meghajtóra, és először probléma nélkül használja. Hosszú idő után az egyik programban (például a könyvelésben vagy a levelezésben) van egy adatbázis, amely felduzzad, és ... egyszerűen leállítja a frissítést. A fájl nem írható felül, mert elérte a 4 GB-os korlátot.
Kevésbé nyilvánvaló probléma, hogy a FAT32-ben egy fájl vagy könyvtár létrehozásának dátuma legfeljebb két másodpercre adható meg. Ez sok időbélyegeket használó kriptográfiai alkalmazás számára nem elegendő. A "date" attribútum alacsony pontossága egy másik oka annak, hogy a FAT32 biztonsági szempontból nem tekinthető teljes fájlrendszernek. Gyengeségeit azonban felhasználhatja saját céljaira. Például, ha fájlokat másol egy NTFS-partícióról egy FAT32-kötetre, a rendszer törli az összes metaadatot, valamint az örökölt és speciálisan beállított engedélyeket. A FAT egyszerűen nem támogatja őket.
A FAT12/16/32-vel ellentétben az exFAT-ot kifejezetten USB Flash és nagy (≥ 32 GB) memóriakártyákhoz tervezték. A kiterjesztett FAT kiküszöböli a FAT32 fent említett hátrányát - ugyanazokat a szektorokat felülírja bármilyen változtatással. 64 bites rendszerként nincs gyakorlati korlátja egyetlen fájl méretét illetően. Elméletileg 2 ^ 64 bájt (16 EB) hosszú lehet, és ekkora kártyák nem jelennek meg hamarosan.
Egy másik alapvető különbség az exFAT között a hozzáférés-vezérlési listák (ACL) támogatása. Ez már nem ugyanaz az egyszerű dolog a kilencvenes évekből, azonban a formátum közelsége megakadályozza az exFAT bevezetését. Az ExFAT-támogatás teljes mértékben és legálisan csak a Windows (az XP SP2-től kezdve) és az OS X (10.6.5-től kezdődően) alatt valósul meg. Linuxon és *BSD-n vagy korlátozottan vagy illegálisan támogatott. A Microsoftnak licencekre van szüksége az exFAT használatához, és ezen a területen sok a jogi vita.
Egy másik kiemelkedő B-tree fájlrendszer a Btrfs. Ez az FS 2007-ben jelent meg, és eredetileg az Oracle-ben készült, SSD-vel és RAID-del való együttműködés céljából. Például dinamikusan méretezhető: hozzon létre új inode-okat közvetlenül a futó rendszeren, vagy osztson fel egy kötetet alkötetekre anélkül, hogy szabad helyet foglalna nekik.
A Btrfs-ben megvalósított másolás írásra mechanizmus és a Device Mapper kernelmodullal való teljes integráció lehetővé teszi, hogy szinte azonnali pillanatképeket készítsen a virtuális blokkeszközökön keresztül. Az adatok előtömörítése (zlib vagy lzo) és deduplikáció felgyorsítja az alapvető műveleteket, miközben meghosszabbítja a flash memória élettartamát. Ez különösen észrevehető adatbázisokkal (2-4-szeres tömörítés érhető el) és kis fájlokkal (rendezett nagy blokkokban vannak írva, és közvetlenül a „levelekben” tárolhatók).
A Btrfs támogatja a teljes naplózást (adatok és metaadatok), a leválasztás nélküli kötetellenőrzést és sok más modern szolgáltatást. A Btrfs kódot a GPL licenc alatt teszik közzé. Ez a fájlrendszer stabilként támogatott Linuxon a kernel 4.3.1-es verziója óta.
Szinte az összes többé-kevésbé modern fájlrendszer (ext3 / ext4, NTFS, HFSX, Btrfs és mások) a naplózott fájlrendszerek általános csoportjába tartozik, mivel külön naplóban (naplóban) rögzítik a változtatásokat, és ellenőrzik vele, hogy nem. lemezműveletek során fellépő hiba. A naplózás részletessége és a hibatűrés azonban ezeknél a fájlrendszereknél eltérő.
Az ext3 három naplózási módot támogat: loopback, rendezett és teljes naplózás. Az első mód csak általános változtatásokat (metaadatokat) ír le, aszinkron módon az adatok változásaihoz képest. A második mód ugyanazt a metaadatírást végzi el, de szigorúan a változtatások végrehajtása előtt. A harmadik mód egyenértékű a teljes naplózással (módosítások mind a metaadatokban, mind magukban a fájlokban).
Csak az utolsó lehetőség biztosítja az adatok integritását. A másik kettő csak felgyorsítja a hibák felderítését az ellenőrzés során, és garantálja magának a fájlrendszernek a sértetlenségének helyreállítását, de a fájlok tartalmát nem.
A naplózás az NTFS-ben hasonló az ext3 második naplózási módjához. Csak a metaadatok változásai kerülnek naplózásra, és hiba esetén maguk az adatok elveszhetnek. Ez a naplózási módszer az NTFS-ben nem a maximális megbízhatóság elérését szolgálta, hanem csak a sebesség és a hibatűrés közötti kompromisszumot. Ez az oka annak, hogy azok, akik megszokták a teljesen naplózott rendszerekkel való munkát, az NTFS-t álnaplónak tekintik.
Az NTFS-ben megvalósított megközelítés bizonyos szempontból még jobb, mint az ext3 alapértelmezetté. Az NTFS emellett rendszeres időközönként ellenőrző pontokat hoz létre, hogy biztosítsa az összes korábban függőben lévő lemezművelet befejezését. Az ellenőrzőpontoknak semmi közük a \System Volume Information\ visszaállítási pontokhoz. Ezek csak szolgáltatás bejegyzések a naplóban.
A gyakorlat azt mutatja, hogy a legtöbb esetben az ilyen részleges NTFS naplózás elegendő a problémamentes működéshez. Végtére is, még éles áramszünet esetén sem kapcsolnak le azonnal a lemezeszközök. A tápegység és a meghajtókban található számos kondenzátor éppen azt a minimális energiát biztosítja, amely elegendő az aktuális írási művelet befejezéséhez. A modern SSD-kkel gyorsaságukkal és hatékonyságukkal általában ugyanannyi energia elegendő a függőben lévő műveletek elvégzéséhez. A teljes naplózásra való váltás kísérlete időnként csökkentené a legtöbb művelet sebességét.
A fájlrendszerek használatát az operációs rendszer szintű támogatásuk korlátozza. Például a Windows nem érti az ext2/3/4-et és a HFS+-t, de néha szükség van rájuk. Ezt a megfelelő illesztőprogram hozzáadásával teheti meg.
Nyílt forráskódú illesztőprogram ext2/3 partíciók olvasásához és írásához, az ext4 részleges támogatásával. A legújabb verzió 16 TB-ig támogatja a kiterjedéseket és a partíciókat. Az LVM, a hozzáférés-vezérlési listák és a kiterjesztett attribútumok nem támogatottak.
Van egy ingyenes bővítmény a Total Commanderhez. Támogatja az ext2/3/4 partíciók olvasását.
A coLinux a Linux kernel nyitott és szabad portja. A 32 bites meghajtóval együtt lehetővé teszi a Linux futtatását Windows környezet 2000-től 7-ig virtualizációs technológiák alkalmazása nélkül. Csak a 32 bites verziókat támogatja. A 64 bites módosítás fejlesztését törölték. A coLinux többek között lehetővé teszi a rendszerezést Windows hozzáférés ext2/3/4 partíciókra. A projekt támogatását 2014-ben felfüggesztették.
Lehet, hogy a Windows 10 már rendelkezik beépített támogatással a Linux-specifikus fájlrendszerekhez, csak rejtve van. Ezeket a gondolatokat sugallja az Lxcore.sys kernelszintű illesztőprogram és az LxssManager szolgáltatás, amelyet az Svchost.exe folyamat könyvtárként tölt be. További információért lásd Alex Ionescu „The Linux Kernel Hidden Inside Windows 10” című előadását a Black Hat 2016-on.
Az ExtFS for Windows a Paragon által kiadott fizetős illesztőprogram. Windows 7 és 10 között működik, támogatja az olvasási/írási hozzáférést az ext2/3/4 kötetekhez. Szinte teljes mértékben támogatja az ext4-et Windows rendszeren.
A HFS+ for Windows 10 egy másik szabadalmaztatott illesztőprogram a Paragon Software-től. A név ellenére a Windows minden verziójában működik XP-től kezdve. Teljes hozzáférést biztosít a HFS+/HFSX fájlrendszerekhez bármilyen elrendezésű lemezeken (MBR/GPT).
A WinBtrfs a Windows Btrfs illesztőprogramjának korai fejlesztése. Már a 0.6-os verzióban is támogatja az olvasási és írási hozzáférést a Btrfs kötetekhez. Kezeli a kemény és szimbolikus hivatkozásokat, támogatja az alternatív adatfolyamokat, ACL-eket, kétféle tömörítést és az aszinkron olvasási/írási módot. Míg a WinBtrfs nem tudja, hogyan kell az mkfs.btrfs-t, a btrfs-balance-t és más segédprogramokat használni a fájlrendszer karbantartására.
| Fájlrendszer | Maximális kis térfogatú | Egy fájl méretének korlátozása | Saját fájlnév hossza | A fájlnév félhossza (beleértve a gyökér elérési útját) | Korlátozza a fájlok és/vagy könyvtárak számát | A fájl / katalógus dátumának feltüntetésének pontossága | Dos-tu-pa jogok | Kemény linkek | Szimbolikus linkek | Azonnali vénás felvételek (pillanatfelvételek) | Adattömörítés a háttérben | Cipher-ro-va-nie adatok a háttérben | Dedu-pli-ka-tion adatok |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| FAT16 | 2 GB az 512 bájtos szektorokban vagy 4 GB a 64 KB-os fürtökben | 2 GB | 255 bájt LFN-nel | - | - | - | - | - | - | - | - | - | - |
| FAT32 | 8 TB 2 KB-os szektorokban | 4 GB (2^32 - 1 bájt) | 255 bájt LFN-nel | akár 32 alkönyvtár CDS-szel | 65460 | 10 ms (létrehozás) / 2 s (módosítás) | Nem | Nem | Nem | Nem | Nem | Nem | Nem |
| exFAT | ≈ 128 PB (2^32-1 klaszter 2^25-1 bájtból) elméleti / 512 TB a harmadik fél általi korlátok miatt | 16 EB (2^64 - 1 bájt) | 2796202 a katalógusban | 10 ms | ACL | Nem | Nem | Nem | Nem | Nem | Nem | ||
| NTFS | 256 TB 64 KB-os fürtökben vagy 16 TB 4 KB-os fürtökben | 16 TB (Win 7) / 256 TB (Win 8) | 255 Unicode karakter (UTF-16) | 32760 Unicode karakter, de legfeljebb 255 karakter minden elemben | 2^32-1 | 100 ns | ACL | Igen | Igen | Igen | Igen | Igen | Igen |
| HFS+ | 8 EB (2^63 bájt) | 8 EB | 255 Unicode karakter (UTF-16) | nincs külön korlátozva | 2^32-1 | 1 s | Unix ACL | Igen | Igen | Nem | Igen | Igen | Nem |
| APFS | 8 EB (2^63 bájt) | 8 EB | 255 Unicode karakter (UTF-16) | nincs külön korlátozva | 2^63 | 1 ns | Unix ACL | Igen | Igen | Igen | Igen | Igen | Igen |
| Ext3 | 32 TB (elméletileg) / 16 TB 4 KB-os fürtökben (az e2fs program segédprogramjainak korlátai miatt) | 2 TB (elméletileg) / 16 GB régebbi programok számára | 255 Unicode karakter (UTF-16) | nincs külön korlátozva | - | 1 s | Unix ACL | Igen | Igen | Nem | Nem | Nem | Nem |
| Ext4 | 1 EB (elméletileg) / 16 TB 4 KB-os fürtökben (az e2fs program segédprogramjainak korlátai miatt) | 16 TB | 255 Unicode karakter (UTF-16) | nincs külön korlátozva | 4 milliárd | 1 ns | POSIX | Igen | Igen | Nem | Nem | Igen | Nem |
| F2FS | 16 TB | 3,94 TB | 255 bájt | nincs külön korlátozva | - | 1 ns | POSIX, ACL | Igen | Igen | Nem | Nem | Igen | Nem |
| BTRFS | 16 EB (2^64 - 1 bájt) | 16 EB | 255 ASCII karakter | 2^17 bájt | - | 1 ns | POSIX, ACL | Igen | Igen | Igen | Igen | Igen | Igen |
Egyszer már bejelentettem a blogomon, akkor még nem igazán lehetett róla tudni semmit, most pedig itt az ideje egy rövid, de következetesebb ismerkedésnek az újonnan vert ReFS-sel.
Azonban mindennek van határa, és a fájlrendszerek képességeinek is. Mára az NTFS képességei a korlátokhoz érkeztek: a nagy kapacitású adathordozók ellenőrzése túl sok időt vesz igénybe, a „Journal” lelassítja a hozzáférést, és majdnem elérte a maximális fájlméretet. Ezt felismerve a Microsoft új fájlrendszert vezetett be a Windows 8-ban - ReFS (Resilient File System - hibatűrő fájlrendszer). Úgy gondolják, hogy a ReFS biztosítja a legjobb adatvédelmet a nagy kapacitású és gyors merevlemezeken. Bizonyára vannak hátrányai, de a Windows 8 valóban masszív használatának kezdete előtt nehéz beszélni róluk.
Tehát most próbáljuk megérteni a ReFS belső felépítését és előnyeit.
A ReFS eredetileg "Protogon" kódnéven volt ismert. Körülbelül egy éve nyilatkozott először a nagyközönségnek Stephen Sinofsky- A Microsoft Windows részlegének elnöke, a Windows fejlesztéséért és marketingjéért felelős és internet böngésző.
Ezekkel a szavakkal mondták el:
„Ma az NTFS a legszélesebb körben használt, legfejlettebb és funkciókban gazdag fájlrendszer. De ha újragondoljuk a Windowst, és jelenleg a Windows 8-at fejlesztjük, nem állunk meg itt. Ezért a Windows 8 mellett egy teljesen új fájlrendszert is bemutatunk. A ReFS az NTFS-re épül, így megtartja a kritikus kompatibilitási jellemzőket, miközben úgy tervezték és tervezték, hogy megfeleljen a tárolási technológiák és forgatókönyvek új generációjának igényeinek.
A Windows 8 rendszerben a ReFS csak a Windows Server 8 részeként kerül bevezetésre, ugyanaz a megközelítés, mint az összes korábbi fájlrendszer bevezetésekor. Természetesen alkalmazás szinten a kliensek ugyanúgy hozzáférést kapnak a ReFS adatokhoz, mint az NTFS adatokhoz. Ne felejtsük el, hogy az NTFS továbbra is az iparág vezető fájlrendszer-technológiája a PC-k számára."
Valóban, először láttuk a ReFS-t a Windows Server 8 szerver operációs rendszerben.Az új fájlrendszert nem a semmiből fejlesztették ki. Például a ReFS ugyanazokat az API-kat használja, mint az NTFS a fájlok megnyitásához, bezárásához, olvasásához és írásához. Ezenkívül számos jól ismert szolgáltatás költözött az NTFS-ről – például a lemeztitkosítás bitlockerés szimbolikus linkek könyvtárak számára. De eltűnt pl. adattömörítésés számos egyéb funkció.
A ReFS fő újításai a fájl- és mappastruktúrák létrehozására és kezelésére koncentrálódnak. Feladatuk az ellátás automatikus javítás hibák, maximális méretezés és az Always Online módban való működés.
A ReFS struktúrák lemezes megvalósítása alapvetően különbözik a Microsoft többi fájlrendszerétől. A Microsoft fejlesztői úgy tudták megvalósítani elképzeléseiket, hogy a ReFS-ben alkalmazták az adatbázisokból jól ismert B±trees koncepciót. A fájlrendszerben lévő mappák táblázatokként vannak felszerelve, a fájlok bejegyzésként. Ezek viszont bizonyos attribútumokat kapnak altáblázatként hozzáadva egy hierarchikus fastruktúrát létrehozva. Még a szabad lemezterület is táblázatokba rendeződik.
A rendszer összes elemének valódi 64 bites számozása mellett ez kiküszöböli a "szűk keresztmetszetek" megjelenését a további skálázás során
Ennek eredményeként a rendszer magja a ReFS-ben az objektumtábla, egy központi katalógus, amely felsorolja a rendszer összes tábláját. Ennek a megközelítésnek van egy fontos előnye: a ReFS felhagyott a bonyolult naplókezeléssel, és a fájllal kapcsolatos új információkat rögzít a szabad helyen – így elkerülhető a felülírás.
« Katalógus levelek' gépelt rekordok. A mappaobjektumokhoz három alapvető bejegyzéstípus létezik: egy könyvtárleíró, egy indexbejegyzés és egy beágyazott objektumleíró. Minden ilyen rekord különálló B±faként van csomagolva, amely mappaazonosítóval rendelkezik; ennek a fának a gyökere a "Directory" fa B ± levele, amely lehetővé teszi, hogy szinte tetszőleges számú rekordot csomagoljon egy mappába. A mappafa B± lapjainak alsó szintjén elsősorban egy könyvtárleíró bejegyzés található, amely a mappára vonatkozó alapvető adatokat (név, "standard információ", fájlnév attribútum stb.) tartalmazza.
A katalógus további részei index rekordok: rövid szerkezetek, amelyek adatokat tartalmaznak a mappában található elemekről. Ezek a rekordok sokkal rövidebbek, mint az NTFS-ben – ez kevésbé zsúfolja össze a kötetet metaadatokkal.
A végén találhatók a címtárbejegyzések. A mappák esetében ezek az elemek tartalmazzák a csomag nevét, a mappa azonosítóját a „Könyvtárban”, valamint a „standard információk” szerkezetét. A fájlokhoz nincs azonosító – ehelyett a struktúra tartalmazza a fájl összes alapadatát, beleértve a fájltöredékfa B gyökerét is. Ennek megfelelően egy fájl szinte tetszőleges számú töredékből állhat.
Az NTFS-hez hasonlóan a ReFS is alapvetően megkülönbözteti a fájlinformációkat (metaadatokat) és a fájltartalmat (felhasználói adatok). de védő funkciókat mindkettőnek egyformán adják. A metaadatok alapértelmezés szerint ellenőrző összegekkel védettek – ugyanez a védelem (opcionálisan) adható a felhasználói adatoknak is. Ezek az ellenőrző összegek a lemezen biztonságos távolságban helyezkednek el egymástól – így hiba esetén könnyebb lesz az adatok helyreállítása.
Egy üres fájlrendszer metaadat mérete körülbelül 0,1%-a magának a fájlrendszernek (azaz körülbelül 2 GB egy 2 TB-os kötetnél). Egyes alapvető metaadatok a nagyobb rugalmasság érdekében duplikálva vannak
A ReFS változat, amit láttunk Windows Server 8 béta, csak 64 KB-os adatfürtöket és 16 KB-os metaadat-fürtöket támogat. Egyelőre a Cluster Size paramétert figyelmen kívül hagyja a ReFS-kötet létrehozásakor, és mindig az alapértelmezett. Fájlrendszer formázásakor a fürtméret kiválasztásának egyetlen lehetősége szintén 64 KB.
Elismerjük: ez a fürtméret több mint elegendő bármilyen méretű fájlrendszer rendezéséhez. Mellékhatás azonban az adattárolás észrevehető redundanciája (egy 1 bájtos fájl a lemezen egy teljes 64 KB-os blokkot foglal el).
Ami a fájlrendszer architektúráját illeti, a ReFS rendelkezik minden szükséges eszközzel a fájlok biztonságos visszaállításához még komoly hardverhiba után is. A naplózó rendszer fő hátránya az NTFS fájlrendszerben és hasonlókban, hogy a lemez frissítése a korábban rögzített metaadatokat károsíthatja a rögzítés közbeni áramszünet esetén - ez a hatás már stabil nevet kapott: az ún. " megdöntött rekord».
Megelőzni megdöntött rekordok, a Microsoft fejlesztői egy új megközelítést választottak, amelyben a metaadat-struktúrák egyes részei saját azonosítókat tartalmaznak, ami lehetővé teszi a struktúrák tulajdonjogának ellenőrzését; A metaadat hivatkozások 64 bites ellenőrző összegeket tartalmaznak a hivatkozott blokkokról.
A metaadatok szerkezetének bármilyen változása két szakaszban történik. Először a szabad lemezterületen létrejön a metaadatok új (módosított) másolata, majd csak ezt követően, ha sikeres, egy atomi frissítési művelettel átkerül a hivatkozás a régi (változatlan) metaadatterületről az új (módosított) metaadat területre. Itt elkerüli a naplózást, mivel automatikusan megőrzi az adatok integritását.
A leírt séma azonban nem vonatkozik a felhasználói adatokra, így a fájl tartalmának bármilyen változása közvetlenül a fájlba íródik. A fájl törlése a metaadat-struktúra újraépítésével történik, amely a metaadatblokk korábbi verzióját tartja a lemezen. Ez a megközelítés lehetővé teszi a törölt fájlok visszaállítását mindaddig, amíg azokat új felhasználói adatokkal felül nem írják.
Külön téma a ReFS hibatűrés lemezkárosodás esetén. A rendszer képes észlelni a lemezkárosodás minden formáját, így az elveszett vagy rossz helyen tárolt rekordokat, valamint az ún. kicsit bomlás(az adathordozón lévő adatok állapotának romlása)
Ha az "integrált adatfolyamok" opció engedélyezve van, a ReFS a fájlok tartalmát is ellenőrzi, és mindig harmadik féltől származó helyre írja a fájlmódosításokat. Ez biztosítja, hogy a már meglévő adatok ne vesszenek el felülíráskor. Az ellenőrző összegek automatikusan frissülnek az adatok írásakor, így ha az írás sikertelen, a felhasználónak továbbra is elérhető lesz a fájl verziója ellenőrzésre.
Egy másik érdekes téma a ReFS biztonsági kérdésben az interakció Tárolóhelyek. ReFS és Tárolóhelyekúgy tervezték, hogy két komponensként kiegészítsék egymást egységes rendszer adattárolás. A teljesítmény javítása mellett Tárolóhelyek megvédi az adatokat a részleges és teljes lemezhibáktól a másolatok több lemezen való tárolásával. Olvasási hibák során Tárolóhelyek tud másolatokat olvasni, és írási hibák esetén (akár a médiaadatok teljes elvesztése esetén is olvasás/írás közben) lehetőség van az adatok „átlátható” újraelosztására. Amint azt a gyakorlat mutatja, az ilyen meghibásodás leggyakrabban nem a médiához kapcsolódik - adatsérülés, adatvesztés vagy rossz helyre való mentés miatt következik be.
Ezeket a hibákat a ReFS ellenőrző összegek segítségével képes észlelni. Hiba észlelésekor a ReFS kapcsolatba lép Tárolóhelyek az adatok összes lehetséges másolatának beolvasása érdekében, és az ellenőrző összeg ellenőrzése alapján kiválasztja a megfelelő példányt. Utána a rendszer ad Tárolóhelyek parancs a sérült másolatok helyreállítására a helyes másolatok alapján. Mindez az alkalmazott szempontból átláthatóan történik.
Ahogy a Microsoft honlapján is olvasható Windows Server 8, az ellenőrző összegek mindig engedélyezve vannak a ReFS metaadatokhoz, és feltételezve, hogy a kötetet tükrözötten tárolják Tárolóhelyek, az automatikus korrekció is engedélyezve van. Minden integrált adatfolyam azonos módon védett. Ezzel egy végponttól végpontig magas fokú integritású megoldás jön létre a felhasználó számára, aminek köszönhetően a viszonylag megbízhatatlan tárhely nagyon megbízhatóvá tehető.
Az említett integritásfolyamok megvédik a fájl tartalmát mindenféle adatsérüléstől. Ez a jellemző azonban bizonyos esetekben nem alkalmazható.
Például egyes alkalmazások esetében célszerű gondosan kezelni a fájltárolást a lemezen lévő fájlok bizonyos rendezése mellett. Mivel a konzisztens adatfolyamok minden alkalommal újraosztják a blokkokat, amikor egy fájl tartalma megváltozik, a fájlok elrendezése ezeknél az alkalmazásoknál túlságosan kiszámíthatatlan. Az adatbázis-rendszerek kiváló példái ennek. Az ilyen alkalmazások általában önállóan követik nyomon a fájlok tartalmának ellenőrző összegeit, és képesek az adatok ellenőrzésére és javítására az API-kkal való közvetlen interakció révén.
Azt hiszem, világos, hogy a ReFS hogyan működik lemezsérülés vagy tárolási hiba esetén. Nehezebb lehet azonosítani és leküzdeni a következőhöz kapcsolódó adatvesztést kicsit bomlás”, amikor a lemez ritkán olvasható részein a károsodások, amelyeket nem észleltek időben, gyorsan növekedni kezdenek. Mire ezeket a hibákat kiolvassák és észlelik, a másolatok már érintettek lehetnek, vagy más hibák miatt elveszhetnek az adatok.
A folyamat leküzdésére kicsit bomlás, a Microsoft hozzáadott egy háttérrendszerfeladatot, amely időszakonként megtisztítja a metaadatokat és adatfolyam integritási adatait egy tükrözött tárhelyen lévő ReFS-köteten. A tisztítás az összes redundáns másolat beolvasásával és a ReFS ellenőrzőösszegekkel történő ellenőrzésével történik. Ha az ellenőrző összegek nem egyeznek, a hibás példányokat jó másolatokkal javítjuk.
Továbbra is fennáll egy fenyegetés, amelyet feltételesen a "rendszergazda rémálmának" nevezhetünk. Vannak esetek, bár ritkák, amikor még a tükrözött térben lévő kötet is megsérülhet. Például egy meghibásodott rendszer memóriája megsértheti az adatokat, amelyek aztán a lemezre kerülhetnek, és megrongálhatják a redundáns másolatokat. Ezenkívül sok felhasználó dönthet úgy, hogy nem használja a tükrözött tárterületeket ReFS alatt.
Ilyen esetekben, amikor a kötet megsérül, a ReFS "javítást" hajt végre – egy olyan funkciót, amely eltávolítja az adatokat a munkakötet névteréből. Célja, hogy megakadályozza a helyrehozhatatlan károkat, amelyek befolyásolhatják az érvényes adatok elérhetőségét. Például, ha egy könyvtár egyetlen fájlja megsérül, és nem javítható automatikusan, a ReFS eltávolítja azt a fájlt a fájlrendszer névteréből, visszaállítva a kötet többi részét.
Megszoktuk, hogy a fájlrendszer nem tudja megnyitni vagy törölni a sérült fájlt, és a rendszergazda sem tehet ellene.
De mivel a ReFS képes helyreállítani a sérült adatokat, a rendszergazda visszaállíthatja ezt a fájlt egy biztonsági másolatból, vagy az alkalmazás segítségével újra létrehozhatja a rendszer leállítása nélkül. Ez azt jelenti, hogy a felhasználónak vagy a rendszergazdának többé nem kell offline állapotban ellenőriznie és javítania a meghajtót. A szerverek számára ez lehetővé teszi nagy mennyiségű adat telepítését a hosszú időszakok kockázata nélkül. elem élettartam sérülés miatt.
Természetesen a ReFS praktikusságát és kényelmét (vagy fordított tulajdonságait) csak a Windows 8-as számítógépek elterjedése és legalább hat hónapos aktív munka után lehet megítélni. A potenciális G8-felhasználóknak eddig több kérdése van, mint válasz.
Például ez: lehetséges lesz-e a Windows 8-ban könnyen és egyszerűen konvertálni az adatokat NTFS-ről ReFS-re és fordítva? A Microsoft képviselői azt mondják, hogy nincs beépített funkció a formátumok konvertálására, de az információk másolhatók. A ReFS hatóköre nyilvánvaló: eleinte csak a szerver nagy adatkezelőjeként használható (sőt, már használatban van). ReFS-sel még nem lesznek külső meghajtók – csak belsőek. Nyilvánvaló, hogy idővel a ReFS több funkcióval lesz felszerelve, és képes lesz helyettesíteni a régi rendszert.
A Microsoft szerint ez valószínűleg a Windows 8 első szervizcsomagjának kiadásával fog megtörténni
A Microsoft azt is állítja, hogy tesztelte a ReFS-t:
„Egy több tízezer tesztből álló kifinomult, kiterjedt csomagot használunk, amelyeket több mint két évtizede építettek NTFS-re. Ezek a tesztek újrateremtik azokat az összetett üzembe helyezési feltételeket, amelyekről úgy gondoljuk, hogy a rendszer tapasztalható, például áramkimaradásokat, gyakran a méretezhetőséghez és a teljesítményhez kapcsolódó problémákat. Ezért azt mondhatjuk, hogy a ReFS rendszer készen áll a teszttelepítésre egy felügyelt környezetben.”
A fejlesztők ugyanakkor elismerik, hogy egy nagy fájlrendszer első verziójaként a ReFS valószínűleg gondos kezelést igényel:
„A ReFS for Windows 8 rendszert nem minősítjük béta verziónak. Az új fájlrendszer akkor lesz készen a kiadásra, amikor a Windows 8 kilép a bétaverzióból, mert semmi sem fontosabb az adatmegbízhatóságnál. Tehát a rendszer bármely más aspektusától eltérően itt a kezdeti használat és tesztelés konzervatív megközelítésére van szükség.”
Nagyrészt ezért kerül bevezetésre a ReFS szakaszos terv szerint. Először - a Windows Server tárolórendszereként, majd - a felhasználók tárolójaként, és már a végén - rendszerindító kötetként. Az új fájlrendszerek kiadására azonban már korábban is alkalmaztak hasonló "óvatos megközelítést".
Ebben a cikkben meg fogjuk érteni milyen funkciókat biztosít a ReFS, és miért jobb, mint az NTFS fájlrendszer. Hogyan lehet visszaállítani az adatokat a ReFS lemezterületről. A Microsoft új ReFS fájlrendszerét eredetileg a Windows Server 2012 rendszerben vezették be. A Windows 10 rendszerben is megtalálható a Lemezterület eszköz részeként. A ReFS használható lemeztárhoz. A Windows Server 2016 megjelenésével javult a fájlrendszer, hamarosan elérhető lesz a Windows 10 új verziójában.
Milyen funkciókat kínál a ReFS, és miben jobb, mint a jelenlegi NTFS?
Tartalom:Röviden Rugalmas fájlrendszer, A ReFS egy új, NTFS-en alapuló rendszer. Jelenleg a ReFS nem kínál átfogó helyettesítést az NTFS-hez az otthoni felhasználók meghajtói számára. A fájlrendszernek megvannak a maga előnyei és hátrányai.
A ReFS célja az NTFS alapvető problémáinak megoldása. Ellenáll az adatsérülésnek, jobban bírja a nagy munkaterhelést, és könnyen méretezhető nagyon nagy fájlrendszerekre. Nézzük meg, mit jelent ez?
A fájlrendszer ellenőrző összegeket használ a metaadatokhoz, és ellenőrző összegeket is használhat a fájladatokhoz. Fájl olvasása vagy írása közben a rendszer ellenőrzi az ellenőrzőösszeg helyességét. Így a sérült adatok valós idejű észlelése történik.
A ReFS integrálva van a Lemezterület funkcióval. Ha tükrözött adattárolót állít be, akkor a Windows a ReFS segítségével felismeri és automatikusan kijavítja a fájlrendszer sérülését az adatok másik lemezről történő másolásával. Ez a funkció Windows 10 és Windows 8.1 rendszerben is elérhető.
Ha a fájlrendszer olyan sérült adatokat észlel, amelyeknek nincs alternatív másolata a helyreállításhoz, akkor a ReFS azonnal törli ezeket az adatokat a lemezről. Ehhez nincs szükség a rendszer újraindítására vagy a tárolóeszköz letiltására, mint az NTFS esetében.
A chkdsk segédprogram használatának szükségessége teljesen eltűnik, mivel a fájlrendszert a hiba pillanatában azonnal kijavítják. Új rendszer ellenáll az egyéb típusú adatsérüléseknek. Az NTFS közvetlenül írja a fájl metaadatait, amikor azt írja. Ha ez idő alatt áramkimaradás vagy számítógép-összeomlás következik be, adatsérülést szenvedhet.
A metaadat-módosítás során a ReFS új másolatot hoz létre az adatokról, és csak a metaadatok lemezre írása után társítja az adatokat a fájlhoz. Ez kiküszöböli az adatok sérülésének lehetőségét. Ezt a funkciót másolás-írásra hívják, és más népszerű Linux operációs rendszerekben is megtalálható: ZFS, BtrFS és Apple APFS fájlrendszer.
A ReFS modernebb, és sokkal nagyobb köteteket és hosszabb fájlneveket támogat, mint az NTFS. Hosszú távon ezek fontos fejlesztések. Az NTFS fájlrendszerben a fájlnév 255 karakterre van korlátozva, a ReFS-ben a fájlnév legfeljebb 32768 karakterből állhat. A Windows 10 lehetővé teszi az NTFS fájlrendszerek karakterkorlátjának letiltását, de ez mindig le van tiltva a ReFS köteteken.
A ReFS már nem támogatja a DOS 8.3 rövid fájlneveket. NTFS-köteten hozzáférhet C:\Program Files\ v C:\PROGRA~1\ a régebbi szoftverekkel való kompatibilitás biztosítása érdekében.
Az NTFS elméleti maximuma 16 exabájt, míg a ReFS elméleti maximuma 262144 exabájt. Bár most már nem sokat számít, de a számítógép folyamatosan fejlődik.
A ReFS-t nem arra tervezték, hogy javítsa a fájlrendszer teljesítményét az NTFS-hez képest. A Microsoft nagyon konkrét esetekben sokkal hatékonyabbá tette a ReFS rendszert.
Például a Tárolóterülettel együtt használva a ReFS támogatja a „valós idejű optimalizálást”. Tegyük fel, hogy van egy meghajtókészlete két meghajtóval, az egyik a maximális teljesítmény, a másik a hangerő érdekében. A ReFS mindig gyorsabb meghajtóra írja az adatokat, így biztosítva a maximális teljesítményt. A háttérben a fájlrendszer automatikusan áthelyezi a nagy adatdarabokat lassabb meghajtókra a hosszú távú tárolás érdekében.
A Windows Server 2016 rendszerben a Microsoft továbbfejlesztette a ReFS-t, hogy jobb teljesítményt nyújtson a virtuális gép funkcióihoz. A Microsoft Hyper-V virtuális gép kihasználja ezeket az előnyöket (elméletileg bármely virtuális gép kihasználhatja a ReFS előnyeit).
Például a ReFS támogatja a blokkklónozást, amely felgyorsítja a virtuális gépek klónozásának és az ellenőrzőpont-egyesítési műveleteknek a folyamatát. Egy virtuális gép másolatának létrehozásához a ReFS-nek csak az új metaadatokat kell lemezre írnia, és hivatkozást kell biztosítania a meglévő adatokra. Ennek az az oka, hogy a ReFS-ben több fájl is mutathat ugyanarra a lemezen lévő mögöttes adatra.
Amikor a virtuális gép új adatokat ír a lemezre, azok egy másik helyre kerülnek, miközben az eredeti virtuális gép adatok a lemezen maradnak. Ez nagymértékben felgyorsítja a klónozási folyamatot, és sokkal kisebb sávszélességet igényel.
A ReFS egy új funkciót is kínál "ritka VDL", amely lehetővé teszi a ReFS számára, hogy gyorsan nullákat írjon egy nagy fájlba. Ez nagymértékben felgyorsítja egy új, üres, rögzített méretű virtuális merevlemez (VHD) fájl létrehozását. NTFS-en ez a művelet 10 percig, ReFS-en néhány másodpercig tarthat.
Számos előnye ellenére a ReFS még nem helyettesítheti az NTFS-t. A Windows nem indul el ReFS-partícióról, és NTFS-t igényel. A ReFS nem támogatja az NTFS-szolgáltatásokat, például az adattömörítést, a fájlrendszer-titkosítást, a merev hivatkozásokat, a kiterjesztett attribútumokat, az adatduplikációt és a lemezkvótákat. Az NTFS-től eltérően azonban a ReFS lehetővé teszi a teljes lemeztitkosítás végrehajtását a BitLocker használatával, beleértve a rendszerlemez-struktúrákat is.
A Windows 10 nem teszi lehetővé a partíciók ReFS-ben történő formázását, ez a fájlrendszer csak a Lemezterületen érhető el. A ReFS megvédi a több merevlemezből álló készleteken használt adatokat a sérüléstől. A Windows Server 2016 rendszerben NTFS helyett ReFS-sel formázhatja a köteteket. Egy ilyen kötet virtuális gépek tárolására használható, de az operációs rendszer továbbra is csak NTFS-ről tud indítani.
A Hetman Partition Recovery lehetővé teszi a ReFS fájlrendszer által kezelt lemezterület elemzését aláírás-elemző algoritmus segítségével. Az eszközszektort szektoronként elemezve a program megkeres bizonyos bájtsorozatokat és megjeleníti azokat a felhasználónak. Az adatok visszaállítása a ReFS lemezterületről nem különbözik az NTFS fájlrendszerrel való munkavégzéstől:
Az új fájlrendszer jövője meglehetősen homályos. A Microsoft véglegesítheti a ReFS-t, hogy lecserélje a korábbi NTFS-t a Windows összes verziójában. A ReFS jelenleg nem használható univerzálisan, és csak bizonyos feladatokra szolgál.
Ha már telepítette és dolgozott a Microsoft új operációs rendszereivel: Windows Server 2012 és Windows 8, akkor valószínűleg már észrevette, hogy most új kötetek formázhatók a ReFS fájlrendszerben. Mi az a fájlrendszer ReFS? A ReFS rövidítés jelentése Rugalmas fájlrendszer, azaz oroszul "Hibatűrő fájlrendszer".
A Microsoft a ReFS fájlrendszert a pillanatnyilag legnépszerűbb NTFS fájlrendszer utódjaként olvassa be, amelynek technológiai lehetőségei már a korlátok közé kerültek. Különösen a nagy adathordozókkal való munkavégzés során adódnak nehézségek: túl hosszú a hibaellenőrzési művelet, a napló lassú, és eléri a maximális fájlméret korlátait az NTFS fájlrendszerben.
A ReFS legtöbb újítása a fájl- és mappastruktúrák létrehozásában és kezelésében rejlik. Ezeket a funkciókat az automatikus hibajavítás, a magas skálázhatóság és az Always Online működés érdekében valósították meg. A ReFS fájlrendszerben a mappák táblákként vannak felépítve, bejegyzésként fájlokkal, amelyeknek viszont saját attribútumai lehetnek altáblázatokba szervezve, megvalósítva a számunkra adatbázisokból ismert B+ fák hierarchikus fastruktúráját. A szabad lemezterület szintén táblázatokba rendeződik.
A ReFS fejlesztése során a következő célokat követtük:
A ReFS főbb jellemzői
A ReFS fájlrendszer korlátai
A ReFS örökölte elődje, az NTFS számos funkcióját és szemantikáját, többek között:
A ReFS fájlrendszeren lévő összes adat ugyanazokon az API-kon keresztül lesz elérhető, amelyeket jelenleg az NTFS-partíciók eléréséhez használnak.
A ReFS eltávolította a következő NTFS-szolgáltatásokat:
A ReFS támogatást a Windows 8 és a Windows Server 2012 rendszerben vezették be, és csak az adatmennyiségekre. Vagyis a ReFS-szel rendelkező partíciók nem használhatók az operációs rendszer telepítésére és onnan történő indítására. Idővel a ReFS több funkcióval lesz felszerelve, és képes lesz teljesen leváltani a régi NTFS rendszert. Valószínűleg minden új funkció megjelenik a Windows 8 első szervizcsomagjában.
Ezenkívül a ReFS még nem alkalmazható cserélhető és hordozható tárolóeszközökre (a ReFS jelenleg csak a belső adathordozókra vonatkozik).
Kellemetlen pillanat az a tény, hogy a meglévő NTFS-kötetek nem konvertálhatók menet közben ReFS-re. Az adatokat rendszeres másolással kell továbbítani.
A kötet a Lemezkezelő konzolon keresztül formázható ReFS fájlrendszerre. De Extra lehetőségek, például az integritás-ellenőrzés engedélyezése, csak a parancssorból engedélyezhető.
Például a ReFS integritásellenőrzést a következő paranccsal engedélyezheti:
Formázza /fs:refs /q /i:enable
Az integritás-ellenőrzés letiltása.
