souborový systém refs pro Windows 10. Souborový systém ReFS zevnitř

Nový souborový systém ReFS společnosti Microsoft se původně objevil na běžících serverech Ovládání Windows 2012. A až později byla zahrnuta do Windows 10, kde ji lze používat pouze jako součást funkce Storage Spaces (technologie virtualizace diskového prostoru) diskového fondu. V Windows Server 2016 Microsoft slibuje výrazné zlepšení práce se souborovým systémem ReFS a podle zvěstí v tisku může ReFS nahradit zastaralý souborový systém NTFS v nová verze Windows 10, který hrdě nese název Windows 10 Pro (pro pokročilé PC).

Co to ale ReFs vlastně je, jak se liší od aktuálně používaného souborového systému NTFS a jaké má výhody?

Co je ReFS

Stručně řečeno, byl navržen jako souborový systém odolný proti chybám. ReFS je nový souborový systém založený na kódu, který je v podstatě přepracováním a vylepšením systému souborů NTFS. Patří mezi ně zlepšená spolehlivost ukládání informací, stabilní provoz v zátěžových režimech, velikosti souborů, svazků, adresářů, počet souborů ve svazcích a adresářích je omezen pouze velikostí 64bitového čísla. Připomeňme, že s touto hodnotou bude maximální velikost souboru 16 exbibajtů a velikost svazku bude 1 yobibajt.

V současné době není ReFS náhradou za NTFS. Má to své výhody i nevýhody. Nebudete ale moci řekněme zformátovat disk a nainstalovat na něj nový. kopii Windows tak jak byste to udělali na NTFS.

ReFS chrání vaše data

ReFS používá kontrolní součty pro metadata a může také používat kontrolní součty pro datové soubory. Pokaždé, když čtete nebo zapisujete soubory, ReFS kontroluje kontrolní součet, aby se ujistil, že je správný. To znamená, že samotný souborový systém má nástroj schopný detekovat poškozená data za běhu.

ReFS je integrován s funkcí Storage Spaces. Pokud jste nakonfigurovali zrcadlení s podporou ReFS, systém Windows snadno zjistí poškození systému souborů a automaticky jej opraví zkopírováním zrcadlených dat na poškozený disk. Tato funkce K dispozici pro Windows 10 a Windows 8.1.

Pokud ReFS detekuje poškozená data a neexistuje žádná požadovaná kopie dat k obnovení, systém souborů je schopen okamžitě odstranit poškozená data z disku. Na rozdíl od NTFS to nevyžaduje restart systému.

ReFS nekontroluje pouze integritu souborů během zápisu a čtení. Automaticky kontroluje integritu dat pravidelnou kontrolou všech souborů na disku, identifikací a opravou poškozených dat. V tomto případě není nutné pravidelně spouštět příkaz chkdsk pro kontrolu disku.

Nový souborový systém je odolný vůči poškození dat i jinými způsoby. Například aktualizujete metadata souboru (řekněme název souboru). Systém souborů NTFS přímo mění metadata souboru. Pokud v tuto chvíli dojde k pádu systému (výpadek proudu), je velká pravděpodobnost poškození souboru. Když změníte metadata, systém souborů ReFS vytvoří novou kopii metadat. Souborový systém nepřepisuje stará metadata, ale zapisuje je nový blok. Tím se eliminuje možnost poškození souboru. Tato strategie se nazývá „copy-on-write“ (copy-on-write, highlight-on-write). Tato strategie je dostupná v jiných moderních souborových systémech, jako jsou ZFS a BtrFS na Linuxu, stejně jako v novém souborovém systému APFS společnosti Apple.

Omezení souborového systému NTFS

ReFS je modernější než NTFS a podporuje mnohem větší objemy dat a delší názvy souborů. Z dlouhodobého hlediska je to velmi důležité.

V systému souborů NTFS je cesta k souboru omezena na 255 znaků. V ReFS maximální částka znaků je již působivých 32 768 znaků. V současné době existuje ve Windows 10 možnost zakázat znakový prvek pro NTFS. U diskových svazků ReFS je tento limit ve výchozím nastavení zakázán.

ReFS nepodporuje názvy souborů DOS 8.3. Na svazcích NTFS máte přístup ke složkám „CProgram Files“, „CProgra`1“. Jsou potřeba pro kompatibilitu se starým software. V ReFS nenajdete složky, na které jsme zvyklí. Byly smazány.

Teoretický maximální objem dat podporovaný NTFS je 16 exabajtů, ReFS podporuje až 262 144 exabajtů. Nyní se toto číslo zdá prostě obrovské.

Výkon ReFS

Vývojáři si nestanovili cíl vytvořit produktivnější souborový systém. Vytvořili více optimalizovaný systém.

Například při použití s ​​polem ReFS podporuje optimalizaci úrovně v reálném čase. Máte úložný fond sestávající ze dvou disků. První disk byl vybrán pro vysokou rychlost a rychlý přístup k datům. Druhý disk je vybrán podle kritérií spolehlivosti, pod dlouhodobé skladování data. V Pozadí ReFS automaticky přesune velké kusy dat na pomalejší disk, čímž zajistí bezpečné uložení dat.

V systému Windows Server 2016 vývojáři přidali nástroj, který poskytuje zvýšenou produktivitu pomocí určitých funkcí virtuální stroje. ReFS například podporuje kopírování bloků, což urychluje proces kopírování virtuálního stroje a operace slučování kontrolních bodů. Chcete-li vytvořit kopii virtuálního počítače, ReFS vytvoří novou kopii metadat na disku a poskytne odkaz na zkopírovaná data na disku. Je to proto, že s ReFS může více souborů odkazovat na stejná základní data na disku. Poté, co po práci s virtuálním strojem změníte data, jsou zapsána na disk v jiném umístění, ale původní data virtuálního stroje zůstanou na disku. To výrazně urychluje proces vytváření kopií a snižuje zatížení disku.

ReFS podporuje „Sparse VDL“ (vybité soubory). Řídký soubor je soubor, ve kterém byla sekvence nula bajtů nahrazena informací o této sekvenci (seznam děr). Díry jsou specifická sekvence nula bajtů uvnitř souboru, které nebyly zapsány na disk. Samotné informace o dírách jsou uloženy v metadatech souborového systému.

Technologie podpory vybitých souborů umožňuje rychle zapisovat nuly do velkého souboru. Tím se výrazně urychlí proces vytváření nového, prázdný soubor virtuální pevný disk pevná velikost (VHD). Vytvoření takového souboru v ReFS trvá pár sekund, zatímco v NTFS taková operace trvá až 10 minut.

Přesto ReFS není schopen zcela nahradit NTFS

Vše, co jsme popsali výše, zní dobře, ale na ReFS z NTFS nepřejdete. Systém Windows nelze spustit ze systému souborů ReFS a vyžaduje NTFS.

ReFS postrádá mnoho technologií dostupných v NTFS. Například komprese a šifrování systému souborů, pevné odkazy, rozšířené atributy, deduplikace dat a diskové kvóty. Navíc, na rozdíl od NTFS, ReFS podporuje technologii úplného šifrování dat - BitLocker.

Ve Windows 10 nebudete moci naformátovat diskový oddíl pomocí ReFS. Nový souborový systém je dostupný pouze pro úložné systémy, kde je jeho hlavní funkcí ochrana dat před poškozením. V systému Windows Server 2016 budete moci naformátovat oddíl disku pomocí ReFS. Budete jej moci použít ke spuštění virtuálních strojů. Nebudete jej však moci vybrat jako spouštěcí disk. Windows se spouští pouze ze systému souborů NTFS.

Není jasné, jaká budoucnost Microsoftu nový souborový systém přinese. Snad jednoho dne úplně nahradí NTFS Verze Windows. Ale dál tento moment ReFS lze použít pouze pro určité úkoly.

Aplikace ReFS

Na podporu nového operačního systému toho bylo řečeno výše. Jsou popsány nevýhody a výhody. Doporučuji se zastavit a shrnout. Pro jaké účely lze a možná by měl být použit ReFS.

Ve Windows 10 je ReFS použitelný pouze ve spojení s komponentou Storage Spaces. Nezapomeňte naformátovat disk určený pro ukládání dat v systému ReFS, nikoli NTFS. V tomto případě budete moci plně ocenit spolehlivost datového úložiště.

Ve Windows Server můžete naformátovat oddíl pro ReFS pomocí standardu nástroj Windows v konzole Správa disků. Pokud používáte, doporučujeme jej naformátovat pro ReFS virtuální servery. Ale pamatujte si to spouštěcí disk musí být naformátován jako NTFS. Spouštění ze systému souborů ReFS není podporováno operačními systémy Windows.

Nový souborový systém ReFS a Windows 10| 2017-06-28 06:34:15 | Super uživatel | Systémový software | https://site/media/system/images/new.png | Nový souborový systém od Microsoft ReFS nahradil zastaralý NTFS Jaké jsou výhody ReFS a jak se liší od NTFS | refs, refs nebo ntfs, refs windows 10, souborový systém refs, nové systémy souborů, systém ntfs, systém souborů ntfs

Nedávno byla vydána veřejná beta verze Microsoft Windows 8 Server s podporou ohlášeného souborového systému ReFS (Resilient File System), dříve známého jako „Protogon“. Tento souborový systém je nabízen jako alternativa k souborovému systému NTFS, který se léty osvědčil v segmentu systémů pro ukládání dat na bázi produktů Microsoft s jeho další migrací do oblasti klientských systémů.

Účelem tohoto článku je povrchní popis struktury souborového systému, jeho výhod a nevýhod, dále rozbor jeho architektury z hlediska zachování integrity dat a perspektiv obnovy dat v případě poškození resp. smazání uživatelem. Článek také odhaluje studii architektonických vlastností souborového systému a jeho potenciálního výkonu.

Windows Server 8 Beta

Možnost souborového systému dostupná v této verzi operačního systému podporuje pouze 64KB datové clustery a 16KB metadatové clustery. Zatím není jasné, zda bude podpora pro souborové systémy ReFS s jinými velikostmi clusteru: v současnosti je parametr Cluster Size při vytváření svazku ReFS ignorován a je vždy nastaven na výchozí hodnotu. Při formátování FS je jedinou dostupnou možností výběru velikosti clusteru 64 KB. Je také jediným zmíněným na vývojářských blozích.

Tato velikost clusteru je více než dostatečná pro organizaci souborových systémů jakékoli praktické velikosti, ale zároveň vede k výrazné redundanci v ukládání dat.

Architektura souborového systému

Přes časté zmínky o podobnostech mezi ReFS a NTFS na vysoká úroveň, mluvíme pouze o kompatibilitě některých metadatových struktur, jako jsou: „standardní informace“, „název souboru“, kompatibilita s hodnotami některých příznaků atributů atd. Disková implementace struktur ReFS se zásadně liší od jiných souborových systémů společnosti Microsoft.

Hlavními strukturálními prvky nového souborového systému jsou stromy B+. Všechny prvky struktury souborového systému jsou reprezentovány jednoúrovňovými (seznamy) nebo víceúrovňovými B+ stromy, což umožňuje výrazně škálovat téměř kterýkoli z prvků souborového systému. Spolu se skutečným 64bitovým číslováním všech prvků systému to eliminuje výskyt úzkých míst při dalším škálování.

Kromě kořenového záznamu stromu B+ mají všechny ostatní záznamy velikost celého bloku metadat (v v tomto případě- 16 kB); mezilehlé (adresové) uzly mají malou celkovou velikost (asi 60 bajtů). K popisu i velmi rozsáhlých struktur je proto obvykle potřeba malý počet stromových úrovní, což má spíše příznivý vliv na celkový výkon systému.

Hlavním strukturálním prvkem souborového systému je „Adresář“, prezentovaný ve formě B+-stromu, jehož klíčem je číslo objektu složky. Na rozdíl od jiných podobných systémů souborů není soubor v ReFS samostatným klíčovým prvkem „Adresáře“, ale existuje pouze jako záznam ve složce, která jej obsahuje. Může to být kvůli této architektonické funkci, že pevné odkazy na ReFS nejsou podporovány.

„Listy adresáře“ jsou psané záznamy. Existují tři hlavní typy položek pro objekt složky: popisovač adresáře, záznam rejstříku a popisovač vnořeného objektu. Všechny tyto záznamy jsou zabaleny jako samostatný strom B+ s ID složky; kořen tohoto stromu je listem B+-stromu „Adresáře“, který umožňuje zabalit téměř libovolný počet záznamů do složky. Na spodní úrovni v listech B+ stromu složky je primárně položka deskriptoru adresáře obsahující základní informace o složce (jako je název, "standardní informace", atribut názvu souboru atd.). Datové struktury mají mnoho společného s těmi, které byly přijaty v NTFS, i když mají řadu rozdílů, z nichž hlavním je absence typovaného seznamu pojmenovaných atributů.

Další v adresáři jsou tzv. rejstříkové položky: krátké struktury obsahující data o prvcích obsažených ve složce. Ve srovnání s NTFS jsou tyto záznamy mnohem kratší, což snižuje zátěž svazku metadaty. Poslední jsou položky adresáře. U složek tyto prvky obsahují název balíčku, identifikátor složky v „Adresáři“ a strukturu „standardních informací“. U souborů neexistuje žádný identifikátor, ale místo toho struktura obsahuje všechna základní data o souboru, včetně kořene B+ stromu fragmentů souboru. V souladu s tím může soubor sestávat z téměř libovolného počtu fragmentů.

Na disku jsou soubory umístěny v blocích o velikosti 64 kB, i když jsou adresovány stejným způsobem jako bloky metadat (v klastrech o velikosti 16 kB). „Rezidence“ dat souboru není na ReFS podporována, takže 1bajtový soubor na disku zabere celý blok 64 kB, což vede k významné redundanci úložiště u malých souborů; na druhou stranu zjednodušuje správu volný prostor a přidělení volného místa pro nový soubor provedeno mnohem rychleji.

Velikost metadat prázdného souborového systému je asi 0,1 % velikosti samotného souborového systému (tj. asi 2 GB na 2TB svazku). Některá základní metadata jsou duplikována pro lepší odolnost proti chybám.

Důkaz o selhání

Nebylo cílem otestovat stabilitu stávající implementace ReFS. Z pohledu architektury souborového systému má všechny potřebné nástroje pro bezpečnou obnovu souborů i po vážném selhání hardwaru. Části struktur metadat obsahují své vlastní identifikátory, což umožňuje kontrolovat vlastnictví struktur; odkazy metadat obsahují 64bitové kontrolní součty bloků, na které se odkazuje, což umožňuje vyhodnotit integritu bloku načteného z odkazu.

Je třeba poznamenat, že kontrolní součty uživatelských dat (obsah souboru) se nepočítají. Na jednu stranu to vyřadí z provozu mechanismus kontroly integrity v datové oblasti, na druhou stranu to zrychlí chod systému díky minimálnímu počtu změn v oblasti metadat.

Jakákoli změna ve struktuře metadat se provádí ve dvou fázích: nejprve se vytvoří nová (změněná) kopie metadat na volném místě na disku, poté, pokud je úspěšná, operace atomické aktualizace přenese odkaz ze starého (nezměněného) na nová (změněná) oblast metadat. Tato strategie (Copy-on-Write (CoW)) vám umožňuje obejít se bez protokolování a automaticky udržovat integritu dat.

Potvrzení takových změn na disku nemusí trvat dostatečně dlouho, což umožní sloučení několika změn stavu systému souborů do jedné.

Toto schéma se nevztahuje na uživatelská data, takže veškeré změny obsahu souboru se zapisují přímo do souboru. Smazání souboru se provádí přebudováním struktury metadat (pomocí CoW), která ukládá předchozí verze blok metadat na disku. To je to, co obnova dělá. smazané soubory možné, než budou přepsány novými uživatelskými daty.

Redundance datového úložiště

V tomto případě mluvíme o spotřebě místa na disku kvůli schématu ukládání dat. Pro účely testování byl nainstalovaný Windows Server zkopírován do 580GB oddílu ReFS. Velikost metadat na prázdném souborovém systému byla asi 0,73 GB.

Při kopírování nainstalovaný systém Windows Server na oddíl s ReFS, redundance ukládání dat souborů se zvýšila z 0,1 % na NTFS na téměř 30 % na ReFS. Zároveň bylo přidáno asi 10 % redundance kvůli metadatům. Výsledkem bylo, že „uživatelská data“ o velikosti 11 GB (více než 70 tisíc souborů) na NTFS, s přihlédnutím k metadatům, zabrala 11,3 GB, zatímco na ReFS stejná data zabrala 16,2 GB; to znamená, že redundance ukládání dat na ReFS je pro tento typ dat téměř 50 %. U malého počtu velkých souborů tento efekt přirozeně není pozorován.

Rychlost provozu

Vzhledem k tomu, že se bavíme o Betě, nebyla provedena žádná měření výkonu FS. Z pohledu architektury FS lze vyvodit určité závěry. Při kopírování více než 70 tisíc souborů do ReFS to vytvořilo B+ strom „Adresáře“ o velikosti 4 úrovní: „kořen“, střední úroveň 1, střední úroveň 2, „listy“.

Hledání atributů složky (za předpokladu, že kořen stromu je uložen v mezipaměti) tedy vyžaduje 3 čtení bloků o velikosti 16 kB. Pro srovnání, na NTFS bude tato operace trvat jedno čtení o velikosti 1-4 kB (za předpokladu, že mapa umístění $MFT je uložena v mezipaměti).

Hledání atributů souboru podle složky a názvu souboru ve složce (malá složka s několika položkami) na ReFS bude vyžadovat stejná 3 čtení. Na NTFS budou vyžadována 2 čtení po 1 KB nebo 3-4 čtení (pokud je záznam souboru v nerezidentním atributu „index“). Ve větších balíčcích roste počet čtení NTFS mnohem rychleji než počet čtení požadovaných ReFS.

Situace je úplně stejná pro obsah souborů: tam, kde zvýšení počtu fragmentů souborů na NTFS vede k výčtu dlouhých seznamů rozmístěných napříč různými $MFT fragmenty, na ReFS se to provádí efektivním vyhledáváním přes B+ -strom.

závěry

Na konečné závěry je ještě brzy, ale ze současné implementace souborového systému lze vidět potvrzení prvotního zaměření souborového systému na segment serverů a především na virtualizační systémy, DBMS a servery pro ukládání archivních dat. , kde je rychlost a spolehlivost provozu prvořadá. Hlavní nevýhoda souborového systému, jako je neefektivní balení dat na disk, je negována na systémech, které pracují s velkými soubory.

SysDev Laboratories bude sledovat vývoj tohoto souborového systému a plánuje zahrnout podporu pro obnovu dat z tohoto souborového systému. Experimentální podpora ReFS pro beta verzi Microsoft Windows 8 Server již byla úspěšně implementována v produktech UFS Explorer a je k dispozici pro uzavřené beta testování mezi partnery. Oficiální vydání nástrojů pro obnovu smazaných souborů z ReFS a také obnovu dat po poškození souborového systému v důsledku selhání hardwaru je plánováno o něco dříve nebo současně s vydáním Microsoft Windows 8 Server s podporou ReFS.

Verze ze dne 16.03.2012.
Na základě materiálů od SisDev Laboratories

Reprodukce nebo citace jsou povoleny za předpokladu, že bude zachován odkaz na originál.

Nejprve ve Windows Server a nyní ve Windows 10 se objevil moderní souborový systém REFS (Resilient File System), ve kterém můžete formátovat pevné disky počítače nebo vytvářet systémové prostředky úložné prostory.

Tento článek je o tom, co je souborový systém REFS, jeho rozdíly od NTFS a možné aplikace pro běžného domácího uživatele.

Kromě funkcí souvisejících se zachováním integrity dat na discích má REFS následující hlavní rozdíly oproti systému souborů NTFS:

• Obvykle lepší výkon, zejména při použití úložných prostorů.
• Teoretická velikost svazku je 262 144 exabajtů (oproti 16 pro NTFS).
• Bez omezení cesty k souboru na 255 znaků (v REFS - 32768 znaků).
• REFS nepodporuje názvy souborů DOS (tj. přístup ke složce C:\Program Files\ na cestě C:\progra~1\ nebude to fungovat). V NTFS byla tato funkce zachována kvůli kompatibilitě se starším softwarem.
• REFS nepodporuje kompresi, další atributy nebo šifrování pomocí systému souborů (NTFS to má, ale funguje pro REFS).

V tuto chvíli nelze formátovat systémový disk v REFS je tato funkce dostupná pouze pro nesystémové disky (nepodporované pro vyměnitelné jednotky), stejně jako pro úložné prostory, a možná pouze druhá možnost může být skutečně užitečná pro běžný uživatel, který se obává o bezpečnost dat.

Upozorňujeme, že po zformátování disku v souborovém systému REFS bude část místa na něm okamžitě obsazena kontrolními daty: například pro prázdný 10 GB disk je to asi 700 MB.

Je možné, že REFS by se v budoucnu mohl stát primárním souborovým systémem ve Windows, ale to se v tuto chvíli nestalo. Oficiální informace o souborovém systému na webu Microsoftu:

Proč smartphone nespouští programy z paměťové karty? Jak se ext4 zásadně liší od ext3? Proč flash disk vydrží déle, když jej naformátujete na NTFS a ne na FAT? Jaký je hlavní problém F2FS? Odpovědi leží ve strukturálních vlastnostech souborových systémů. Budeme o nich mluvit.

Úvod

Souborové systémy definují způsob ukládání dat. Určují, s jakými omezeními se uživatel setká, jak rychlé budou operace čtení a zápisu a jak dlouho bude disk fungovat bez poruch. To platí zejména pro levné SSD a jejich mladší bratry - flash disky. Znáte-li tyto funkce, můžete z jakéhokoli systému vytěžit maximum a optimalizovat jeho využití pro konkrétní úkoly.

Pokaždé, když potřebujete udělat něco netriviálního, musíte zvolit typ a parametry souborového systému. Chcete například urychlit nejběžnější operace se soubory. Na úrovni souborového systému toho lze dosáhnout různými způsoby: zajistí indexování rychlé hledání a předrezervace volných bloků usnadní přepisování často se měnících souborů. Předběžná optimalizace dat v paměť s náhodným přístupem sníží počet požadovaných I/O operací.

Takové vlastnosti moderních souborových systémů, jako je líný zápis, deduplikace a další pokročilé algoritmy, pomáhají prodloužit dobu bezproblémového provozu. Jsou relevantní zejména pro levné SSD s čipy TLC paměť, flash disky a paměťové karty.

Pro disková pole existují samostatné optimalizace různé úrovně: Systém souborů může například podporovat zjednodušené zrcadlení svazku, okamžité pořizování snímků nebo dynamické škálování bez přepnutí svazku do režimu offline.

Černá skříňka

Uživatelé obecně pracují se systémem souborů, který je standardně nabízen operačním systémem. Málokdy vytvářejí nové diskové oddíly a ještě méně často přemýšlejí o jejich nastavení - jednoduše použijí doporučené parametry nebo dokonce koupí předem naformátovaná média.

Pro fanoušky Windows je vše jednoduché: NTFS na všech diskových oddílech a FAT32 (nebo stejný NTFS) na flash discích. Pokud existuje NAS a používá nějaký jiný souborový systém, pak pro většinu zůstává mimo vnímání. Jednoduše se k němu připojí přes síť a stahují soubory jako z černé skříňky.

Na mobilní gadgety s Androidem ext4 se nejčastěji vyskytuje v vnitřní paměť a FAT32 na microSD kartách. Yabloko vůbec nezajímá, jaký mají souborový systém: HFS+, HFSX, APFS, WTFS... pro ně jsou jen krásné ikony složek a souborů nakreslené těmi nejlepšími designéry. Uživatelé Linuxu mají nejbohatší výběr, ale můžete přidat podporu pro nenativní souborové systémy ve Windows i macOS – o tom později.

Společné kořeny

Bylo vytvořeno přes sto různých souborových systémů, ale o něco více než tucet lze považovat za aktuální. I když byly všechny vyvinuty pro své vlastní specifické aplikace, mnoho z nich spolu souviselo na koncepční úrovni. Jsou si podobné, protože používají stejný typ struktury reprezentace (meta)dat – B-stromy („bi-stromy“).

Jako každý hierarchický systém začíná B-strom kořenovým záznamem a poté se větví na listové prvky – jednotlivé záznamy souborů a jejich atributy neboli „listy“. Hlavním bodem vytvoření takové logické struktury bylo urychlit vyhledávání objektů souborového systému na velkých dynamických polích - jako pevné disky s kapacitou několika terabajtů nebo ještě působivějšími poli RAID.

B-stromy vyžadují mnohem méně přístupů na disk než jiné typy vyvážených stromů k provádění stejných operací. Toho je dosaženo díky tomu, že finální objekty v B-stromech jsou hierarchicky umístěny ve stejné výšce a rychlost všech operací je přesně úměrná výšce stromu.

Stejně jako ostatní vyvážené stromy mají B-stromy stejnou délku cesty od kořene k jakémukoli listu. Místo toho, aby rostly nahoru, více se větví a rozšiřují: všechny body větvení v B-stromu ukládají mnoho odkazů na podřízené objekty, takže je lze snadno najít za méně volání. Velké číslo ukazatele snižují počet časově nejnáročnějších diskových operací – polohování hlavy při čtení libovolných bloků.

Koncept B-stromů byl formulován již v sedmdesátých letech a od té doby prošel různými vylepšeními. V té či oné podobě je implementován v NTFS, BFS, XFS, JFS, ReiserFS a mnoha DBMS. Všichni jsou příbuzní z hlediska základních principů organizace dat. Rozdíly se týkají detailů, často dost důležitých. Související souborové systémy mají také společnou nevýhodu: všechny byly vytvořeny pro specifickou práci s disky ještě před příchodem SSD.

Flash paměť jako motor pokroku

Jednotky SSD postupně nahrazují diskové jednotky, ale prozatím jsou nuceny používat souborové systémy, které jsou jim cizí, předávané děděním. Jsou postaveny na flash paměťových polích, jejichž principy fungování se liší od principů diskových zařízení. Zejména flash paměť musí být před zápisem vymazána, což je operace, kterou čipy NAND nemohou provádět na úrovni jednotlivých buněk. Je to možné pouze u velkých bloků zcela.

Toto omezení je způsobeno tím, že v paměti NAND jsou všechny buňky sloučeny do bloků, z nichž každý má pouze jedno společné připojení k řídicí sběrnici. Nebudeme zabíhat do podrobností o organizaci stránky a popisovat kompletní hierarchii. Důležitý je samotný princip skupinových operací s buňkami a skutečnost, že velikosti bloků flash paměti jsou obvykle větší než bloky adresované v jakémkoli souborovém systému. Proto musí být všechny adresy a příkazy pro disky s NAND flash přeloženy přes abstrakční vrstvu FTL (Flash Translation Layer).

Kompatibilitu s logikou diskových zařízení a podporu příkazů jejich nativních rozhraní zajišťují řadiče flash pamětí. Obvykle je FTL implementováno v jejich firmwaru, ale může být (částečně) implementováno na hostiteli - například Plextor píše ovladače pro své SSD, které urychlují zápis.

Bez FTL se to neobejde, protože i zápis jednoho bitu do konkrétní buňky spouští celou řadu operací: řadič najde blok obsahující požadovanou buňku; blok je celý přečten, zapsán do mezipaměti nebo do volné místo, poté je zcela vymazán a poté je přepsán zpět s nezbytnými změnami.

Tento přístup připomíná každodenní život v armádě: aby mohl dát rozkaz jednomu vojákovi, seržant sestaví všeobecnou formaci, povolá chudáka z formace a ostatním přikáže, aby se rozešli. V dnes již vzácné paměti NOR byly organizací speciální jednotky: každá buňka byla řízena nezávisle (každý tranzistor měl individuální kontakt).

Úkoly pro řadiče přibývají, protože s každou generací flash paměti klesá technický proces její výroby, aby se zvýšila hustota a snížily náklady na ukládání dat. Spolu s technologickými standardy se snižuje i odhadovaná životnost čipů.

Moduly s jednoúrovňovými buňkami SLC měly deklarovaný zdroj 100 tisíc přepisovacích cyklů a ještě více. Mnoho z nich stále funguje na starých flash discích a CF kartách. Pro enterprise-class MLC (eMLC) byl zdroj deklarován v rozmezí 10 až 20 tisíc, zatímco pro běžné spotřebitelské MLC se odhaduje na 3-5 tisíc. Paměti tohoto typu aktivně ždímají ještě levnější TLC, jejichž zdroje sotva dosahují tisíce cyklů. Udržet životnost flash paměti na přijatelné úrovni vyžaduje softwarové triky a jedním z nich se stávají nové souborové systémy.

Zpočátku výrobci předpokládali, že souborový systém není důležitý. Samotný řadič musí obsluhovat krátkodobou řadu paměťových buněk jakéhokoli typu a rozdělovat mezi ně zátěž optimálním způsobem. Pro ovladač souborového systému simuluje běžný disk a sám provádí nízkoúrovňové optimalizace pro jakýkoli přístup. V praxi však optimalizace různá zařízení se liší od magických po fiktivní.

U podnikových SSD je vestavěným řadičem malý počítač. Má velkou vyrovnávací paměť (půl gigabajtu nebo více) a podporuje mnoho technik efektivity dat, aby se zabránilo zbytečným přepisovacím cyklům. Čip organizuje všechny bloky v mezipaměti, provádí líné zápisy, provádí deduplikaci za běhu, rezervuje některé bloky a jiné vymaže na pozadí. Všechna tato kouzla se dějí zcela bez povšimnutí OS, programů a uživatele. U takového SSD je opravdu jedno, jaký souborový systém je použit. Vnitřní optimalizace mají mnohem větší dopad na produktivitu a zdroje než externí.

Levné SSD (a ještě více flash disky) jsou vybaveny mnohem méně chytrými ovladači. Cache v nich je omezená nebo chybí, a ty pokročilé serverové technologie se vůbec neuplatňují. Ovladače v paměťových kartách jsou tak primitivní, že se často tvrdí, že vůbec neexistují. Pro levná zařízení s flash pamětí proto zůstávají relevantní externí metody vyvažování zátěže – především pomocí specializovaných souborových systémů.

Od JFFS po F2FS

Jedním z prvních pokusů napsat souborový systém, který by zohledňoval principy organizace flash paměti, byl JFFS – Journaling Flash File System. Původně byl tento vývoj švédské společnosti Axis Communications zaměřen na zvýšení efektivity paměti síťová zařízení, který Axis vyráběl v devadesátých letech. První verze JFFS podporovala pouze paměť NOR, ale již ve druhé verzi se spřátelila s NAND.

V současné době má JFFS2 omezené použití. Stále se používá hlavně v linuxových distribucích pro vestavěné systémy. Nachází se v routerech, IP kamerách, NAS a dalších stálicích internetu věcí. Obecně všude tam, kde je vyžadováno malé množství spolehlivé paměti.

Dalším pokusem o vývoj JFFS2 byl LogFS, který ukládal inody samostatný soubor. Autory této myšlenky jsou Jorn Engel, zaměstnanec německé divize IBM, a Robert Mertens, učitel na univerzitě v Osnabrücku. Zdroj LogFS je k dispozici na GitHubu. Soudě podle skutečnosti, že poslední změna byla provedena před čtyřmi lety, LogFS nezískal popularitu.

Tyto pokusy však podnítily vznik dalšího specializovaného souborového systému – F2FS. Byl vyvinut společností Samsung Corporation, která tvoří značnou část flash paměti vyráběné ve světě. Samsung vyrábí čipy NAND Flash pro svá vlastní zařízení i pro jiné společnosti a také vyvíjí SSD se zásadně novými rozhraními namísto starších diskových. Vytvoření specializovaného souborového systému optimalizovaného pro flash paměti bylo z pohledu Samsungu dlouho opožděnou nutností.

Před čtyřmi lety, v roce 2012, Samsung vytvořil F2FS (Flash Friendly File System). Její nápad byl dobrý, ale realizace se ukázala jako hrubá. Klíčový úkol při vytváření F2FS byl jednoduchý: snížit počet operací přepisu buněk a rozložit na ně zátěž co nejrovnoměrněji. To vyžaduje provádění operací na více buňkách ve stejném bloku současně, spíše než je vynucovat jednu po druhé. To znamená, že není potřeba okamžité přepisování existujících bloků na první žádost OS, ale ukládání příkazů a dat do mezipaměti, přidávání nových bloků do volného místa a zpožděné mazání buněk.

Dnes je již podpora F2FS v Linuxu (a potažmo v Androidu) oficiálně implementována, ale v praxi zatím nepřináší žádné zvláštní výhody. Hlavní rys tohoto souborového systému (líné přepisování) vedl k předčasným závěrům o jeho účinnosti. Starý trik s ukládáním do mezipaměti dokonce oklamal rané verze benchmarků, kde F2FS prokázalo pomyslnou výhodu ne o pár procent (jak se očekávalo), nebo dokonce o několiknásobek, ale o řády. Ovladač F2FS jednoduše ohlásil dokončení operace, kterou ovladač právě plánoval provést. Pokud je ale skutečný výkonový zisk pro F2FS malý, tak opotřebení článků bude určitě menší než při použití stejného ext4. Ty optimalizace, které levný řadič neumí, budou provedeny na úrovni samotného souborového systému.

Rozsahy a bitmapy

F2FS je prozatím pro geeky vnímáno jako exotické. I ve svém vlastním smartphony Samsung ext4 stále platí. Mnozí to považují za další vývoj ext3, ale není to tak úplně pravda. Jde spíše o revoluci než o prolomení hranice 2 TB na soubor a pouhé zvýšení dalších kvantitativních ukazatelů.

Když byly počítače velké a soubory malé, adresování nebyl problém. Každému souboru byl přidělen určitý počet bloků, jejichž adresy byly zaneseny do korespondenční tabulky. Takto fungoval souborový systém ext3, který funguje dodnes. Ale v ext4 se objevil zásadně odlišný způsob adresování - rozsahy.

Oblasti lze považovat za rozšíření inodů jako diskrétní sady bloků, které jsou zcela adresovány jako souvislé sekvence. Jeden rozsah může obsahovat celý středně velký soubor, ale pro velké soubory stačí přidělit tucet nebo dva rozsahy. To je mnohem efektivnější než adresování stovek tisíc malých bloků o čtyřech kilobajtech.

Samotný nahrávací mechanismus se v ext4 také změnil. Nyní jsou bloky distribuovány okamžitě v jedné žádosti. A to ne předem, ale bezprostředně před zápisem dat na disk. Líná alokace více bloků vám umožňuje zbavit se zbytečných operací, kterými se ext3 provinil: v něm byly bloky pro nový soubor alokovány okamžitě, i když se celý vešel do mezipaměti a byl plánován jako dočasné smazání.

Dieta s omezením TUKU

Kromě vyvážených stromů a jejich modifikací existují další oblíbené logické struktury. Existují souborové systémy se zásadně odlišným typem organizace – například lineární. Pravděpodobně alespoň jeden z nich používáte často.

Tajemství

Hádejte hádanku: ve dvanácti začala přibírat, v šestnácti byla hloupá tlustá a ve dvaatřiceti ztloustla a zůstala prosťáčka. Kdo je ona?

Správně, toto je příběh o systému souborů FAT. Požadavky na kompatibilitu jí zajistily špatnou dědičnost. Na disketách to bylo 12bitové, zap pevné disky- nejprve to bylo 16bitové, ale do dnešních dnů se dostalo jako 32bitové. V každé další verzi se počet adresovatelných bloků zvyšoval, ale na její podstatě se nic nezměnilo.

Stále oblíbený souborový systém FAT32 se objevil před dvaceti lety. Dnes je stále primitivní a nepodporuje seznamy řízení přístupu, diskové kvóty, kompresi na pozadí ani jiné moderní technologie optimalizace zpracování dat.

Proč je v dnešní době potřeba FAT32? Vše je stále pouze pro zajištění kompatibility. Výrobci se správně domnívají, že oddíl FAT32 může číst jakýkoli OS. Proto to vytvářejí na vnější tvrdý disky, USB Flash a paměťové karty.

Jak uvolnit flash paměť smartphonu

Karty microSD(HC) používané v chytrých telefonech jsou ve výchozím nastavení naformátovány na FAT32. To je hlavní překážkou instalace aplikací na ně a přenosu dat z interní paměti. Abyste to překonali, musíte na kartě vytvořit oddíl s ext3 nebo ext4. Lze do něj přenést všechny atributy souborů (včetně vlastníka a přístupových práv), takže jakákoli aplikace může fungovat, jako by byla spuštěna z vnitřní paměti.

Windows neumí vytvořit více než jeden oddíl na flash discích, ale za tímto účelem můžete spustit Linux (alespoň ve virtuálním stroji) nebo pokročilý nástroj pro práci s logickými oddíly - například MiniTool Partition Wizard Free. Po objevení dalšího primárního oddílu s ext3/ext4 na kartě nabídne aplikace Link2SD a podobné mnohem více možností než v případě jednoho oddílu FAT32.

Další argument ve prospěch výběru FAT32 je často uváděn jako nedostatek žurnálování, což znamená více rychlé operace zápisy a menší opotřebení paměťových buněk NAND Flash. V praxi vede použití FAT32 k opaku a přináší mnoho dalších problémů.

Flash disky a paměťové karty rychle umírají kvůli skutečnosti, že jakákoli změna v FAT32 způsobí přepsání stejných sektorů, kde jsou umístěny dva řetězce tabulek souborů. Uložil jsem celou webovou stránku a byla stokrát přepsána - s každým přidáním dalšího malého GIF na flash disk. Spustili jste přenosný software? Vytváří dočasné soubory a za běhu je neustále mění. Proto je mnohem lepší používat NTFS na flash discích s tabulkou $MFT odolnou proti selhání. Malé soubory lze ukládat přímo do hlavní tabulky souborů a zapisují se do ní její přípony a kopie různé oblasti flash paměti. Indexování NTFS navíc zrychluje vyhledávání.

INFO

Pro FAT32 a NTFS nejsou teoretická omezení úrovně vnoření specifikována, ale v praxi jsou stejná: v adresáři první úrovně lze vytvořit pouze 7707 podadresářů. Ti, kteří si rádi hrají na matrjošky, to ocení.

Dalším problémem, se kterým se většina uživatelů potýká, je, že není možné zapsat soubor větší než 4 GB na oddíl FAT32. Důvodem je, že ve FAT32 je velikost souboru popsána 32 bity v alokační tabulce souborů a 2^32 (mínus jeden, abych byl přesný) jsou přesně čtyři koncerty. Ukazuje se, že na čerstvě zakoupenou flashku nelze zapsat ani film v běžné kvalitě, ani obraz DVD.

Kopírování velkých souborů není tak špatné: když se o to pokusíte, chyba je alespoň okamžitě viditelná. V jiných situacích funguje FAT32 jako časovaná bomba. Přenosný software jste si například zkopírovali na flash disk a zpočátku jej bez problémů používáte. Po dlouhé době se některý z programů (například účetnictví nebo email), databáze nafoukne a... prostě se přestane aktualizovat. Soubor nelze přepsat, protože dosáhl limitu 4 GB.

Méně zřejmým problémem je, že v systému FAT32 lze datum vytvoření souboru nebo adresáře zadat do dvou sekund. To není dostatečné pro mnoho kryptografických aplikací, které používají časová razítka. Nízká přesnost atributu data je dalším důvodem, proč FAT32 není z hlediska zabezpečení považován za platný souborový systém. Jeho slabiny však lze využít i pro vlastní účely. Pokud například zkopírujete jakékoli soubory z oddílu NTFS na svazek FAT32, budou z nich vymazána všechna metadata a také zděděná a speciálně nastavená oprávnění. FAT je prostě nepodporuje.

exFAT

Na rozdíl od FAT12/16/32 byl exFAT vyvinut speciálně pro USB Flash a velké (≥ 32 GB) paměťové karty. Rozšířený FAT odstraňuje výše zmíněnou nevýhodu FAT32 - přepisování stejných sektorů při jakékoliv změně. Jako 64bitový systém nemá prakticky významná omezení velikosti jednoho souboru. Teoreticky může mít délku 2^64 bajtů (16 EB) a karty této velikosti se brzy neobjeví.

Další důležitá věc exFAT rozdíl- podpora seznamů řízení přístupu (ACL). To už není stejný prosťáček z devadesátých let, ale uzavřenost formátu brání implementaci exFAT. Podpora ExFAT je plně a legálně implementována pouze ve Windows (od XP SP2) a OS X (od 10.6.5). Na Linuxu a *BSD je podporován buď s omezeními, nebo ne zcela legálně. Microsoft vyžaduje licencování pro použití exFAT a v této oblasti existuje mnoho právních sporů.

Btrfs

Další významný zástupce souborových systémů založených na B-stromech se nazývá Btrfs. Tento FS se objevil v roce 2007 a původně byl vytvořen v Oracle s ohledem na práci s SSD a RAID. Lze jej například dynamicky škálovat: vytvářet nové inody přímo na běžícím systému nebo rozdělovat svazek na podsvazky, aniž by jim bylo přiděleno volné místo.

Mechanismus copy-on-write implementovaný v Btrfs a plná integrace s modulem Device mapper kernel vám umožňují pořizovat téměř okamžité snímky prostřednictvím virtuálních blokových zařízení. Předkomprese (zlib nebo lzo) a deduplikace urychlují základní operace a zároveň prodlužují životnost flash paměti. To je patrné zejména při práci s databázemi (je dosaženo 2-4násobné komprese) a malými soubory (jsou zapisovány v uspořádaných velkých blocích a lze je ukládat přímo do „listů“).

Btrfs také podporuje úplný režim protokolování (data a metadata), kontrolu objemu bez odpojení a mnoho dalších moderních funkcí. Kód Btrfs je publikován pod licencí GPL. Tento souborový systém je v Linuxu podporován jako stabilní od verze jádra 4.3.1.

Deníky

Téměř všechny více či méně moderní souborové systémy (ext3/ext4, NTFS, HFSX, Btrfs a další) patří do obecné skupiny žurnálovaných, protože uchovávají záznamy o provedených změnách v samostatném protokolu (žurnálu) a jsou proti němu kontrolovány v případ selhání během diskových operací . Nicméně granularita protokolování a odolnost proti chybám těchto systémů souborů se liší.

Ext3 podporuje tři režimy protokolování: s zpětná vazba, organizované a kompletní protokolování. První režim zahrnuje zaznamenávání pouze obecných změn (metadat), prováděných asynchronně s ohledem na změny v samotných datech. Ve druhém režimu se provádí stejný záznam metadat, ale přísně před provedením jakýchkoli změn. Třetí režim je ekvivalentní úplnému protokolování (změny jak v metadatech, tak v samotných souborech).

Pouze poslední možnost zajišťuje integritu dat. Zbývající dva pouze urychlují detekci chyb během kontroly a zaručují obnovení integrity samotného souborového systému, nikoli však obsahu souborů.

Žurnálování v NTFS je podobné druhému režimu protokolování v ext3. Do protokolu se zapisují pouze změny metadat a samotná data mohou být v případě poruchy ztracena. Tato metoda protokolování v NTFS nebyla zamýšlena jako způsob dosažení maximální spolehlivosti, ale pouze jako kompromis mezi výkonem a odolností proti chybám. To je důvod, proč lidé, kteří jsou zvyklí pracovat s plně žurnálovanými systémy, zvažují pseudožurnálování NTFS.

Přístup implementovaný v NTFS je v některých ohledech dokonce lepší než výchozí v ext3. Systém NTFS navíc pravidelně vytváří kontrolní body, aby zajistil dokončení všech dříve odložených diskových operací. Kontrolní body nemají nic společného s body obnovy v \System Volume Information\ . Toto jsou pouze záznamy protokolu služeb.

Praxe ukazuje, že takovéto částečné žurnálování NTFS ve většině případů pro bezproblémový provoz postačuje. Disková zařízení totiž neztrácejí energii okamžitě ani při náhlém výpadku proudu. Napájecí zdroj a četné kondenzátory v samotných jednotkách poskytují jen minimální množství energie, které stačí k dokončení aktuální operace zápisu. U moderních SSD disků s jejich rychlostí a efektivitou obvykle stačí stejné množství energie k provedení nevyřízených operací. Pokus o přechod na úplné protokolování by výrazně snížil rychlost většiny operací.

Připojení souborů třetích stran v systému Windows

Použití souborových systémů je omezeno jejich podporou na úrovni OS. Windows si například nerozumí s ext2/3/4 a HFS+, ale někdy je nutné je použít. To lze provést přidáním příslušného ovladače.

VAROVÁNÍ

Většina ovladačů a pluginů pro podporu systémů souborů třetích stran má svá omezení a ne vždy fungují stabilně. Mohou být v konfliktu s jinými ovladači, antiviry a virtualizačními programy.

Otevřený ovladač pro čtení a zápis ext2/3 oddílů s částečnou podporou ext4. V Nejnovější verze jsou podporovány oblasti a oddíly až do 16 TB. LVM, seznamy řízení přístupu a rozšířené atributy nejsou podporovány.

Existuje bezplatný plugin pro Total Commander. Podporuje čtení ext2/3/4 oddílů.

coLinux je otevřený a bezplatný port linuxového jádra. Spolu s 32bitovým ovladačem vám umožňuje provozovat Linux Prostředí Windows od roku 2000 do 7 bez použití virtualizačních technologií. Podporuje pouze 32bitové verze. Vývoj 64bitové modifikace byl zrušen. coLinux umožňuje mimo jiné organizovat z Windows přístup do oddílů ext2/3/4. Podpora projektu byla v roce 2014 pozastavena.

Windows 10 již může mít vestavěnou podporu pro souborové systémy specifické pro Linux, je pouze skrytá. Tyto myšlenky navrhuje ovladač na úrovni jádra Lxcore.sys a služba LxssManager, která je načtena jako knihovna procesem Svchost.exe. Další informace o tom najdete ve zprávě Alexe Ionesca „Linuxové jádro skryté uvnitř Windows 10“, kterou přednesl na Black Hat 2016.

ExtFS pro Windows je placený ovladač od Paragonu. Běží na Windows 7 až 10 a podporuje přístup pro čtení/zápis do svazků ext2/3/4. Poskytuje téměř kompletní podporu pro ext4 ve Windows.

HFS+ pro Windows 10 je další proprietární ovladač od Paragon Software. Navzdory názvu funguje ve všech verzích Windows počínaje XP. Poskytuje plný přístup k systémům souborů HFS+/HFSX na discích s libovolným rozložením (MBR/GPT).

WinBtrfs je raný vývoj ovladače Btrfs pro Windows. Již ve verzi 0.6 podporuje přístup pro čtení i zápis do svazků Btrfs. Zvládne pevné i symbolické odkazy, podporuje alternativní datové toky, ACL, dva typy komprese a asynchronní režim čtení/zápisu. Zatímco WinBtrfs neví, jak používat mkfs.btrfs, btrfs-balance a další nástroje k údržbě tohoto souborového systému.

Schopnosti a omezení souborových systémů: souhrnná tabulka

Souborový systém	Maximální velikost svazku	Omezte velikost jednoho souboru	Délka správného názvu souboru	Délka celého názvu souboru (včetně cesty od kořenového adresáře)	Omezte počet souborů a/nebo adresářů	Přesnost indikace data souboru/adresáře	Práva dos-tu-pa	Pevné odkazy	Symbolické odkazy	Momentky	Komprese dat na pozadí	Šifrování dat na pozadí	Dědeček-ple-ka-tion dat
FAT16	2 GB v 512 bajtových sektorech nebo 4 GB v 64 kB clusterech	2 GB	255 bajtů s LFN	-	-	-	-	-	-	-	-	-	-
FAT32	8 TB sektorů po 2 KB	4 GB (2^32 – 1 bajt)	255 bajtů s LFN	až 32 podadresářů s CDS	65460	10 ms (vytvořit) / 2 s (upravit)	Ne	Ne	Ne	Ne	Ne	Ne	Ne
exFAT	≈ 128 PB (2^32-1 shluky 2^25-1 bajtů) teoreticky / 512 TB kvůli omezením třetích stran	16 EB (2^64 – 1 bajt)			2796202 v katalogu	10 ms	ACL	Ne	Ne	Ne	Ne	Ne	Ne
NTFS	256 TB v klastrech o velikosti 64 kB nebo 16 TB v klastrech o velikosti 4 kB	16 TB (Win 7) / 256 TB (Win 8)	255 znaků Unicode (UTF-16)	32 760 znaků Unicode, maximálně 255 znaků na prvek	2^32-1	100 ns	ACL	Ano	Ano	Ano	Ano	Ano	Ano
HFS+	8 EB (2^63 bajtů)	8 EB	255 znaků Unicode (UTF-16)	samostatně neomezené	2^32-1	1 s	Unix, ACL	Ano	Ano	Ne	Ano	Ano	Ne
APFS	8 EB (2^63 bajtů)	8 EB	255 znaků Unicode (UTF-16)	samostatně neomezené	2^63	1 ns	Unix, ACL	Ano	Ano	Ano	Ano	Ano	Ano
Ext3	32 TB (teoreticky) / 16 TB ve 4 kB clusterech (kvůli omezení programů e2fs)	2 TB (teoreticky) / 16 GB pro starší programy	255 znaků Unicode (UTF-16)	samostatně neomezené	-	1 s	Unix, ACL	Ano	Ano	Ne	Ne	Ne	Ne
Ext4	1 EB (teoreticky) / 16 TB ve 4 KB clusterech (kvůli omezení programů e2fs)	16 TB	255 znaků Unicode (UTF-16)	samostatně neomezené	4 miliardy	1 ns	POSIX	Ano	Ano	Ne	Ne	Ano	Ne
F2FS	16 TB	3,94 TB	255 bajtů	samostatně neomezené	-	1 ns	POSIX, ACL	Ano	Ano	Ne	Ne	Ano	Ne
BTRFS	16 EB (2^64 – 1 bajt)	16 EB	255 znaků ASCII	2^17 bajtů	-	1 ns	POSIX, ACL	Ano	Ano	Ano	Ano	Ano	Ano

Metoda ukládání čehokoli obvykle vždy znamená určitou uspořádanost, ale pokud to v lidském životě není podmínkou, pak ve světě počítačů je ukládání dat bez toho téměř nemožné. Tato uspořádanost se odráží v systému souborů, což je koncept známý většině uživatelů různých elektronická zařízení a operační systémy.

Systém souborů lze přirovnat k určitému druhu označení, které určuje, jak, kde a jakým způsobem by měl být každý bajt zapsán na médium. První souborové systémy, které se objevily na úsvitu elektronické éry, byly velmi nedokonalé, jako například Minix, souborový systém, který má mnoho omezení a používá se ve operační systém Minix, který se později stal prototypem linuxového jádra.

Ale čas plynul, objevily se nové systémy souborů, pokročilejší a stabilnější. Dnes nejoblíbenější z nich, alespoň mezi Uživatelé Windows, je NTFS, který nahradil FAT32, který se nyní používá pouze v malých flash discích a má mnoho nevýhod, z nichž nejvýznamnější je nemožnost zapisovat soubory větší než 4 GB. NTFS však není bez nich. Podle mnoha odborníků tedy postrádá efektivitu, výkon a stabilitu, a proto nastal čas přemýšlet o vytvoření ještě pokročilejšího souborového systému, který dokáže splnit rostoucí požadavky nejprve serverových a poté klientských systémů.

A tak v roce 2012 vývojáři Microsoftu představili Resilient File System nebo zkráceně ReFS, obnovitelný souborový systém umístěný jako alternativa k NTFS a v budoucnu možná jeho náhrada. ReFS je ve skutečnosti pokračováním vývoje NTFS, ze kterého bylo rozhodnuto odstranit všechny nepotřebné věci, které se nikdy nestaly populární, a místo toho přidat nové funkce.

Novinky v odolném systému souborů:

• Architektura pomocí funkce (úložné prostory)
• Vysoká odolnost proti poruchám. Chyby souborového systému, které vedly ke ztrátě dat v NTFS, budou v ReFS minimalizovány
• Izolace poškozených oblastí. Pokud jsou oblasti souborového systému poškozeny, lze k zaznamenaným datům přistupovat ze systému Windows
• Proaktivní oprava chyb. Automaticky skenuje svazky na poškození a aplikuje preventivní opatření pro obnovu dat
• Automatické obnovení podsložky a související soubory, když jsou poškozena metadata
• Použití redundantních zápisů ke zlepšení odolnosti proti chybám
• Maximální velikost svazku v ReFS může dosáhnout 402 EB oproti 18,4 EB v NTFS
• Soubor o velikosti 18,3 EB lze zapsat do souboru naformátovaného v ReFS
• Počet souborů v jedné složce je 18 bilionů. oproti 4,3 miliardám v NTFS
• Délka názvu souboru a cesta k němu je 32767 oproti 255 v NTFS

Co bude odstraněno:

• Podpora komprese dat
• Šifrování dat pomocí technologie EFS
• Rozšířené atributy souboru
• Pevné odkazy
• Diskové kvóty
• Podpora krátkých jmen a ID objektů
• Možnost změny velikosti clusteru (zůstává v otázce)

Co bude zděděno z NTFS:

• seznamy řízení přístupu (ACL)
• Vytváření snímků svazku
• Montážní body
• Body přepracování
• Šifrování BitLocker
• Vytváření a používání symbolických odkazů
• Záznam všech změn v systému souborů (USN log)

V současné době je ReFS v počáteční fázi testování, nicméně počítačoví nadšenci mohou ocenit výhody ReFS nyní a na klientovi systém Windows 8.1 nebo 10. Chcete-li to provést, budete muset provést následující vylepšení registru:

Nicméně při použití ReFS zapnuto trvalý základ Nedoporučeno. Za prvé je systém stále nedokončený a za druhé je zde jakákoli možnost konverze na ReFS a naopak programy třetích stran chybí, za třetí, pokud omylem ztratíte nebo smažete soubory z oddílu naformátovaného v ReFS, nebude je možné čím obnovit, protože zatím neexistují žádné programy pro obnovu dat, které by s tímto souborovým systémem pracovaly.

Měli bychom v blízké budoucnosti očekávat implementaci ReFS? S větší jistotou můžeme říci, že ne. Pokud se dostane do praxe, bude to nejprve na serverových systémech, což se také nestane brzy, ale uživatelé klientských Windows si na to budou muset ještě minimálně pět let počkat. Stačí si připomenout implementaci NTFS na klientských systémech a pak to Microsoftu trvalo sedm let. No, nejdůležitější je, že ReFS prostě není potřeba. Až se na stolních počítačích objeví zettabyte disky, pak možná přijde nejlepší hodina pro ReFS, ale zatím musíme být trpěliví a čekat.

Měj krásný zbytek dne!