Noul sistem de fișiere ReFS de la Microsoft a apărut inițial pe servere care rulează Windows 2012. A fost inclus ulterior în Windows 10, unde poate fi utilizat doar ca parte a caracteristicii Spații de stocare a unui pool de discuri. În Windows Server 2016, Microsoft promite să îmbunătățească semnificativ funcționarea cu sistemul de fișiere ReFS, în plus, conform zvonurilor tipărite, ReFS poate veni să înlocuiască sistemul de fișiere NTFS învechit în noua versiune de Windows 10, care se numește cu mândrie Windows 10 Pro (pentru PC-uri avansate).
Dar ce este mai exact ReF-urile, cum diferă de sistemul de fișiere NTFS utilizat în prezent și ce avantaje are?
Pe scurt, a fost conceput ca un sistem de fișiere tolerant la erori. ReFS este un nou sistem de fișiere construit cu cod și este în esență un sistem de fișiere NTFS reproiectat și îmbunătățit. Acestea includ o fiabilitate îmbunătățită a stocării informațiilor, o funcționare stabilă în modurile de solicitare, dimensiuni de fișiere, volume, directoare, numărul de fișiere din volume și directoare este limitat doar de dimensiunea numerelor pe 64 de biți. Reamintim că maximul pentru această valoare, dimensiunea maximă a fișierului va fi de 16 exbibiți, iar dimensiunea volumului este de 1 yobibyte.
În prezent, ReFS nu este un înlocuitor pentru NTFS. Are avantaje și dezavantaje. Dar nu puteți, să zicem, să formatați discul și să instalați o copie nouă a Windows pe el așa cum ați face pe NTFS.
ReFS utilizează sumele de verificare pentru metadate și poate utiliza, de asemenea, sumele de verificare pentru fișierele de date. De fiecare dată când citiți sau scrieți fișiere, ReFS verifică suma de verificare pentru a vă asigura că este corectă. Aceasta înseamnă că sistemul de fișiere în sine are un instrument capabil să detecteze datele corupte din mers.
ReFS este integrat cu spații de stocare. Dacă ați configurat oglindirea activată ReFS, Windows poate detecta cu ușurință corupția sistemului de fișiere și o poate repara automat copiind datele oglindite pe discul deteriorat. Această caracteristică este disponibilă atât pentru Windows 10, cât și pentru Windows 8.1.
Dacă ReFS detectează date corupte și copia necesară a datelor nu este disponibilă pentru recuperare, sistemul de fișiere poate elimina imediat datele corupte de pe disc. Acest lucru nu necesită o repornire a sistemului, spre deosebire de NTFS.
ReFS face mai mult decât să verifice integritatea fișierelor pe măsură ce acestea sunt citite. Scanează automat integritatea datelor, verificând în mod regulat toate fișierele de pe disc, identificând și reparând datele corupte. În acest caz, nu este nevoie să rulați periodic comanda chkdsk pentru a verifica discul.
Noul sistem de fișiere este, de asemenea, rezistent la corupția datelor în alte moduri. De exemplu, actualizați metadatele unui fișier (deși un nume de fișier). Sistemul de fișiere NTFS modifică direct metadatele fișierului. Dacă are loc o blocare a sistemului (oprire) în acest moment, este foarte probabil ca fișierul să fie deteriorat. Când modificați metadatele, sistemul de fișiere ReFS creează o nouă copie a metadatelor. Sistemul de fișiere nu suprascrie vechile metadate, ci le scrie într-un bloc nou. Aceasta elimină posibilitatea deteriorării fișierului. Această strategie se numește „copy-on-write”. Această strategie este disponibilă pe alte sisteme de fișiere moderne, cum ar fi ZFS și BtrFS pe Linux, precum și pe noul sistem de fișiere APFS de la Apple.
ReFS este mai modern decât NTFS și acceptă cantități mult mai mari de date și nume de fișiere mai lungi. Acest lucru este foarte important pe termen lung.
În sistemul de fișiere NTFS, calea fișierului este limitată la 255 de caractere. În ReFS, numărul maxim de caractere este deja de 32.768 de caractere impresionante. În prezent, în Windows 10 există o opțiune pentru a dezactiva elementul de caracter pentru NTFS. Această limită este dezactivată în mod implicit pe volumele de disc ReFS.
ReFS nu acceptă numele de fișier DOS 8.3. Pe volumele NTFS, aveți acces la folderele „CProgram Files”, „CProgra`1”. Sunt necesare pentru compatibilitatea cu vechile software... În ReFS, nu veți găsi folderele cu care suntem obișnuiți. Ele sunt eliminate.
Cantitatea teoretică maximă de date acceptată de NTFS este de 16 exabytes, ReFS acceptă până la 262.144 exabytes. Acum această cifră pare enormă.
Dezvoltatorii nu au urmărit să creeze un sistem de fișiere mai eficient. Au creat un sistem mai raționalizat.
De exemplu, atunci când este utilizat cu o matrice, ReFS acceptă optimizarea nivelului în timp real. Aveți un grup de unități cu două discuri asamblat. Primul disc este selectat pentru viteză mare, acces rapid la date. Al doilea disc este selectat cu un criteriu de fiabilitate pentru stocarea pe termen lung a datelor. În fundal, ReFS va muta automat bucăți mari de date pe un disc mai lent, asigurându-se astfel că datele sunt salvate în mod fiabil.
În Windows Server 2016, dezvoltatorii au adăugat un instrument care oferă îmbunătățiri ale performanței utilizând caracteristici specifice mașinilor virtuale. De exemplu, ReFS acceptă copierea blocurilor, ceea ce accelerează procesul de copiere a mașinilor virtuale și fuzionarea punctelor de control. Pentru a crea o copie a unei mașini virtuale, ReFS creează o nouă copie a metadatelor de pe disc și oferă un link către datele copiate de pe disc. Aceasta pentru ca mai multe fișiere să poată face referire la aceleași date subiacente pe disc utilizând ReFS. După ce ați lucrat cu mașina virtuală, modificați datele, acestea sunt scrise pe disc într-o altă locație, iar datele originale ale mașinii virtuale rămân pe disc. Acest lucru accelerează foarte mult procesul de creare a copiilor și reduce sarcina pe disc.
ReFS acceptă „Sparse VDL” (fișiere rare). Un fișier subțire este un fișier în care o secvență de zero octeți este înlocuită cu informații despre acea secvență (o listă de găuri). Găurile sunt o secvență specifică de zero octeți în interiorul unui fișier, care nu sunt scrise pe disc. Informațiile despre gaură în sine sunt stocate în metadatele sistemului de fișiere.
Tehnologia de suport a fișierelor rare vă permite să scrieți rapid zerouri într-un fișier mare. Acest lucru accelerează foarte mult procesul de creare a unui fișier nou, gol, de dimensiune fixă virtuală (VHD). Crearea unui astfel de fișier în ReFS durează câteva secunde, în timp ce în NTFS durează până la 10 minute.
Tot ce am descris mai sus sună bine, dar nu veți putea trece la ReFS din NTFS. Windows nu poate porni din ReFS, necesitând NTFS.
ReFS nu are multe dintre tehnologiile disponibile în NTFS. De exemplu, compresia și criptarea sistemului de fișiere, legăturile dure, atributele extinse, deduplicarea datelor și cotele de disc. În același timp, spre deosebire de NTFS, ReFS acceptă tehnologia completă de criptare a datelor - BitLocker.
În Windows 10, nu veți putea formata o partiție de disc cu ReFS. Noul sistem de fișiere este disponibil numai pentru sistemele de stocare, unde funcția sa principală este de a proteja datele de daune. În Windows Server 2016, veți putea formata partiția de disc cu ReFS. Îl veți putea folosi pentru a rula mașini virtuale. Dar nu îl veți putea selecta ca disc de boot. Windows pornește numai din sistemul de fișiere NTFS.
Nu este clar ce viitor își rezervă Microsoft pentru noul sistem de fișiere. Poate că într-o zi va înlocui complet NTFS în toate versiunile de Windows. Dar, în acest moment, ReFS poate fi utilizat doar pentru anumite sarcini.
S-au spus multe despre sprijinul noului sistem de operare. Sunt descrise contra și pro. Propun să mă opresc și să rezum. În ce scop este posibil și poate că este necesar să utilizați ReFS.
În Windows 10, ReFS se aplică numai împreună cu componenta Spații de stocare. Asigurați-vă că ați formatat unitatea de stocare cu ReFS și nu cu NTFS. În acest caz, veți putea aprecia pe deplin fiabilitatea stocării datelor.
Pe Windows Server, veți putea formata partiția pentru ReFS utilizând instrumentul Windows standard din Consola de gestionare a discurilor. Este recomandat să vă asigurați că formatați pentru ReFS dacă utilizați servere virtuale. Nu uitați însă că discul de boot trebuie să fie formatat NTFS. Pornirea din sistemul de fișiere ReFS nu este acceptată pe sistemele de operare Windows.
Nou sistem de fișiere ReFS și Windows 10| 28.06.2017 06:34:15 | Super Utilizator | Software de sistem | https: //site/media/system/images/new.png | Noul sistem de fișiere de la Microsoft ReFS a venit să înlocuiască NTFS învechit. Care sunt avantajele ReFS și cum diferă de NTFS | refs, refs sau ntfs, refs windows 10, refs sistem de fișiere, sisteme de fișiere noi, sistem ntfs, sistem de fișiere ntfs
De ce un smartphone nu poate lansa programe de pe un card de memorie? Cum diferă ext4 fundamental de ext3? De ce o unitate flash va trăi mai mult dacă este formatată pe NTFS în loc de FAT? Care este principala problemă cu F2FS? Răspunsurile stau în particularitățile structurii sistemelor de fișiere. Vom vorbi despre ele.
Sistemele de fișiere determină modul în care sunt stocate datele. Ele determină ce restricții se va confrunta utilizatorul, cât de rapide vor fi operațiile de citire și scriere și cât timp va funcționa unitatea fără eșecuri. Acest lucru este valabil mai ales pentru SSD-urile bugetare și pentru frații lor mai mici - unități flash. Cunoscând aceste caracteristici, puteți extrage maximul din orice sistem și puteți optimiza utilizarea acestuia pentru sarcini specifice.
Trebuie să alegeți tipul și parametrii sistemului de fișiere de fiecare dată când trebuie să faceți ceva non-banal. De exemplu, doriți să accelerați cele mai frecvente operații de fișiere. La nivel de sistem de fișiere, acest lucru poate fi realizat în mai multe moduri: indexarea va oferi căutări rapide, iar rezervarea prealabilă a blocurilor gratuite va facilita suprascrierea fișierelor care se schimbă frecvent. Pre-optimizarea datelor în memorie cu acces aleator va reduce numărul de operații I / O necesare.
Caracteristicile sistemelor de fișiere moderne, cum ar fi scrierea leneșă, deduplicarea și alți algoritmi avansați, ajută la prelungirea timpului de funcționare. Sunt deosebit de relevante pentru SSD-uri ieftine cu cipuri de memorie TLC, unități flash și carduri de memorie.
Există optimizări separate pentru tablourile de discuri de diferite niveluri: de exemplu, sistemul de fișiere poate accepta oglindirea ușoară a volumului, instantanee sau scalare dinamică fără a scoate un volum offline.
Utilizatorii lucrează în principal cu sistemul de fișiere oferit de sistemul de operare în mod implicit. Rareori creează partiții noi de disc și chiar mai rar se gândesc la setările lor - folosesc doar parametrii recomandați sau chiar cumpără suporturi pre-formatate.
Pentru fanii Windows, totul este simplu: NTFS pe toate partițiile de disc și FAT32 (sau același NTFS) pe unitățile flash. Dacă există un NAS și se utilizează un alt sistem de fișiere, atunci pentru majoritate acest lucru rămâne dincolo de percepție. Pur și simplu se conectează la acesta prin rețea și descarcă fișiere, parcă dintr-o cutie neagră.
Pe gadgeturile mobile cu Android, ext4 se găsește cel mai adesea în memoria internă și FAT32 pe cardurile microSD. Pentru Apple, nu contează deloc ce fel de sistem de fișiere au: HFS +, HFSX, APFS, WTFS ... pentru ei există doar pictograme frumoase de dosare și fișiere desenate de cei mai buni designeri. Utilizatorii Linux au cea mai bogată alegere, dar puteți adăuga suport pentru sistemele de fișiere care nu sunt native pentru sistemul de operare atât în Windows, cât și în macOS - mai multe despre asta mai târziu.
Au fost create peste o sută de sisteme de fișiere diferite, dar puțin mai mult de o duzină pot fi numite relevante. În timp ce toate au fost concepute pentru aplicațiile lor specifice, multe au ajuns să fie legate conceptual. Sunt similare deoarece folosesc același tip de structură de prezentare (meta) date - copaci B („bi-copaci”).
Ca și în cazul oricărui sistem ierarhic, arborele B începe de la înregistrarea rădăcină și se ramifică până la elementele finale - înregistrări individuale despre fișiere și atributele lor, sau „frunze”. Scopul principal al creării unei astfel de structuri logice a fost de a accelera căutarea obiectelor sistemului de fișiere pe matrici dinamice mari - cum ar fi hard disk-uri de mai mulți terabyți sau matrici RAID chiar mai impresionante.
Arborii B necesită mult mai puține accesări pe disc decât alte tipuri de arbori B atunci când se efectuează aceleași operațiuni. Acest lucru se realizează datorită faptului că obiectele finale din arborii B sunt ierarhic situate la aceeași înălțime, iar viteza tuturor operațiunilor este doar proporțională cu înălțimea arborelui.
La fel ca alți copaci echilibrați, copacii B au aceeași lungime a drumului de la rădăcină la orice frunză. În loc să crească, se ramifică mai mult și cresc mai mult în lățime: toate punctele de ramificare din arborele B stochează multe referințe la obiectele copil, ceea ce le face ușor de găsit în mai puține apeluri. Un număr mare de indicatori reduce numărul celor mai lungi operații pe disc - poziționarea capului la citirea blocurilor arbitrare.
Conceptul de copaci B a fost formulat în anii șaptezeci și a suferit diverse îmbunătățiri de atunci. Este implementat într-o formă sau alta în NTFS, BFS, XFS, JFS, ReiserFS și multe DBMS. Toți sunt veri în ceea ce privește principiile de bază ale organizării datelor. Diferențele privesc detalii, care sunt adesea destul de importante. Dezavantajul sistemelor de fișiere conexe este, de asemenea, obișnuit: toate au fost create pentru a funcționa cu discuri chiar înainte de apariția SSD-urilor.
Unitățile în stare solidă înlocuiesc treptat unitățile de disc, dar până acum sunt forțate să folosească sisteme de fișiere care le sunt străine, moștenite. Acestea sunt construite pe matrici de memorie flash, ale căror principii diferă de cele ale dispozitivelor de disc. În special, memoria flash trebuie ștearsă înainte de scriere, iar această operațiune în cipurile NAND nu poate fi efectuată la nivelul celulelor individuale. Este posibil doar pentru blocurile mari ca întreg.
Această limitare se datorează faptului că în memoria NAND, toate celulele sunt combinate în blocuri, fiecare dintre acestea având o singură conexiune comună la magistrala de control. Nu vom intra în detaliile organizării de paginare și nu vom picta întreaga ierarhie. Însăși principiul operațiunilor de grup cu celule și faptul că dimensiunile blocurilor de memorie flash sunt de obicei mai mari decât blocurile adresate în orice sistem de fișiere sunt importante. Prin urmare, toate adresele și comenzile pentru unitățile cu bliț NAND trebuie traduse prin stratul de abstractizare FTL (Flash Translation Layer).
Controlerele de memorie flash oferă compatibilitate cu logica dispozitivelor de disc și suport pentru comenzile interfețelor lor native. De obicei, FTL este implementat în firmware-ul lor, dar poate (parțial) să ruleze pe gazdă - de exemplu, Plextor scrie drivere pentru SSD-urile sale care accelerează scrierea.
Nu puteți face deloc FTL, deoarece chiar scrierea unui bit într-o anumită celulă duce la lansarea unei serii întregi de operații: controlerul caută un bloc care conține celula necesară; blocul este citit integral, scris în memoria cache sau în spațiul liber, apoi șters complet, după care este rescris înapoi cu modificările necesare.
Această abordare seamănă cu viața de zi cu zi din armată: pentru a da un ordin unui soldat, sergentul face o formație generală, îl cheamă pe bietul om din ordin și poruncește celorlalți să se disperseze. În memoria rar acum NOR, organizația era spetsnaz: fiecare celulă era controlată independent (fiecare tranzistor avea un contact individual).
Controlerele au din ce în ce mai multe sarcini, deoarece cu fiecare generație de memorie flash, procesul tehnic de fabricație scade pentru a crește densitatea și a reduce costul stocării datelor. Împreună cu standardele tehnologice, durata de viață estimată a cipurilor este, de asemenea, redusă.
Modulele cu celule SLC cu un singur nivel au avut o resursă declarată de 100 de mii de cicluri de rescriere și chiar mai mult. Mulți dintre ei funcționează încă în unități flash vechi și carduri CF. MLC de clasă enterprise (eMLC) a revendicat resursa în intervalul de la 10 la 20 mii, în timp ce în MLC obișnuit la nivel de consumator este estimat la 3-5 mii. Memoria de acest tip este aglomerată activ de TLC și mai ieftin, a cărui resursă abia atinge o mie de cicluri. Menținerea duratei de viață a memoriei flash la un nivel acceptabil trebuie făcută prin modificări software, iar noile sisteme de fișiere devin unul dintre ele.
Inițial, producătorii au presupus că sistemul de fișiere nu era important. Controlerul în sine trebuie să mențină o serie de celule de memorie de scurtă durată de orice tip, distribuind sarcina între ele într-un mod optim. Pentru driverul sistemului de fișiere, acesta simulează un disc obișnuit și realizează optimizări la nivel scăzut pentru orice acces. Cu toate acestea, în practică, optimizarea variază de la magică la fictivă pentru diferite dispozitive.
În SSD-urile corporative, controlerul încorporat este un computer mic. Are un buffer de memorie imens (jumătate de concert și mai mult) și sprijină multe metode pentru a îmbunătăți eficiența de lucru cu date, ceea ce evită ciclurile de rescriere inutile. Cipul aranjează toate blocurile din cache, efectuează scrieri leneșe, efectuează deduplicarea din mers, rezervă unele blocuri și șterge altele în fundal. Toată această magie se întâmplă complet neobservată de SO, programe și utilizator. Cu un SSD ca acesta, nu contează ce sistem de fișiere este utilizat. Optimizările interne au un impact mult mai mare asupra performanței și resurselor decât cele externe.
SSD-urile bugetare (și cu atât mai mult - unitățile flash) sunt echipate cu controlere mult mai puțin inteligente. Cache-ul din ele este trunchiat sau absent, iar tehnologiile avansate de server nu sunt utilizate deloc. În cardurile de memorie, controlerele sunt atât de primitive încât se pretinde adesea că nu există deloc. Prin urmare, pentru dispozitivele ieftine cu memorie flash, metodele externe de echilibrare a sarcinii rămân relevante - folosind în principal sisteme de fișiere specializate.
Una dintre primele încercări de a scrie un sistem de fișiere care să ia în considerare principiile de organizare a memoriei flash a fost JFFS - Journaling Flash File System. Inițial, această dezvoltare a companiei suedeze Axis Communications a fost axată pe îmbunătățirea eficienței memoriei dispozitivelor de rețea pe care Axis le-a produs în anii nouăzeci. Prima versiune a JFFS a acceptat doar memoria NOR, dar deja în a doua versiune a devenit prieten cu NAND.
JFFS2 are o utilizare limitată chiar acum. În cea mai mare parte este încă utilizat în distribuțiile Linux pentru sistemele încorporate. Poate fi găsit în routere, camere IP, NAS și alte obișnuite de pe Internetul obiectelor. În general, oriunde este necesară o cantitate mică de memorie fiabilă.
Un alt efort de dezvoltare pentru JFFS2 a fost LogFS, care a stocat inodurile într-un fișier separat. Autorii acestei idei sunt un angajat al diviziei germane a IBM Jorn Engel și un profesor la Universitatea din Osnabrück Robert Mertens. Codul sursă pentru LogFS este disponibil pe GitHub. Judecând după faptul că ultima modificare a fost făcută acum patru ani, LogFS nu a câștigat popularitate.
Dar aceste încercări au stimulat apariția unui alt sistem de fișiere specializat - F2FS. A fost dezvoltat de Samsung Corporation, care reprezintă o mare parte din memoria flash produsă în lume. Samsung produce cipuri NAND Flash pentru propriile sale dispozitive și pentru alte companii și dezvoltă, de asemenea, SSD-uri cu interfețe fundamental noi, în loc de cele vechi pe disc. Crearea unui sistem de fișiere specializat optimizat pentru memoria flash a fost o necesitate demult așteptată din punctul de vedere al Samsung.
În urmă cu patru ani, în 2012, Samsung a creat F2FS (Flash Friendly File System). Ideea sa este bună, dar implementarea sa dovedit a fi umedă. Sarcina cheie la crearea F2FS a fost simplă: reducerea numărului de operații de rescriere a celulei și distribuirea sarcinii pe ele cât mai uniform posibil. Acest lucru necesită efectuarea de operații cu mai multe celule din același bloc în același timp și nu violarea lor una câte una. Aceasta înseamnă că nu avem nevoie de rescrierea instantanee a blocurilor existente la prima cerere a sistemului de operare, ci de stocarea în cache a comenzilor și a datelor, adăugarea de blocuri noi la spațiul liber și ștergerea întârziată a celulelor.
Astăzi, suportul F2FS este deja implementat oficial în Linux (și, prin urmare, în Android), dar nu oferă avantaje speciale în practică. Principala caracteristică a acestui sistem de fișiere (suprascrierea amânată) a condus la concluzii premature despre eficacitatea acestuia. Vechiul truc de cache a păcălit chiar versiunile timpurii ale benchmark-urilor, unde F2FS a prezentat un avantaj aparent nu cu câteva procente (așa cum era de așteptat) sau chiar de mai multe ori, ci cu ordine de mărime. Doar că driverul F2FS a raportat execuția unei operațiuni pe care controlerul tocmai plănuia să o facă. Cu toate acestea, dacă câștigul real de performanță în F2FS este mic, atunci uzura celulei va fi cu siguranță mai mică decât atunci când se utilizează același ext4. Acele optimizări pe care un controler ieftin nu le poate face vor fi realizate la nivelul sistemului de fișiere în sine.
În timp ce F2FS este perceput ca exotic pentru geeks. Chiar și propriile smartphone-uri Samsung încă folosesc ext4. Mulți consideră că este o dezvoltare ulterioară a ext3, dar acest lucru nu este pe deplin adevărat. Aceasta este mai mult o revoluție decât ruperea barierei de 2 TB per fișier și pur și simplu creșterea altor valori.
Când computerele erau mari și fișierele erau mici, adresarea era ușoară. Fiecare fișier a primit un anumit număr de blocuri, ale căror adrese au fost introduse în tabelul de corespondență. Așa a funcționat sistemul de fișiere ext3, care este încă în uz astăzi. Dar în ext4, a apărut un mod fundamental diferit de adresare - extinderi.
Extensiile pot fi considerate extensii inode ca seturi discrete de blocuri care sunt abordate în întregime ca secvențe contigue. O măsură poate conține un întreg fișier de dimensiuni medii, iar pentru fișierele mari, este suficient să alocați o duzină sau două extensii. Acest lucru este mult mai eficient decât abordarea a sute de mii de blocuri mici de patru kilobyți.
Mecanismul de scriere în sine s-a schimbat în ext4. Acum distribuția blocurilor are loc imediat într-o singură cerere. Și nu în avans, ci chiar înainte de a scrie date pe disc. Alocarea întârziată a mai multor blocuri vă permite să scăpați de operațiile inutile care au păcătuit ext3: în acesta, blocurile pentru un fișier nou au fost alocate imediat, chiar dacă acesta se potrivea complet în cache și era programat să fie șters ca temporar.
Pe lângă copacii echilibrați și modificările lor, există și alte structuri logice populare. Există sisteme de fișiere cu un tip de organizație fundamental diferit - de exemplu, liniar. Probabil că folosiți cel puțin unul dintre ele foarte mult.
Ghiciți ghicitoarea: la doisprezece ani a început să se îngrașă, la șaisprezece ani era o femeie grasă proastă, iar la treizeci și doi a devenit grasă și a rămas o simplă. Cine este ea?
Așa este, aceasta este o poveste despre sistemul de fișiere FAT. Cerințele de compatibilitate i-au asigurat o moștenire proastă. Pe dischete era de 12 biți, pe discuri - la început era de 16 biți și până în prezent a coborât pe 32 de biți. În fiecare versiune ulterioară, numărul de blocuri adresabile a crescut, dar în esență nimic nu s-a schimbat.
Încă popularul sistem de fișiere FAT32 a apărut acum douăzeci de ani. Astăzi este încă primitiv și nu acceptă ACL-uri, cote de disc, compresie de fundal sau alte tehnologii moderne de optimizare a datelor.
De ce este nevoie de FAT32 în aceste zile? Tot la fel numai în scopuri de compatibilitate. Producătorii cred pe bună dreptate că orice sistem de operare poate citi o partiție FAT32. Prin urmare, îl creează pe hard disk-uri externe, USB Flash și carduri de memorie.
Cardurile MicroSD (HC) utilizate în smartphone-uri sunt formatate în mod implicit la FAT32. Acesta este principalul obstacol în calea instalării aplicațiilor pe acestea și a transferului de date din memoria internă. Pentru a o depăși, trebuie să creați o partiție ext3 sau ext4 pe card. Toate atributele fișierului (inclusiv proprietarul și drepturile de acces) pot fi transferate către acesta, astfel încât orice aplicație poate funcționa ca și cum ar fi fost lansată din memoria internă.
Windows nu poate crea mai mult de o partiție pe unitățile flash, dar pentru aceasta puteți rula Linux (cel puțin într-o mașină virtuală) sau un utilitar avansat pentru lucrul cu partiționarea logică - de exemplu, MiniTool Partition Wizard Free. După ce ați găsit o partiție primară suplimentară cu ext3 / ext4 pe card, aplicația Link2SD și altele similare vor oferi mult mai multe opțiuni decât în cazul unei singure partiții FAT32.
Un alt argument în favoarea FAT32 este lipsa jurnalizării, ceea ce înseamnă operații de scriere mai rapide și o uzură mai mică a celulelor de memorie Flash NAND. În practică, utilizarea FAT32 duce la opus și dă naștere la multe alte probleme.
Unitățile flash și cardurile de memorie mor rapid, deoarece orice modificare a FAT32 determină suprascrierea acelorași sectoare în care se află două lanțuri de tabele de fișiere. Am salvat întreaga pagină web și a fost rescrisă de o sută de ori - cu fiecare adăugare a unui alt GIF mic pe unitatea flash. Ați lansat software-ul portabil? El a creat fișiere temporare și le schimbă constant în timpul lucrului. Prin urmare, este mult mai bine să utilizați NTFS pe unitățile flash cu tabelul său tolerant la defecte $ MFT. Fișierele mici pot fi stocate direct în tabelul de fișiere principal, iar extensiile și copiile sale sunt scrise în diferite zone ale memoriei flash. În plus, indexarea NTFS face căutările mai rapide.
O altă problemă cu care se confruntă majoritatea utilizatorilor este că este imposibil să scrieți un fișier mai mare de 4 GB pe o partiție FAT32. Motivul este că în FAT32 dimensiunea fișierului este descrisă de 32 de biți în tabelul de alocare a fișierelor, iar 2 ^ 32 (minus unul, mai precis) dă doar patru concerte. Se pare că nici un film în calitate normală, nici o imagine DVD nu pot fi înregistrate pe o unitate flash proaspăt cumpărată.
Copierea fișierelor mari reprezintă încă jumătate din probleme: atunci când încercați să faceți acest lucru, eroarea este cel puțin imediat vizibilă. În alte situații, FAT32 acționează ca o bombă cu ceas. De exemplu, ați copiat software portabil pe o unitate flash USB și la început îl puteți folosi fără probleme. După mult timp, unul dintre programe (de exemplu, contabilitate sau poștă) are o bază de date umflată și ... doar se oprește din actualizare. Fișierul nu poate fi suprascris deoarece a atins limita de 4 GB.
O problemă mai puțin evidentă este că în FAT32, data creării unui fișier sau director poate fi specificată cu o precizie de două secunde. Acest lucru nu este suficient pentru multe aplicații criptografice care utilizează marcaje de timp. Precizia redusă a atributului de dată este un alt motiv pentru care FAT32 nu este considerat un sistem complet de fișiere din punct de vedere al securității. Cu toate acestea, punctele slabe ale acestuia pot fi folosite în scopuri proprii. De exemplu, dacă copiați orice fișiere dintr-o partiție NTFS într-un volum FAT32, acestea vor fi șterse de toate metadatele, precum și de permisiunile moștenite și setate special. FAT pur și simplu nu le susține.
Spre deosebire de FAT12 / 16/32, exFAT a fost conceput special pentru USB Flash și carduri de memorie mari (≥ 32 GB). FAT extins elimină dezavantajul menționat mai sus al FAT32 - suprascriind aceleași sectoare la orice modificare. Ca sistem pe 64 de biți, practic nu are limite semnificative asupra dimensiunii unui singur fișier. Teoretic, poate avea o lungime de 2 ^ 64 octeți (16 EB), iar cărțile de această dimensiune nu vor apărea în curând.
O altă diferență majoră în exFAT este suportul pentru listele de control al accesului (ACL). Aceasta nu mai este atât de simplă din anii nouăzeci, dar formatul închis împiedică implementarea exFAT. Suportul ExFAT este implementat integral și legal numai în Windows (începând de la XP SP2) și OS X (începând cu 10.6.5). Pe Linux și * BSD, este acceptat fie cu restricții, fie nu în întregime din punct de vedere legal. Microsoft necesită licențiere pentru a utiliza exFAT și există numeroase litigii legale în acest domeniu.
Un alt exemplu important de sisteme de fișiere B-tree se numește Btrfs. Acest FS a apărut în 2007 și a fost creat inițial în Oracle cu scopul de a lucra cu SSD și RAID. De exemplu, poate fi scalat dinamic: creați noi inode pe sistemul live sau împărțiți un volum în subvolumuri fără a le aloca spațiu liber.
Mecanismul de copiere pe scriere implementat în Btrfs și integrarea completă cu modulul kernel Device mapper vă permit să realizați instantanee aproape instantanee prin dispozitive de blocare virtuală. Precomprimarea datelor (zlib sau lzo) și deduplicarea accelerează operațiunile de bază, prelungind în același timp durata de viață a memoriei flash. Acest lucru este remarcabil mai ales atunci când se lucrează cu baze de date (compresia se realizează de 2-4 ori) și fișiere mici (acestea sunt scrise în blocuri mari ordonate și pot fi stocate direct în „frunze”).
Btrfs acceptă, de asemenea, jurnalizarea completă (date și metadate), verificarea volumului fără demontare și multe alte caracteristici moderne. Codul Btrfs este publicat sub licența GPL. Acest sistem de fișiere a fost menținut ca stabil pe Linux de la kernel 4.3.1.
Aproape toate sistemele de fișiere mai mult sau mai puțin moderne (ext3 / ext4, NTFS, HFSX, Btrfs și altele) aparțin grupului general al celor jurnalizate, deoarece păstrează evidența modificărilor făcute într-un jurnal separat (jurnal) și verifică cu el în cazul în care de eșec în timpul operațiilor pe disc ... Cu toate acestea, nivelul verbozității și toleranței la erori ale acestor sisteme de fișiere este diferit.
Ext3 acceptă trei moduri de înregistrare: loopback, secvențiat și înregistrare completă. Primul mod implică înregistrarea doar a modificărilor generale (metadate), efectuate asincron în ceea ce privește modificările din datele în sine. În cel de-al doilea mod, se efectuează aceeași înregistrare a metadatelor, dar strict înainte de a face modificări. Al treilea mod este echivalent cu înregistrarea completă (modificări atât în metadate, cât și în fișiere).
Doar această din urmă opțiune asigură integritatea datelor. Celelalte două accelerează identificarea erorilor în timpul verificării și garantează restabilirea integrității sistemului de fișiere în sine, dar nu și a conținutului fișierelor.
Înregistrarea NTFS este similară celui de-al doilea mod de înregistrare ext3. Numai modificările metadatelor sunt înregistrate în jurnal, iar datele în sine pot fi pierdute în caz de eșec. Această metodă de jurnalizare NTFS nu a fost concepută ca o modalitate de a obține fiabilitate maximă, ci doar ca o compromis între performanță și toleranță la erori. Acesta este motivul pentru care oamenii obișnuiți să lucreze cu sisteme de jurnalizare completă consideră că NTFS este pseudo-jurnalizat.
Abordarea NTFS este oarecum mai bună decât cea implicită din ext3. În NTFS, punctele de control sunt create suplimentar periodic pentru a se asigura că toate operațiunile pe disc în așteptare anterior sunt finalizate. Punctele de control nu au nimic de-a face cu punctele de restaurare din \ System Volume Infromation \. Acestea sunt doar intrări generale din jurnal.
Practica arată că un astfel de jurnal parțial NTFS în cele mai multe cazuri este suficient pentru o funcționare fără probleme. La urma urmei, chiar și cu o întrerupere puternică a curentului, dispozitivele disc nu se dezactivează instantaneu. Unitatea de alimentare cu energie electrică și numeroși condensatori din acționări furnizează însăși rezerva minimă de energie, care este suficientă pentru a finaliza operația de scriere curentă. SSD-urile moderne, cu viteza și economia lor, au de obicei suficientă energie pentru a efectua operațiuni în așteptare. O încercare de a trece la jurnalizarea completă ar reduce viteza majorității operațiunilor de mai multe ori.
Utilizarea sistemelor de fișiere este limitată de suportul lor la nivelul sistemului de operare. De exemplu, Windows nu înțelege ext2 / 3/4 și HFS +, dar uneori trebuie să le folosiți. Acest lucru se poate face prin adăugarea driverului corespunzător.
Driver deschis pentru citirea și scrierea partițiilor ext2 / 3 cu suport ext4 parțial. Cea mai recentă versiune acceptă extensii și partiții de până la 16 TB. LVM, ACL-urile și atributele extinse nu sunt acceptate.
Există un plugin gratuit pentru Total Commander. Suportă citirea partițiilor ext2 / 3/4.
coLinux este un port open source și gratuit al kernel-ului Linux. Împreună cu un driver pe 32 de biți, vă permite să rulați Linux pe Windows 2000 până la 7 fără a utiliza tehnologii de virtualizare. Suportă doar versiunile pe 32 de biți. Dezvoltarea modificării pe 64 de biți a fost anulată. coLinux permite, printre altele, să organizeze accesul de la Windows la partițiile ext2 / 3/4. Sprijinul pentru proiect a fost suspendat în 2014.
Este posibil ca Windows 10 să aibă deja suport nativ pentru sistemele de fișiere specifice Linux, este doar ascuns. Aceste gânduri sunt sugerate de driverul de nivel kernel Lxcore.sys și de serviciul LxssManager, care este încărcat ca bibliotecă prin procesul Svchost.exe. Pentru mai multe detalii, consultați discuția lui Alex Ionescu „Kernel-ul Linux ascuns în Windows 10”, pe care a prezentat-o la Black Hat 2016.
ExtFS pentru Windows este un driver plătit lansat de Paragon. Funcționează pe Windows 7-10, acceptă accesul de citire / scriere la volumele ext2 / 3/4. Oferă suport ext4 aproape complet pe Windows.
HFS + pentru Windows 10 este un alt driver proprietar de la Paragon Software. În ciuda numelui, funcționează în toate versiunile de Windows începând de la XP. Oferă acces complet la sistemele de fișiere HFS + / HFSX de pe discuri cu orice partiție (MBR / GPT).
WinBtrfs este o dezvoltare timpurie a driverului Btrfs pentru Windows. Deja în versiunea 0.6, acceptă atât accesul la citire, cât și la scriere la volumele Btrfs. Poate gestiona legături dure și simbolice, acceptă fluxuri de date alternative, ACL, două tipuri de compresie și mod de citire / scriere asincron. Până în prezent, WinBtrfs nu poate utiliza mkfs.btrfs, btrfs-balance și alte utilități pentru a menține acest sistem de fișiere.
| Sistemul de fișiere | Mac-si-mal-ny volum-dimensiune | Pre-del-dimensiunea unui fișier | Lungimea după propriul nume de fișier | Lungimea numelui complet al fișierului (inclusiv calea de la rădăcină) | Pre-ștergere număr de fișiere și / sau cataloage | Precizia specificării datei fișierului / catalogului | Drepturi dos-tu-pa | Legături dure | Link-uri fără sim | Instantanee | Comprimarea datelor în fundal | Cifra-ro-va-tion de date în fundal | Bunic-pli-ka-tion de date |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| FAT16 | 2 GB în sectoare de 512 octeți sau 4 GB în clustere de 64 KB | 2 GB | 255 octeți cu LFN | - | - | - | - | - | - | - | - | - | - |
| FAT32 | 8 TB în sectoare de 2 KB | 4 GB (2 ^ 32 - 1 octet) | 255 octeți cu LFN | până la 32 de subdirectoare cu CDS | 65460 | 10ms (creați) / 2s (modificați) | Nu | Nu | Nu | Nu | Nu | Nu | Nu |
| exFAT | ≈ 128 PB (2 ^ 32-1 clustere de 2 ^ 25-1 octeți) teoretic / 512 TB din cauza limitărilor terților | 16 EB (2 ^ 64 - 1 octet) | 2796202 în catalog | 10 ms | ACL | Nu | Nu | Nu | Nu | Nu | Nu | ||
| NTFS | 256 TB în clustere de 64 KB sau 16 TB în clustere 4K | 16 TB (Win 7) / 256 TB (Win 8) | 255 caractere Unicode (UTF-16) | 32.760 de caractere Unicode, dar nu mai mult de 255 de caractere per element | 2^32-1 | 100 ns | ACL | da | da | da | da | da | da |
| HFS + | 8 EB (2 ^ 63 octeți) | 8 EB | 255 caractere Unicode (UTF-16) | nu se limitează separat | 2^32-1 | 1 sec | Unix, ACL | da | da | Nu | da | da | Nu |
| APFS | 8 EB (2 ^ 63 octeți) | 8 EB | 255 caractere Unicode (UTF-16) | nu se limitează separat | 2^63 | 1 ns | Unix, ACL | da | da | da | da | da | da |
| Ext3 | 32 TB (teoretic) / 16 TB în clustere 4K (datorită limitărilor programelor e2fs) | 2 TB (teoretic) / 16 GB pentru programele mai vechi | 255 caractere Unicode (UTF-16) | nu se limitează separat | - | 1 sec | Unix, ACL | da | da | Nu | Nu | Nu | Nu |
| Ext4 | 1 EB (teoretic) / 16 TB în clustere 4K (datorită limitărilor programelor e2fs) | 16 TB | 255 caractere Unicode (UTF-16) | nu se limitează separat | 4 miliarde | 1 ns | POSIX | da | da | Nu | Nu | da | Nu |
| F2FS | 16 TB | 3,94 TB | 255 octeți | nu se limitează separat | - | 1 ns | POSIX ACL | da | da | Nu | Nu | da | Nu |
| BTRFS | 16 EB (2 ^ 64 - 1 octet) | 16 EB | 255 caractere ASCII | 2 ^ 17 octeți | - | 1 ns | POSIX ACL | da | da | da | da | da | da |
L-am anunțat deja o dată pe blogul meu, apoi nu se știa nimic cu adevărat despre el, iar acum a venit timpul pentru o scurtă, dar mai consistentă cunoaștere a noului ReFS.
Cu toate acestea, totul are o limită, la fel și capacitățile sistemelor de fișiere. Astăzi, capacitățile NTFS au ajuns la limitele lor: verificarea mediilor mari de stocare durează prea mult, „Jurnalul” încetinește accesul, iar dimensiunea maximă a fișierului a fost aproape atinsă. Realizând acest lucru, Microsoft a implementat un nou sistem de fișiere în Windows 8 - ReFS (Resilient File System). ReFS este considerat a oferi cea mai bună protecție a datelor pentru hard disk-uri mari și rapide. Cu siguranță are și dezavantajele sale, dar înainte de începerea utilizării cu adevărat masive în Windows 8, este dificil să vorbim despre ele.
Deci, deocamdată, să încercăm să înțelegem caracteristicile interne și avantajele ReFS.
ReFS a fost inițial denumit în cod „Protogon”. Pentru prima dată am povestit despre ea publicului larg acum aproximativ un an Stephen Sinofsky- Președinte al Diviziei Windows de la Microsoft, responsabil cu dezvoltarea și comercializarea Windows și Internet Explorer.
El a spus în aceste cuvinte:
„NTFS este cel mai utilizat, avansat și bogat sistem de fișiere din prezent. Dar regândind Windows și dezvoltăm în prezent Windows 8, nu ne oprim aici. Prin urmare, împreună cu Windows 8, introducem și un sistem de fișiere complet nou. ReFS este construit pe partea de sus a NTFS, astfel încât să păstreze interoperabilitatea critică în timp ce este proiectat și proiectat pentru a satisface nevoile următoarei generații de tehnologii și scenarii de stocare.
În Windows 8, ReFS va fi introdus doar ca parte a Windows Server 8, aceeași abordare pe care am folosit-o pentru a implementa toate sistemele de fișiere anterioare. Desigur, la nivelul aplicației, clienților li se va oferi acces la datele ReFS în același mod ca și datele NTFS. Rețineți că NTFS este încă cea mai importantă tehnologie din industrie pentru sistemele de fișiere PC. ”
Într-adevăr, am văzut pentru prima dată ReFS în sistemul de operare server Windows Server 8. Noul sistem de fișiere nu a fost dezvoltat de la zero. De exemplu, ReFS folosește aceleași API ca NTFS pentru a deschide, închide, citi și scrie fișiere. De asemenea, multe caracteristici familiare au migrat din NTFS - de exemplu, criptarea discului Bitlockerși legături simbolice pentru biblioteci. Dar a dispărut, de exemplu, compresia datelorși o serie de alte funcții.
Principalele inovații în ReFS sunt axate pe crearea și gestionarea structurilor de fișiere și foldere. Sarcina lor este de a asigura remediere automată erori, scalare maximă și funcționare în modul întotdeauna online (Always Online).
Implementarea pe disc a structurilor ReFS este fundamental diferită de alte sisteme de fișiere Microsoft. Dezvoltatorii Microsoft și-au putut realiza ideile prin aplicarea conceptului de arborele B, care este bine cunoscut din bazele de date din ReFS. Dosarele din sistemul de fișiere sunt structurate ca tabele cu fișiere ca intrări. Acestea, la rândul lor, primesc anumite atribute adăugate ca sub-tabele, creând o structură arborescentă ierarhică. Chiar și spațiul liber pe disc este organizat în tabele.
Împreună cu numerotarea reală pe 64 de biți a tuturor elementelor sistemului, acest lucru elimină apariția „blocajelor” în timpul scalării sale ulterioare.
Ca rezultat, nucleul sistemului ReFS este tabelul cu obiecte - directorul central care listează toate tabelele din sistem. Există un avantaj important în această abordare: ReFS a abandonat gestionarea complexă a jurnalelor și angajează informații noi despre fișiere în spațiul liber - acest lucru împiedică suprascrierea acestuia.
« Catalog Frunze"Sunt intrări tastate. Există trei tipuri de bază de înregistrări pentru un obiect folder: descriptor director, înregistrare index și descriptor obiect imbricat. Toate aceste înregistrări sunt ambalate ca un arbore B ± separat cu un identificator de folder; rădăcina acestui copac este frunza B ± a arborelui „Catalog”, care permite împachetarea a aproape orice număr de înregistrări într-un folder. La nivelul inferior, în foile B ± ale arborelui folderelor, există în primul rând o înregistrare descriptor de director care conține date de bază despre folder (nume, „informații standard”, atribut nume fișier etc.).
Mai departe în catalog sunt plasate înregistrări index: structuri scurte care conțin informații despre elementele conținute în dosar. Aceste înregistrări sunt semnificativ mai scurte decât NTFS, ceea ce face ca volumul de metadate să fie mai puțin supraîncărcat.
La final sunt intrările din catalog. Pentru foldere, aceste elemente conțin numele pachetului, identificatorul folderului din „Catalog” și structura „informațiilor standard”. Pentru fișiere, nu există identificator - în schimb, structura conține toate datele de bază despre fișier, inclusiv rădăcina B ± a arborelui bloc al fișierului. În consecință, un fișier poate consta din aproape orice număr de fragmente.
La fel ca NTFS, ReFS face o distincție fundamentală între informațiile despre fișiere (metadate) și conținutul fișierului (datele utilizatorului). Cu toate acestea, funcțiile de protecție sunt oferite ambelor în același mod. Metadatele sunt protejate implicit cu sume de verificare - aceeași protecție (dacă se dorește) poate fi acordată datelor utilizatorului. Aceste sume de verificare sunt situate pe disc la o distanță sigură una de cealaltă - deci va fi mai ușor să recuperați datele în cazul unei erori.
Dimensiunea metadatelor unui sistem de fișiere gol este de aproximativ 0,1% din dimensiunea sistemului de fișiere în sine (adică aproximativ 2 GB pe 2 TB volum). Unele metadate de bază sunt duplicate pentru o mai bună rezistență la crash
Varianta ReFS pe care am văzut-o în Windows Server 8 Beta, acceptă doar clustere de date de 64 KB și clustere de metadate de 16 KB. Deocamdată, parametrul „Cluster Size” este ignorat la crearea unui volum ReFS și se presupune că este întotdeauna implicit. La formatarea sistemului de fișiere, 64 KB este, de asemenea, singura opțiune disponibilă pentru dimensiunea clusterului.
Recunoaștem că această dimensiune a clusterului este mai mult decât suficientă pentru a organiza sisteme de fișiere de orice dimensiune. Cu toate acestea, un efect secundar este o redundanță vizibilă în stocarea datelor (un fișier de 1 octet pe disc va ocupa un bloc complet de 64 KB).
În ceea ce privește arhitectura sistemului de fișiere, ReFS are toate instrumentele de care aveți nevoie pentru a recupera fișiere în condiții de siguranță chiar și după o eroare hardware majoră. Principalul dezavantaj al sistemului jurnal în sistemul de fișiere NTFS și altele asemenea este că actualizarea discului poate deteriora metadatele înregistrate anterior în cazul unei întreruperi a curentului în timpul înregistrării - acest efect a primit deja un nume stabil: așa-numitul. " înregistrare suspendată».
A preveni recorduri atârnate, Microsoft a adoptat o nouă abordare în care părțile structurilor de metadate conțin propriile lor identificatori, ceea ce vă permite să verificați proprietatea asupra structurilor; linkurile de metadate conțin sumele de verificare pe 64 de biți ale blocurilor la care se face referire.
Orice modificare a structurii metadatelor are loc în două etape. În primul rând, o nouă copie (modificată) a metadatelor este creată în spațiul liber pe disc și numai după aceea, dacă are succes, operația de actualizare atomică transferă legătura din vechea (neschimbată) în zona nouă (modificată) de metadate. Aici, elimină necesitatea înregistrării prin păstrarea automată a integrității datelor.
Cu toate acestea, schema descrisă nu se aplică datelor utilizatorului, astfel încât orice modificare a conținutului fișierului este scrisă direct în fișier. Fișierul este șters prin reconstruirea structurii metadatelor, care salvează versiunea anterioară a blocului de metadate pe disc. Această abordare vă permite să recuperați fișierele șterse până când acestea sunt suprascrise cu date noi de utilizator.
Un subiect separat este toleranța la erori ReFS în caz de deteriorare a discului. Sistemul este capabil să identifice toate formele de deteriorare a discului, inclusiv cele pierdute sau stocate în locul greșit de înregistrare, precum și așa-numitul. pic de descompunere(degradarea datelor de pe mass-media)
Când opțiunea „Fluxuri integrale” este activată, ReFS verifică și conținutul fișierelor în comparație cu sumele de verificare și scrie întotdeauna modificări la fișiere într-o locație terță parte. Aceasta oferă asigurarea că datele preexistente nu se vor pierde atunci când sunt suprascrise. Sumele de verificare sunt actualizate automat atunci când datele sunt scrise, deci dacă scrierea eșuează, utilizatorul va avea o versiune a fișierului de verificat.
Un alt subiect interesant despre securitatea ReFS este interacțiunea cu Spații de depozitare... ReFS și Spații de depozitare concepute pentru a se completa reciproc ca două componente ale unui singur sistem de stocare. Pe lângă îmbunătățirea performanței Spații de depozitare protejați datele de defecțiunile parțiale și complete ale discului, stocând copii pe mai multe discuri. În timpul eșecurilor de citire Spații de depozitare poate citi copii și, în caz de eșecuri de scriere (chiar și cu pierderea completă a datelor media în timpul citirii / scrierii), este posibilă redistribuirea „transparentă” a datelor. După cum arată practica, cel mai adesea un astfel de eșec nu are nimic de-a face cu suportul - apare din cauza corupției datelor sau din cauza pierderii sau stocării datelor într-un loc greșit.
Acestea sunt tipurile de eșecuri pe care ReFS le poate detecta folosind sumele de verificare. După detectarea unei defecțiuni, ReFS comunică cu Spații de depozitare pentru a citi toate copiile posibile ale datelor și selectează copia corectă pe baza verificării sumelor de control. Sistemul dă apoi Spații de depozitare comanda de recuperare a copiilor deteriorate pe baza copiilor adevărate. Toate acestea se întâmplă în mod transparent din punct de vedere aplicat.
După cum se menționează pe site-ul Microsoft pentru Windows Server 8, sumele de verificare sunt întotdeauna activate pentru metadatele ReFS și presupunând că volumul este oglindit Spații de depozitare, corectarea automată este, de asemenea, activată. Toate fluxurile coerente sunt protejate în același mod. Acest lucru creează o soluție end-to-end cu un grad ridicat de integritate pentru utilizator, prin care stocarea relativ nesigură poate fi făcută extrem de fiabilă.
Fluxurile de integritate menționate protejează conținutul fișierului de toate tipurile de corupție a datelor. Cu toate acestea, această caracteristică este inaplicabilă în unele cazuri.
De exemplu, unele aplicații preferă gestionarea corectă a stocării fișierelor cu un fel de sortare a fișierelor pe disc. Deoarece fluxurile coerente redistribuie blocurile de fiecare dată când conținutul unui fișier se modifică, aspectul fișierelor este prea imprevizibil pentru aceste aplicații. Sistemele de baze de date sunt un prim exemplu în acest sens. De regulă, astfel de aplicații urmăresc în mod independent sumele de control ale conținutului fișierelor și au capacitatea de a verifica și corecta datele prin interacțiunea directă cu API-urile.
Cum funcționează ReFS în caz de corupție a discului sau eșec de stocare, cred că este clar. Poate fi mai dificil să identifici și să depășești pierderile de date asociate cu „ pic de descompunere„Când deteriorarea nedetectată a părților citite rareori a discului începe să crească rapid. Până la citirea și detectarea acestor daune, este posibil să fi afectat deja copiile sau datele pot fi pierdute din cauza altor defecțiuni.
Pentru a depăși procesul pic de descompunere, Microsoft a adăugat o activitate de sistem de fundal care curăță periodic metadatele și datele din fluxuri consistente pe un volum ReFS în spațiul de stocare în oglindă. Curățarea se face citind toate copiile redundante și verificând corectitudinea utilizând sumele de verificare ReFS. Dacă sumele de verificare nu se potrivesc, copiile eronate sunt corectate cu copii bune.
Rămâne o amenințare care poate fi numită în mod convențional „coșmarul administratorului”. Există cazuri, deși rare, când chiar și un volum din spațiul oglindit poate fi deteriorat. De exemplu, memoria unui sistem defect poate corupe datele care pot ajunge apoi pe disc și pot deteriora copiile redundante. În plus, mulți utilizatori pot decide să nu folosească spații de stocare oglindite pentru ReFS.
Pentru astfel de cazuri, când volumul se deteriorează, ReFS efectuează „reparații” - o funcție care elimină datele din spațiul de nume de pe volumul de lucru. Misiunea sa este de a preveni daunele ireparabile care ar putea afecta disponibilitatea datelor corecte. De exemplu, dacă un singur fișier dintr-un director este deteriorat și nu poate fi reparat automat, ReFS va elimina acel fișier din spațiul de nume al sistemului de fișiere, restabilind restul volumului.
Suntem obișnuiți cu faptul că sistemul de fișiere nu poate deschide sau șterge un fișier deteriorat, iar administratorul nu poate face nimic în acest sens.
Dar, din moment ce ReFS poate recupera datele corupte, administratorul poate restaura acest fișier dintr-o copie de rezervă sau poate utiliza aplicația pentru a-l recrea, evitând necesitatea închiderii sistemului. Aceasta înseamnă că utilizatorul sau administratorul nu va mai avea nevoie să efectueze procedura de verificare și reparare offline. Pentru servere, acest lucru face posibilă implementarea unor volume mari de date, fără riscul unei durate mari de viață a bateriei din cauza deteriorării.
Desigur, caracterul practic și comoditatea (sau calitățile opuse) ale ReFS pot fi judecate numai după ce computerele cu Windows 8 se răspândesc și după cel puțin șase luni de lucru activ cu acestea. Între timp, potențialii utilizatori G8 au mai multe întrebări decât răspunsuri.
De exemplu, acest lucru: va fi posibil în Windows 8 să convertiți cu ușurință și simplu datele din NTFS în ReFS și invers? Microsoft spune că nu este așteptată nicio funcție de conversie a formatului încorporat, dar informațiile pot fi copiate în continuare. Domeniul de aplicare al ReFS este evident: la început, poate fi folosit doar ca un mare manager de date pentru server (de fapt, este deja utilizat). Nu vor exista încă unități externe cu ReFS - doar cele interne. Evident, în timp, ReFS va fi echipat cu mai multe funcții și va putea înlocui sistemul vechi.
Microsoft spune că cel mai probabil acest lucru se va întâmpla odată cu lansarea primului service pack pentru Windows 8.
Microsoft susține, de asemenea, că a testat ReFS:
„Folosind o suită complexă și extinsă de zeci de mii de teste scrise pentru NTFS de mai bine de două decenii. Aceste teste recreează condițiile de implementare sofisticate pe care credem că le-ar putea întâlni sistemul, cum ar fi în timpul unei întreruperi de curent, cu probleme asociate adesea cu scalabilitatea și performanța. Prin urmare, putem spune că sistemul ReFS este gata pentru o implementare de testare într-un mediu controlat. "
În același timp, totuși, dezvoltatorii recunosc că, ca prima versiune a unui sistem de fișiere mare, ReFS va avea probabil nevoie de precauție în manipularea:
„Nu caracterizăm ReFS pentru Windows 8 ca o versiune beta. Noul sistem de fișiere va fi gata de lansare când Windows 8 va ieși din beta, deoarece nimic nu este mai important decât fiabilitatea datelor. Deci, spre deosebire de orice alt aspect al sistemului, acest lucru necesită o abordare conservatoare a utilizării și testării inițiale. "
Din multe puncte de vedere, din acest motiv ReFS va fi introdus în utilizare conform unui plan pe etape. Mai întâi ca sistem de stocare pentru Windows Server, apoi ca stocare pentru utilizatori și, în final, ca volum de încărcare. Cu toate acestea, o „abordare prudentă” similară a fost folosită în trecut la lansarea de noi sisteme de fișiere.
În acest articol, ne vom da seama ce caracteristici oferă ReFS și cum este mai bun decât sistemul de fișiere NTFS... Cum se recuperează date din spațiul pe disc ReFS. Noul sistem de fișiere ReFS de la Microsoft a fost introdus inițial în Windows Server 2012. Este inclus și în Windows 10 ca parte a instrumentului Spațiu pe disc. ReFS poate fi utilizat pentru un grup de unități. Odată cu lansarea Windows Server 2016, sistemul de fișiere a fost îmbunătățit și va fi disponibil în curând în noua versiune de Windows 10.
Ce caracteristici oferă ReFS și cum este mai bine decât sistemul NTFS actual?
Conţinut:Abreviere pentru Sistem de fișiere rezistent ReFS este un sistem nou bazat pe NTFS. În această etapă, ReFS nu oferă o înlocuire cuprinzătoare pentru NTFS pentru utilizatorii casnici. Sistemul de fișiere are avantajele și dezavantajele sale.
ReFS este conceput pentru a rezolva problemele de bază NTFS. Este mai rezistent la corupția datelor, gestionează mai bine volumul de muncă crescut și se adaptează cu ușurință la sisteme de fișiere foarte mari. Să vedem ce înseamnă asta?
Sistemul de fișiere utilizează sumele de verificare pentru metadate și poate utiliza, de asemenea, sumele de verificare pentru datele fișierelor. La citirea sau scrierea unui fișier, sistemul verifică suma de verificare pentru a se asigura că este corectă. Astfel, se efectuează detectarea datelor corupte în timp real.
ReFS este integrat cu caracteristica Disk Space. Dacă ați configurat un magazin de date în oglindă, Windows folosește ReFS pentru a detecta și repara automat corupția sistemului de fișiere prin copierea datelor de pe altă unitate. Această caracteristică este disponibilă atât în Windows 10, cât și în Windows 8.1.
Dacă sistemul de fișiere detectează datele deteriorate care nu au o copie alternativă pentru recuperare, atunci ReFS va șterge imediat aceste date de pe disc. Acest lucru nu necesită repornirea sistemului sau deconectarea dispozitivului de stocare, așa cum este cazul NTFS.
Necesitatea de a utiliza utilitarul chkdsk dispare complet, deoarece sistemul de fișiere este corectat automat imediat în momentul erorii. Sistem nou rezistent la alte tipuri de corupție a datelor. NTFS scrie metadatele fișierului direct la scrierea metadatelor fișierului. Dacă are loc o întrerupere a curentului electric sau un accident de computer în acest timp, veți primi corupția datelor.
Când se modifică metadatele, ReFS creează o nouă copie a datelor și asociază datele cu fișierul numai după ce metadatele sunt scrise pe disc. Acest lucru elimină posibilitatea corupției datelor. Această caracteristică se numește copiere-scriere și este prezentă în alte sisteme de operare Linux populare: ZFS, BtrFS și sistemul de fișiere APFS de la Apple.
ReFS este mai modern și acceptă volume mult mai mari și nume de fișiere mai lungi decât NTFS. Pe termen lung, acestea sunt îmbunătățiri importante. În NTFS, numele fișierului este limitat la 255 de caractere, în ReFS, numele fișierului poate avea până la 32768 caractere. Windows 10 vă permite să dezactivați limita limită de caractere pentru sistemele de fișiere NTFS, dar este întotdeauna dezactivată pe volumele ReFS.
ReFS nu mai acceptă nume scurte de fișiere în format DOS 8.3. Pe un volum NTFS, puteți accesa C: \ Fișiere de program \ v C: \ PROGRA ~ 1 \ pentru a asigura compatibilitatea cu software-ul vechi.
NTFS are o dimensiune teoretică maximă de 16 exabytes, în timp ce ReFS are o dimensiune teoretică maximă de 262.144 exabytes. Deși nu prea contează acum, computerele evoluează constant.
ReFS nu a fost conceput pentru a îmbunătăți performanța sistemului de fișiere față de NTFS. Microsoft a făcut ReFS mult mai eficient în cazuri foarte specifice.
De exemplu, atunci când este utilizat cu spațiul pe disc, ReFS acceptă „optimizarea în timp real”. Să presupunem că aveți un pool de stocare cu două discuri, unul pentru performanțe maxime și celălalt pentru capacitate. ReFS va scrie întotdeauna date pe discul mai rapid pentru o performanță maximă. În fundal, sistemul de fișiere va muta automat bucăți mari de date pe discuri mai lente pentru stocare pe termen lung.
În Windows Server 2016, Microsoft a îmbunătățit ReFS pentru a oferi performanțe mai bune pentru funcțiile mașinii virtuale. Mașina virtuală Microsoft Hyper-V profită de aceste avantaje (în teorie, orice mașină virtuală poate profita de ReFS).
De exemplu, ReFS acceptă clonarea în blocuri, care accelerează procesul de clonare a mașinilor virtuale și fuzionează punctele de control. Pentru a crea o copie a mașinii virtuale, ReFS trebuie doar să scrie noile metadate pe disc și să furnizeze un link către datele existente. Acest lucru se datorează faptului că în ReFS, mai multe fișiere pot indica aceleași date subiacente pe disc.
Când mașina virtuală scrie date noi pe disc, acestea sunt scrise într-o altă locație, iar datele originale ale mașinii virtuale rămân pe disc. Acest lucru accelerează foarte mult procesul de clonare și necesită o lățime de bandă mult mai redusă.
ReFS oferă, de asemenea, o nouă funcție „VDL rar” ceea ce permite ReFS să scrie rapid zerouri într-un fișier mare. Acest lucru accelerează semnificativ crearea unui fișier nou, gol, cu dimensiune fixă virtuală (VHD). Pe NTFS această operațiune poate dura 10 minute, pe ReFS poate dura câteva secunde.
În ciuda mai multor avantaje, ReFS nu poate înlocui încă NTFS. Windows nu poate porni de pe partiția ReFS și necesită NTFS. ReFS nu acceptă funcții NTFS, cum ar fi compresia de date, criptarea sistemului de fișiere, legăturile dure, atributele extinse, deduplicarea datelor și cotele de disc. Dar, spre deosebire de NTFS, ReFS permite criptarea completă a unității cu BitLocker, inclusiv structurile de unitate ale sistemului.
Windows 10 nu permite formatarea unei partiții cu ReFS, acest sistem de fișiere este disponibil numai în spațiul pe disc. ReFS protejează datele utilizate pe grupurile de hard disk-uri multiple de daune. În Windows Server 2016, puteți formata volume folosind ReFS în loc de NTFS. Un astfel de volum poate fi folosit pentru a stoca mașini virtuale, dar sistemul de operare poate porni doar numai din NTFS.
Hetman Partition Recovery vă permite să analizați spațiul pe disc gestionat de sistemul de fișiere ReFS utilizând un algoritm de analiză a semnăturii. Analizând dispozitivul sector cu sector, programul găsește secvențe specifice de octeți și le afișează utilizatorului. Recuperarea datelor din spațiul pe disc ReFS nu diferă de lucrul cu sistemul de fișiere NTFS:
Viitorul noului sistem de fișiere este destul de tulbure. Microsoft poate finaliza ReFS pentru a înlocui NTFS învechit în toate versiunile de Windows. În prezent, ReFS nu poate fi utilizat universal și servește doar pentru anumite sarcini.
Dacă ați instalat deja și ați lucrat cu noi sisteme de operare de la Microsoft: Windows Server 2012 și Windows 8, probabil că ați observat deja că acum pot fi formatate volume noi în sistemul de fișiere ReFS. Ce este un sistem de fișiere ReFS? ReFS înseamnă Sistem de fișiere rezistent, adică în limba rusă „Sistem de fișiere tolerant la erori”.
Microsoft vede sistemul de fișiere ReFS ca succesor al celui mai popular sistem de fișiere din acest moment, NTFS, ale cărui capacități tehnologice au ajuns deja la limitele lor. În special, atunci când lucrați cu medii de stocare mari, există dificultăți în activitatea lor: aceasta este prea lungă atunci când efectuați operația de verificare a erorilor și funcționarea lentă a jurnalului și atingerea limitei de dimensiune maximă a fișierului pe sistemul de fișiere NTFS. .
Majoritatea inovațiilor ReFS constau în crearea și gestionarea structurilor de fișiere și foldere. Aceste caracteristici sunt implementate pentru corectarea automată a erorilor, scalabilitate ridicată și funcționare Always Online. Dosarele din sistemul de fișiere ReFS sunt structurate ca tabele cu fișiere ca înregistrări, care, la rândul lor, pot avea propriile atribute, organizate sub-tabele, implementând structura arborescentă ierarhică B + familiară din bazele de date. Spațiul liber pe disc este, de asemenea, organizat în tabele.
La dezvoltarea ReFS, au fost urmărite următoarele obiective:
Caracteristici cheie ale ReFS
Limitări ale sistemului de fișiere ReFS
ReFS moștenește multe dintre caracteristicile și semantica predecesorului său, NTFS, inclusiv:
Toate datele din sistemul de fișiere ReFS vor fi accesibile prin aceleași API-uri care sunt utilizate în prezent pentru a accesa partițiile NTFS.
ReFS a renunțat la următoarele caracteristici NTFS:
Suportul ReFS a fost introdus în Windows 8 și Windows Server 2012 și numai pentru volumele de date. Adică, partițiile ReFS nu pot fi utilizate pentru a instala și porni de pe un sistem de operare. În timp, ReFS va fi echipat cu mai multe caracteristici și va putea înlocui complet sistemul NTFS învechit. Este posibil ca toate funcțiile noi să apară în primul Service Pack pentru Windows 8.
În plus, ReFS nu poate fi încă utilizat pentru dispozitive de stocare detașabile și portabile (ReFS este utilizat în prezent doar pentru suporturi interne).
Punctul frustrant este că volumele NTFS existente nu pot fi convertite în ReFS din mers. Datele vor trebui transferate prin copiere obișnuită.
Volumul poate fi formatat la sistemul de fișiere ReFS prin consola de gestionare a discurilor. Dar Opțiuni suplimentare de exemplu, activarea verificării coerenței poate fi activată numai din linia de comandă.
De exemplu, puteți activa verificarea coerenței ReFS cu comanda:
Format / fs: refs / q / i: activate
Dezactivați verificarea coerenței.
