Нова файлова система ReFS від Microsoft спочатку з'явилася на серверах під управлінням Windows 2012. І тільки пізніше вона була включена в Windows 10, де може бути використана тільки як частина функції Storage Spaces (технологія віртуалізації дискового простору) пулу дисків. У Windows Server 2016 Microsoft обіцяють значно поліпшити роботу з файловою системою ReFS, до того ж, по потрапляють чутками в друк, ReFS може прийти на заміну застарілої файлової системи NTFS в новій версії Windows 10, яка гордо носить назву Windows 10 Pro (для просунутих ПК ).
Але що ж насправді являє собою ReFs, чим вона відрізняється від нині файлової системи NTFS і які плюси вона в собі несе
Якщо коротко, то вона розроблялася, як відмовостійка файлова система. ReFS - це нова файлова система, створена з використанням коду і по суті є переробленою і поліпшеною файлової системою NTFS. До них відносяться поліпшена надійність зберігання інформації, стабільна робота в стрес режимах, розміри файлів, томів, каталогів, кількість файлів в томах і каталогах обмежена лише величиною знаків 64-бітного числа. Нагадаємо, що максимально при такій величині максимальний розмір файлу буде дорівнює 16 ексбібайт, а розмір томи 1 йобібайт.
На поточний момент ReFS - не заміна NTFS. Вона має свої переваги і недоліки. Але ви не зможете, скажімо, відформатувати диск і встановити на нього свіжу копію Windows так як би ви зробили це на NTFS.
ReFS використовує контрольні суми для метаданих, а також може використовувати контрольні суми для файлів даних. Кожен раз, коли ви читаєте або записуєте файли, ReFS перевіряє контрольну суму, щоб переконатися в її правильності. Це означає, що сама файлова система має інструмент, здатний виявляти спотворені дані на льоту.
ReFS інтегрована з функцією Storage Spaces. Якщо ви налаштували віддзеркалення за підтримкою ReFS, Windows легко виявить пошкодження файлової системи і автоматично усуне, скопіювавши отзеркалірованние дані на пошкоджений диск. Ця функція доступна як для Windows 10, так і для Windows 8.1.
У разі якщо ReFS виявляє пошкоджені дані, а необхідної копії даних для відновлення немає, файлова система в змозі відразу ж видалити пошкоджені дані з диска. Для цього не потрібно перезавантаження системи на відміну від NTFS.
ReFS не тільки перевіряє цілісність файлів під час запісічтенія. Вона автоматично сканує цілісність даних, регулярно перевіряючи всі файли на диску, ідентифікуючи і виправляючи пошкоджені дані. У такому випадку відпадає необхідність періодично запускати команду chkdsk для перевірки диска.
Нова файлова систем також стійка при пошкодженні даних іншими способами. Наприклад, ви оновлюєте метадані файлу (нехай ім'я файлу). Файлова система NTFS безпосередньо змінити метадані файлу. Якщо в цей час відбудеться збій системи (відключитися харчування) велика ймовірність, що файл буде пошкоджений. Коли ви змінюєте метадані, файлова система ReFS створює нову копію метаданих. Файлова система не перезаписує старі метадані, а записує їх в новий блок. При цьому виключається можливість пошкодження файлу. Така стратегія називається "copy-on-write" (копіювання при записі, виділення під час запису). Дана стратегія доступна в інших сучасних файлових системах, таких як ZFS і BtrFS в Linux, а також в новій файлової системи Apple APFS.
ReFS сучасніша, ніж NTFS і підтримує набагато більші обсяги даних і довші імена файлів. У довгостроковій перспективі це дуже важливо.
У файлової системи NTFS шлях до файлу обмежений 255 символами. У ReFS максимальну кількість символів становить вже значні 32768 символів. В даний час в Windows 10 існує можливість відключити символьний елемент для NTFS. На дискових томах ReFS такий ліміт за замовчуванням відключений.
ReFS не підтримує імена файлів у форматі DOS 8.3. На томах NTFS вам доступні папки "CProgram Files", "CProgra`1". Вони потрібні для сумісності зі старим програмним забезпеченням. У ReFS ви не знайдете звичних нам папок. Вони віддалені.
Теоретичний максимальний обсяг даних, підтримуваний NTFS - 16 ексабайт, ReFS підтримує до 262144 ексабайт. Зараз така цифра здається просто величезною.
Розробники не ставили за мету створити більш продуктивну файлову систему. Вони зробили більш оптимізовану систему.
Наприклад, при використанні з масивом, ReFS підтримує оптимізацію рівнів в режимі реального часу. У вас зібраний пул з накопичувачів, що складається з двох дисків. Перший диск підібраний з розрахунком на високу швидкість роботи, швидкий доступдо даних. Другий диск підібраний з критерієм надійності, під довгострокове зберігання даних. У фоновому режимі ReFS автоматично перемістить великі шматки даних на більш повільний диск, забезпечивши тим самим надійність збереження даних.
У Windows Server 2016 розробники додали інструмент, що забезпечує підвищення продуктивності за допомогою певних функцій віртуальних машин. Наприклад, ReFS підтримує копіювання блоків, що прискорює процес копіювання віртуальних машин і операцій злиття контрольних точок. Щоб створити копію віртуальної машини, ReFS створює нову копію метаданих на диску і вказує посилання на скопійовані дані на диску. Це зроблено для того, щоб за допомогою ReFS кілька файлів могли посилатися на одні й ті ж базові дані на диску. Після того, як ви, попрацювавши з віртуальною машиною, змініть дані вони записуються на диск в інше місце, а вихідні дані віртуальної машини залишаються на диску. Це значно прискорює процес створення копій і зменшує навантаження на диск.
ReFS підтримує "Sparse VDL" (виряджені файли). Розряджений файл - це файл, в якому послідовність нульових байтів замінена інформацією про цю послідовності (список дірок). Дірки - певна послідовність нульових байт всередині файлу, чи не записаних на диск. Сама інформація про дірки зберігається в метаданих файлової системи.
Технологія підтримки виряджених файлів дозволяє швидко записувати нулі в великий файл. Це значно прискорює процес створення нового, порожнього файлу віртуального жорсткого диска фіксованого розміру (VHD). Створення такого файлу в ReFS займає кілька секунд, тоді як в NTFS подібна операція займає до 10 хвилин.
Все, що ми описали вище звучить непогано, але ви не зможете перемкнутися на ReFS з NTFS. Windows не може завантажитися з файлової системи ReFS, вимагаючи при цьому NTFS.
У ReFS відсутні багато технологій, доступні в NTFS. Наприклад, стиснення і шифрування файлової системи, жорсткі посилання, розширені атрибути, Дедуплікація даних і дискові квоти. При цьому на відміну від NTFS ReFS підтримує технологію повного шифрування даних - BitLocker.
У Windows 10 ви не зможете відформатувати розділ диска з ReFS. Нова файлова система доступна тільки для систем зберігання, де її основна функція захистити дані від пошкодження. У Windows Server 2016 ви зможете відформатувати розділ диска в ReFS. Ви зможете використовувати його для запуску віртуальних машин. Але ви не зможете вибрати його у вигляді завантажувального диска. Windows завантажується тільки з файлової системи NTFS.
Незрозуміло, яке майбутнє Microsoft підготувала нової файлової системи. Можливо, в один прекрасний момент вона повністю замінить NTFS у всіх версіях Windows. Але на даний момент ReFS можна використовувати тільки для певних завдань.
Вище було багато сказано в підтримку нової операційної системи. Описано мінуси і плюси. Пропоную зупинитися і підвести підсумок. Для яких же цілей можна, а може і потрібно використовувати ReFS.
У Windows 10 ReFS застосуємо тільки в сукупності з компонентом Storage Spaces. Обов'язково відформатуйте свій диск, виділений під зберігання даних в ReFS, а не NTFS. У такому випадку ви зможете в повній мірі оцінити надійність зберігання даних.
У Windows Server ви зможете відформатувати розділ під ReFS за допомогою стандартного інструменту Windows в консолі управління дисками. Рекомендується обов'язково відформатувати під ReFS, якщо ви використовуєте віртуальні сервера. Але пам'ятайте, що завантажувальний диск повинен бути відформатований під NTFS. Завантаження з-під файлової системи ReFS не підтримує операційними системами Windows.
Нова файлова система ReFS і Windows 10| 2017-06-28 6:34:15 | Super User | Системне ПО | https: //сайт/media/system/images/new.png | Нова файлова система від Microsoft ReFS прийшла на заміну застарілої NTFS.Какіе плюси ReFS несе в собі і чим вона відрізняється від NTFS | refs, refs або ntfs, refs windows 10, refs файлова система, нові файлові системи, система ntfs, файлова система ntfs
Чому смартфон може не запускати програми з карти пам'яті? Чим ext4 принципово відрізняється від ext3? Чому флешка проживе довше, якщо відформатувати її в NTFS, а не в FAT? У чому головна проблема F2FS? Відповіді криються в особливостях будови файлових систем. Про них ми і поговоримо.
Файлові системи визначають спосіб зберігання даних. Від них залежить, з якими обмеженнями зіткнеться користувач, наскільки швидкими будуть операції читання і запису і як довго накопичувач пропрацює без збоїв. Особливо це стосується бюджетних SSD і їхніх молодших братів - флешок. Знаючи ці особливості, можна вичавити з будь-якої системи максимум і оптимізувати її використання для конкретних завдань.
Вибирати тип і параметри файлової системи доводиться всякий раз, коли треба зробити щось нетривіальне. Наприклад, потрібно прискорити найбільш часті файлові операції. На рівні файлової системи цього можна досягти різними способами: індексування забезпечить швидкий пошук, а попереднє резервування вільних блоків дозволить спростити перезапис часто змінюються файлів. Попередня оптимізація даних в оперативної пам'ятізнизить кількість необхідних операцій введення-виведення.
Збільшити термін безвідмовної експлуатації допомагають такі властивості сучасних файлових систем, як відкладений запис, дедуплікація і інші просунуті алгоритми. Особливо актуальні вони для дешевих SSD з чіпами пам'яті TLC, флешок і карт пам'яті.
Окремі оптимізації існують для дискових масивів різних рівнів: наприклад, файлова система може підтримувати спрощене віддзеркалення томи, миттєве створення знімків або динамічне масштабування без відключення томи.
Користувачі в основному працюють з тією файлової системою, яка пропонується за замовчуванням операційною системою. Вони рідко створюють нові дискові розділи і ще рідше замислюються про їх налаштування - просто використовують рекомендовані параметри або взагалі купують попередньо відформатовані носії.
У шанувальників Windows все просто: NTFS на всіх дискових розділах і FAT32 (або та ж NTFS) на флешках. Якщо ж стоїть NAS і в ньому використовується якась інша файлова система, то для більшості це залишається за гранню сприйняття. До нього просто підключаються по мережі і качають файли, як з чорного ящика.
На мобільних гаджетах з Android найчастіше зустрічається ext4 у внутрішній пам'яті та FAT32 на картках microSD. Яблучникам ж і зовсім без різниці, що у них за файлова система: HFS +, HFSX, APFS, WTFS ... для них існують тільки красиві значки папок і файлів, намальовані кращими дизайнерами. Найбагатше вибір у линуксоидов, але прикрутити підтримку нерідних для операційки файлових систем можна і в Windows, і в macOS - про це трохи пізніше.
Різних файлових систем створено понад сотні, але актуальними можна назвати трохи більше десятка. Хоча всі вони розроблялися для своїх специфічних застосувань, багато в підсумку виявилися спорідненими на концептуальному рівні. Вони схожі, оскільки використовують однотипну структуру уявлення (мета) даних - B-дерева ( «бі-дерева»).
Як і будь-яка ієрархічна система, B-дерево починається з кореневої запису і далі розгалужується аж до кінцевих елементів - окремих записів про файлах і їх атрибутах, або «листя». Основний сенс створення такої логічної структури був в тому, щоб прискорити пошук об'єктів файлової системи на великих динамічних масивах - на кшталт жорстких дисків об'ємом в кілька терабайт або ще більш значних RAID-масивів.
B-дерева вимагають набагато менше звернень до диску, ніж інші типи збалансованих дерев, при виконанні тих же операцій. Досягається це за рахунок того, що кінцеві об'єкти в B-деревах ієрархічно розташовані на одній висоті, а швидкість всіх операцій якраз пропорційна висоті дерева.
Як і інші збалансовані дерева, B-trees мають однакову довжину шляхів від кореня до будь-якого листа. Замість зростання вгору вони сильніше розгалужуються і більше ростуть в ширину: всі крапки розгалуження у B-дерева зберігають безліч посилань на дочірні об'єкти, завдяки чому їх легко відшукати за менше число звернень. Велике число покажчиків знижує кількість найтриваліших дискових операцій - позиціонування головок при читанні довільних блоків.
Концепція B-дерев була сформульована ще в сімдесятих роках і з тих пір піддавалася різним поліпшень. У тому чи іншому вигляді вона реалізована в NTFS, BFS, XFS, JFS, ReiserFS і безлічі СУБД. Всі вони - родичі з точки зору базових принципів організації даних. Відмінності стосуються деталей, часто досить важливих. Недолік у родинних файлових систем теж загальний: всі вони створювалися для роботи саме з дисками ще до появи SSD.
Твердотільні накопичувачі поступово витісняють дискові, але поки змушені використовувати чужі їм файлові системи, передані у спадок. Вони побудовані на масивах флеш-пам'яті, принципи роботи якої відрізняються від таких у дискових пристроїв. Зокрема, флеш-пам'ять повинна стиратися перед записом, а ця операція в чіпах NAND не може виконуватися на рівні окремих осередків. Вона можлива тільки для великих блоків цілком.
Пов'язано це обмеження з тим, що в NAND-пам'яті все осередки об'єднані в блоки, кожен з яких має тільки одну спільну підключення до керуючої шині. Не будемо вдаватися в деталі сторінкової організації і розписувати повну ієрархію. Важливий сам принцип групових операцій з осередками і той факт, що розміри блоків флеш-пам'яті зазвичай більше, ніж блоки, адресовані в будь-який файлової системи. Тому всі адреси і команди для накопичувачів з NAND flash треба транслювати через шар абстрагування FTL (Flash Translation Layer).
Сумісність з логікою дискових пристроїв і підтримку команд їх нативних інтерфейсів забезпечують контролери флеш-пам'яті. Зазвичай FTL реалізується саме в їх прошивці, але може (частково) виконуватися і на хості - наприклад, компанія Plextor пише для своїх SSD драйвери, що прискорюють запис.
Зовсім без FTL не обійтися, оскільки навіть запис одного біта в конкретний осередок призводить до запуску цілої серії операцій: контролер шукає блок, що містить потрібну комірку; блок зчитується повністю, записується в кеш або на вільне місце, потім стирається цілком, після чого перезаписується назад вже з необхідними змінами.
Такий підхід нагадує армійські будні: щоб віддати наказ одному солдатові, сержант робить загальне побудова, викликає бідолаху з ладу і командує іншим розійтися. У рідкісної нині NOR-пам'яті організація була спецназівські: кожна клітинка управлялася незалежно (у кожного транзистора був індивідуальний контакт).
Завдань у контролерів все додається, оскільки з кожним поколінням флеш-пам'яті техпроцес її виготовлення зменшується заради підвищення щільності і здешевлення вартості зберігання даних. Разом з технологічними нормами зменшується і розрахунковий термін експлуатації чіпів.
Модулі з однорівневими осередками SLC мали заявлений ресурс в 100 тисяч циклів перезапису і навіть більше. Багато з них до цих пір працюють в старих флешках і картках CF. У MLC корпоративного класу (eMLC) ресурс заявлявся в межах від 10 до 20 тисяч, в той час як у звичайній MLC споживчого рівня він оцінюється в 3-5 тисяч. Пам'ять цього типу активно тіснить ще дешевша TLC, у якій ресурс ледь дотягує до тисячі циклів. Утримувати термін життя флеш-пам'яті на прийнятному рівні доводиться за рахунок програмних хитрувань, і нові файлові системи стають одним з них.
Спочатку виробники припускали, що файлова система неважлива. Контролер сам повинен обслуговувати недовговічний масив осередків пам'яті будь-якого типу, розподіляючи між ними навантаження оптимальним чином. Для драйвера файлової системи він імітує звичайний диск, а сам виконує низькорівневі оптимізації при будь-якому зверненні. Однак на практиці оптимізація у різних пристроїв різниться від чарівної до фіктивної.
У корпоративних SSD вбудований контроллер - це маленький комп'ютер. У нього є величезний буфер пам'яті (полгіга і більше), і він підтримує безліч методів підвищення ефективності роботи з даними, що дозволяє уникати зайвих циклів перезапису. Чіп впорядковує все блоки в кеші, виконує відкладений запис, виробляє Дедуплікація на льоту, резервує одні блоки і очищає в тлі інші. Все це чарівництво відбувається абсолютно непомітно для ОС, програм і користувача. З таким SSD дійсно неважливо, яка файлова система використовується. Внутрішні оптимізації роблять набагато більший вплив на продуктивність і ресурс, ніж зовнішні.
В бюджетні SSD (і тим більше - флешки) ставлять куди менш розумні контролери. Кеш в них урізаний або відсутній, а просунуті серверні технології не застосовуються зовсім. У картах пам'яті контролери настільки примітивні, що часто стверджується, ніби їх немає зовсім. Тому для дешевих пристроїв з флеш-пам'яттю залишаються актуальними зовнішні методи балансування навантаження - в першу чергу за допомогою спеціалізованих файлових систем.
Однією з перших спроб написати файлову систему, яка б враховувала принципи організації флеш-пам'яті, була JFFS - Journaling Flash File System. Спочатку ця розробка шведської фірми Axis Communications була орієнтована на підвищення ефективності пам'яті мережевих пристроїв, які Axis випускала в дев'яностих. Перша версія JFFS підтримувала тільки NOR-пам'ять, але вже в другій версії подружилася з NAND.
Зараз JFFS2 має обмежене застосування. В основному вона все так само використовується в дистрибутивах Linux для вбудованих систем. Її можна знайти в маршрутизаторах, IP-камерах, NAS і інших завсідників інтернету речей. Загалом, скрізь, де потрібно невеликий обсяг надійної пам'яті.
Подальшої спробою розвитку JFFS2 стала LogFS, у якій індексні дескриптори зберігалися в окремому файлі. Автори цієї ідеї - співробітник німецького підрозділу IBM Йорн Енгель та викладач Оснабрюкского університету Роберт Мертенс. Вихідний код LogFS викладений на GitHub. Судячи з того, що остання зміна в ньому було зроблено чотири роки тому, LogFS так і не набула популярності.
Зате ці спроби підстьобнули поява іншої спеціалізованої файлової системи - F2FS. Її розробили в корпорації Samsung, на частку якої припадає чимала частина виробленої у світі флеш-пам'яті. В Samsung роблять чіпи NAND Flash для власних пристроїв та на замовлення інших компаній, а також розробляють SSD з принципово новими інтерфейсами замість успадкованих дискових. Створення спеціалізованої файлової системи з оптимізацією для флеш-пам'яті було з точки зору Samsung давно назрілою необхідністю.
Чотири роки тому, в 2012 році, в Samsung створили F2FS (Flash Friendly File System). Її ідея хороша, але реалізація виявилася вогкуватої. Ключове завдання при створенні F2FS була проста: знизити число операцій перезапису елементів і розподілити навантаження на них максимально рівномірно. Для цього потрібно виконувати операції з декількома осередками в межах того ж блоку одночасно, а не гвалтувати їх по одній. Значить, потрібна не миттєва перезапис наявних блоків за першим запитом ОС, а кешування команд і даних, дозапис нових блоків на вільне місце і відкладене стирання осередків.
Сьогодні підтримка F2FS вже офіційно реалізована в Linux (а значить, і в Android), але особливих переваг на практиці вона поки не дає. Основна особливість цієї файлової системи (відкладена перезапис) привела до передчасних висновків про її ефективності. Старий трюк з кешуванням навіть дурив ранні версії бенчмарков, де F2FS демонструвала уявне перевагу нема на кілька відсотків (як очікувалося) і навіть не в рази, а на порядки. Просто драйвер F2FS рапортував про виконання операції, яку контролер тільки планував зробити. Втім, якщо реальний приріст продуктивності у F2FS і невеликий, то знос осередків безумовно буде менше, ніж при використанні тієї ж ext4. Ті оптимізації, які не зможе зробити дешевий контролер, будуть виконані на рівні самої файлової системи.
Поки F2FS сприймається як екзотика для гиків. Навіть у власних смартфонах Samsung все ще застосовується ext4. Багато хто вважає її подальшим розвитком ext3, але це не зовсім так. Мова йде скоріше про революцію, ніж про подолання бар'єру в 2 Тбайт на файл і простому збільшенні інших кількісних показників.
Коли комп'ютери були великими, а файли - маленькими, адресація не уявляла складнощів. Кожному файлу виділялося енну кількість блоків, адреси яких заносилися в таблицю відповідності. Так працювала і файлова система ext3, що залишається в строю до сих пір. А ось в ext4 з'явився принципово інший спосіб адресації - екстенти.
Екстенти можна уявити як розширення індексних дескрипторів у вигляді відокремлених наборів блоків, які адресуються цілком як безперервні послідовності. Один екстент може містити цілий файл середнього розміру, а для великих файлів досить виділити десяток-другий екстентів. Це куди ефективніше, ніж адресувати сотні тисяч дрібних блоків по чотири кілобайт.
Змінився в ext4 і сам механізм запису. Тепер розподіл блоків відбувається відразу за один запит. І не заздалегідь, а безпосередньо перед записом даних на диск. Відкладене багатоблокових розподіл дозволяє позбутися від зайвих операцій, якими грішила ext3: в ній блоки для нового файлу виділялися відразу, навіть якщо він цілком уміщався в кеші і планувався до видалення як тимчасовий.
Крім збалансованих дерев і їх модифікацій, є й інші популярні логічні структури. Існують файлові системи з принципово іншим типом організації - наприклад, лінійним. Як мінімум однієї з них ти напевно часто користуєшся.
Відгадай загадку: о дванадцятій вона почала повніти, до шістнадцяти була дурнуватою товстункою, а до тридцяти двох стала жирною, так і залишившись простачкою. Хто вона?
Правильно, це історія про файлову систему FAT. Вимоги сумісності забезпечили їй погану спадковість. На дискетах вона була 12-розрядної, на жорстких дисках - спочатку 16-бітної, а до наших днів дійшла вже як 32-розрядна. У кожній наступній версії збільшувалося число адресованих блоків, але в самій суті нічого не змінювалося.
Популярна досі файлова система FAT32 з'явилася аж двадцять років тому. Сьогодні вона все так само примітивна і не підтримує ні списки управління доступом, ні дискові квоти, ні фонове стиснення, ні інші сучасні технології оптимізації роботи з даними.
Навіщо ж FAT32 потрібна в наші дні? Все так же виключно для забезпечення сумісності. Виробники справедливо вважають, що розділ з FAT32 зможе прочитати будь-яка ОС. Тому саме його вони створюють на зовнішніх жорстких дисках, USB Flash і картах пам'яті.
Картки microSD (HC), які використовуються в смартфонах, за замовчуванням відформатовані в FAT32. Це основна перешкода для установки на них додатків і перенесення даних з внутрішньої пам'яті. Щоб його подолати, потрібно створити на картці розділ з ext3 або ext4. На нього можна перенести всі файлові атрибути (включаючи власника і права доступу), тому будь-який додаток зможе працювати так, немов запустилось з внутрішньої пам'яті.
Windows не вміє робити на флешках більше одного розділу, але для цього можна запустити Linux (хоча б в виртуалке) або просунуту утиліту для роботи з логічної розміткою - наприклад, MiniTool Partition Wizard Free. Виявивши на картці додатковий первинний розділ з ext3 / ext4, додаток Link2SD і аналогічні йому запропонують куди більше варіантів, ніж у випадку з одним розділом FAT32.
Як ще один аргумент на користь вибору FAT32 часто називають відсутність в ній журналирования, а значить, більш швидкі операції записи і менший знос осередків пам'яті NAND Flash. На практиці ж використання FAT32 призводить до зворотного і породжує безліч інших проблем.
Флешки та карти пам'яті якраз швидко вмирають через те, що будь-яка зміна в FAT32 викликає перезапис одних і тих же секторів, де розташовані два ланцюжки файлових таблиць. Зберіг веб-сторінку цілком, і вона перезаписати раз сто - з кожним додаванням на флешку черговий дрібної гифки. Запустив портейбл-софт? Він настворювала тимчасових файлів і постійно змінює їх під час роботи. Тому набагато краще використовувати на флешках NTFS з її стійкою до збоїв таблицею $ MFT. Дрібні файли можуть зберігатися прямо в головній файловій таблиці, а її розширення і копії записуються в різні області флеш-пам'яті. До того ж завдяки індексації на NTFS пошук виконується швидше.
Інша проблема, з якою стикається більшість користувачів, - на розділ з FAT32 неможливо записати файл більше 4 Гбайт. Причина полягає в тому, що в FAT32 розмір файлу описується 32 бітами в таблиці розміщення файлів, а 2 ^ 32 (мінус одиниця, якщо бути точним) якраз дають чотири гіга. Виходить, що на свіжокуплені флешку можна записати ні фільм в нормальній якості, ні образ DVD.
Копіювання великих файлів ще півбіди: при спробі зробити це помилка хоча б видно відразу. В інших ситуаціях FAT32 виступає в ролі бомби уповільненої дії. Наприклад, ти скопіював на флешку портейбл-софт і на перших порах користуєшся їм без проблем. Через тривалий час у одній з програм (припустимо, бухгалтерської або поштової) база даних роздувається, і ... вона просто перестає оновлюватися. Файл не може бути перезаписаний, оскільки досяг ліміту в 4 Гбайт.
Менш очевидна проблема полягає в тому, що в FAT32 дата створення файлу або каталогу може бути задана з точністю до двох секунд. Цього недостатньо для багатьох криптографічних додатків, що використовують тимчасові мітки. Низька точність атрибута «дата» - ще одна причина того, чому FAT32 не розглядається як повноцінна файлова система з точки зору безпеки. Однак її слабкі сторони можна використовувати і в своїх цілях. Наприклад, якщо скопіювати на тому FAT32 будь-які файли з розділу NTFS, то вони очистяться від усіх метаданих, а також успадкованих і спеціально заданих дозволів. FAT просто не підтримує їх.
На відміну від FAT12 / 16/32, exFAT розроблялася спеціально для USB Flash і карт пам'яті великого (≥ 32 Гбайт) обсягу. Extended FAT усуває згаданий вище недолік FAT32 - перезапісиваніе одних і тих же секторів при будь-якій зміні. Як у 64-розрядної системи, у неї немає практично значущих лімітів на розмір одного файлу. Теоретично він може мати довжину в 2 ^ 64 байт (16 Ебайт), а картки такого обсягу з'являться нескоро.
Ще одна принципова відмінність exFAT - Підтримка списків контролю доступу (ACL). Це вже не та простачка з дев'яностих, однак впровадження exFAT заважає закритість формату. Підтримка exFAT повноцінно і легально реалізована тільки в Windows (починаючи з XP SP2) і OS X (починаючи з 10.6.5). В Linux і * BSD вона підтримується або з обмеженнями, або не цілком законно. Microsoft вимагає ліцензувати використання exFAT, і в цій області багато правових спорів.
Ще один яскравий представник файлових систем на основі B-дерев називається Btrfs. Ця ФС з'явилася в 2007 році і спочатку створювалася в Oracle з прицілом на роботу з SSD і RAID. Наприклад, її можна динамічно масштабувати: створювати нові індексні дескриптори прямо в працюючій системі або розділяти тому на подтома без виділення їм вільного місця.
Реалізований в Btrfs механізм копіювання при записі і повна інтеграція з модулем ядра Device mapper дозволяють робити практично миттєві снапшоти через віртуальні блокові пристрої. Попереднє стиснення даних (zlib або lzo) і дедуплікація прискорюють основні операції, заодно продовжуючи час життя флеш-пам'яті. Особливо це помітно при роботі з базами даних (досягається стиск в 2-4 рази) і дрібними файлами (вони записуються впорядковано великими блоками і можуть зберігатися безпосередньо в «листі»).
Також Btrfs підтримує режим повного журналювання (даних і метаданих), перевірку томи без від'єднання і безліч інших сучасних фич. Код Btrfs опублікований під ліцензією GPL. Ця файлова система підтримується в Linux як стабільна починаючи з версії ядра 4.3.1.
Практично всі більш-менш сучасні файлові системи (ext3 / ext4, NTFS, HFSX, Btrfs і інші) відносять до загальної групи журнальованою, оскільки вони ведуть облік внесених змін в окремому балці (журналі) і звіряються з ним в разі збою при виконанні дискових операцій . Однак ступінь подробиці ведення журналів і відмовостійкість у цих файлових систем різні.
Еxt3 підтримує три режими ведення журналу: зі зворотним зв'язком, упорядкований і повне журнал. Перший режим має на увазі запис тільки загальних змін (метаданих), виконувану асинхронно по відношенню до змін самих даних. У другому режимі виконується та ж запис метаданих, але строго перед внесенням будь-яких змін. Третій режим еквівалентний повного журнал (змін як в метаданих, так і в самих файлах).
Цілісність даних забезпечує тільки останній варіант. Решта два лише прискорюють виявлення помилок в ході перевірки і гарантують відновлення цілісності самої файлової системи, але не вмісту файлів.
Журнал роботи в NTFS схоже на другий режим ведення логу в ext3. В журнал записуються тільки зміни в метаданих, а самі дані в разі збою можуть бути загублені. Такий метод ведення журналу в NTFS замислювався не як спосіб досягнення максимальної надійності, а лише як компроміс між швидкодією і стійкістю до відмов. Саме тому люди, які звикли до роботи з повністю журнальованою системами, вважають NTFS псевдожурналіруемой.
Реалізований в NTFS підхід в чомусь навіть краще використовується за замовчуванням в ext3. В NTFS додатково періодично створюються контрольні точки, які гарантують виконання всіх відкладених раніше дискових операцій. Контрольні точки не мають нічого спільного з точками відновлення в \ System Volume Infromation \. Це просто службові записи в балці.
Практика показує, що такого часткового журналирования NTFS в більшості випадків вистачає для безпроблемної роботи. Адже навіть при різкому відключенні харчування дискові пристрою не обесточиваются миттєво. Блок живлення і численні конденсатори в самих накопичувачах забезпечують якраз той мінімальний запас енергії, якого вистачає на завершення поточної операції записи. Сучасним SSD при їх швидкодії і економічності такого ж кількості енергії зазвичай вистачає і на виконання відкладених операцій. Спроба ж перейти на повне журнал знизила б швидкість більшості операцій в рази.
Використання файлових систем лімітовано їх підтримкою на рівні ОС. Наприклад, Windows не розуміє ext2 / 3/4 і HFS +, а використовувати їх часом треба. Зробити це можна, додавши відповідний драйвер.
Відкритий драйвер для читання і запису на розділи ext2 / 3 з частковою підтримкою ext4. В останній версії підтримуються екстенти і розділи обсягом до 16 Тбайт. Не підтримуються LVM, списки контролю доступу і розширені атрибути.
Існує безкоштовний плагін для Total Commander. Підтримує читання розділів ext2 / 3/4.
coLinux - відкритий і безкоштовний порт ядра Linux. Разом з 32-бітовим драйвером він дозволяє запускати Linux в середовищі Windows з 2000 по 7 без використання технологій віртуалізації. Підтримує тільки 32-бітові версії. Розробка 64-бітної модифікації була скасована. сoLinux дозволяє в тому числі організувати з Windows доступ до розділів ext2 / 3/4. Підтримка проекту припинена в 2014 році.
Можливо, в Windows 10 вже є вбудована підтримка характерних для Linux файлових систем, просто вона прихована. На ці думки наводить драйвер рівня ядра Lxcore.sys і сервіс LxssManager, який завантажується як бібліотека процесом Svchost.exe. Детальніше про це дивись в доповіді Алекса Іонеску «Ядро Лінукс, приховане усередині Windows 10», з яким він виступив на Black Hat 2016.
ExtFS for Windows - платний драйвер, що випускається компанією Paragon. Він працює в Windows з 7 по 10, підтримує доступ до томів ext2 / 3/4 в режимі читання і запису. Забезпечує майже повну підтримку ext4 в Windows.
HFS + for Windows 10 - ще один пропріетарний драйвер виробництва Paragon Software. Незважаючи на назву, працює у всіх версіях Windows починаючи з XP. Надає повний доступ до файлових систем HFS + / HFSX на дисках з будь-розміткою (MBR / GPT).
WinBtrfs - рання розробка драйвера Btrfs для Windows. Уже в версії 0.6 підтримує доступ до томів Btrfs як на читання, так і на запис. Вміє обробляти жорсткі і символічні посилання, підтримує альтернативні потоки даних, ACL, два види компресії і режим асинхронного читання / запису. Поки WinBtrfs не вміє використовувати mkfs.btrfs, btrfs-balance та багато інших програм для обслуговування цієї файлової системи.
| Фай-ло-вая сис-те-ма | Мак-сі-маль-ний раз-мер томи | Пре-дель-ний раз-мер одного файлу | Дли-на собст-вен-ного імені файлу | Дли-на пів-но-го імені файлу (вклю-чаю шлях від кореня) | Пре-дель-ве число файлів і / або ката-ло-гов | Точ-ність вка-за-ня дати файлу / ката-ло-га | Права доступу | жорсткі посилання | Сім-воль-ні посилання | Мгно-вен-ні знімки (snap-shots) | Сжа-тя дан-них в тлі | Шиф-ро-ва-ня дан-них в тлі | Дідові-пли-ка-ція дан-них |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| FAT16 | 2 ГБ секторами по 512 байт або 4 ГБ кластерами по 64 КБ | 2 ГБ | 255 байт з LFN | - | - | - | - | - | - | - | - | - | - |
| FAT32 | 8 ТБ секторами по 2 КБ | 4 ГБ (2 ^ 32 - 1 байт) | 255 байт з LFN | до 32 підкаталогів з CDS | 65460 | 10 мс (створення) / 2 з (зміна) | немає | немає | немає | немає | немає | немає | немає |
| exFAT | ≈ 128 ПБ (2 ^ 32-1 кластерів по 2 ^ 25-1 байт) теоретично / 512 ТБ через сторонніх обмежень | 16 ЕБ (2 ^ 64 - 1 байт) | 2796202 в каталозі | 10 мс | ACL | немає | немає | немає | немає | немає | немає | ||
| NTFS | 256 ТБ кластерами по 64 КБ або 16 ТБ кластерами по 4 КБ | 16 ТБ (Win 7) / 256 ТБ (Win 8) | 255 символів Unicode (UTF-16) | 32760 символів Unicode, але не більше 255 символів в кожному елементі | 2^32-1 | 100 нс | ACL | да | да | да | да | да | да |
| HFS + | 8 ЕБ (2 ^ 63 байт) | 8 ЕБ | 255 символів Unicode (UTF-16) | окремо не обмежується | 2^32-1 | 1 з | Unix, ACL | да | да | немає | да | да | немає |
| APFS | 8 ЕБ (2 ^ 63 байт) | 8 ЕБ | 255 символів Unicode (UTF-16) | окремо не обмежується | 2^63 | 1 нс | Unix, ACL | да | да | да | да | да | да |
| Ext3 | 32 ТБ (теоретично) / 16 ТБ кластерами по 4 КБ (через обмеження утиліт e2fs programs) | 2 ТБ (теоретично) / 16 ГБ у старих програм | 255 символів Unicode (UTF-16) | окремо не обмежується | - | 1 з | Unix, ACL | да | да | немає | немає | немає | немає |
| Ext4 | 1 ЕБ (теоретично) / 16 ТБ кластерами по 4 КБ (через обмеження утиліт e2fs programs) | 16 ТБ | 255 символів Unicode (UTF-16) | окремо не обмежується | 4 млрд. | 1 нс | POSIX | да | да | немає | немає | да | немає |
| F2FS | 16 ТБ | 3,94 ТБ | 255 байт | окремо не обмежується | - | 1 нс | POSIX, ACL | да | да | немає | немає | да | немає |
| BTRFS | 16 ЕБ (2 ^ 64 - 1 байт) | 16 ЕБ | 255 символів ASCII | 2 ^ 17 байт | - | 1 нс | POSIX, ACL | да | да | да | да | да | да |
Я вже анонсував її колись в своєму блозі, тоді про неї ще толком нічого не було відомо, і ось настав час для короткого, але більш послідовного знайомства з новою ReFS.
Однак у всього є межа, і у можливостей файлових систем - теж. Сьогодні можливості NTFS підійшли до своїх кордонів: перевірка ємних носіїв даних займає надто багато часу, «Журнал» гальмує доступ, а максимальний розмір файлів вже практично досягнуто. Розуміючи це, Microsoft реалізувала в Windows 8 нову файлову систему - ReFS (Resilient File System - відмовостійка файлова система). Вважається, що ReFS забезпечує кращий захист даних на ємних і швидких жорстких дисках. Напевно у неї є і свої недоліки, але до початку по-справжньому масового використання в Windows 8 говорити про них важко.
Так що поки спробуємо розібратися у внутрішньому устрої та переваги ReFS.
Спочатку ReFS була відома під кодовою назвою «Protogon». Вперше про неї широкому загалу приблизно рік назад розповів Стівен Сінофскі- президент підрозділу Windows в Microsoft, який відповідає за розробку і маркетинг Windows і Internet Explorer.
Розповів такими словами:
«Сьогодні система NTFS є найбільш широко використовуваної, передовий і функціонально багатою файлової системою. Але переосмислюючи Windows, а ми в даний момент розробляємо Windows 8, - ми не зупиняємося на досягнутому. Тому разом з Windows 8 ми також впроваджуємо абсолютно нову файлову систему. ReFS створена на основі NTFS, тому в ній збереглися найважливіші можливості сумісності, в той же час вона розроблена і спроектована з урахуванням потреб нового покоління технологій і сценаріїв зберігання даних.
У Windows 8, ReFS буде введена тільки як частина Windows Server 8, такий же підхід ми використовували для впровадження всіх попередніх файлових систем. Звичайно ж, на прикладному рівні клієнтам надаватиметься доступ до даних ReFS такий же, як до даних NTFS. Не можна забувати про те, що NTFS все ще є провідною технологією в індустрії серед файлових систем для ПК ».
Дійсно, вперше ReFS ми побачили в серверної ОС Windows Server 8. Нова файлова система розроблена все ж таки не з нуля. Наприклад для відкриття, закриття, читання і запису файлів ReFS використовує ті ж інтерфейси доступу API, що і NTFS. Також з NTFS перекочували багато добре знайомі можливості - наприклад, шифрування диска Bitlockerі символьні посиланнядля бібліотек. Зате зникло, наприклад, стиснення данихі ряд інших функцій.
Основні інновації ReFS зосереджені в області створення структур файлів і папок, а також управління ними. Їх завдання - забезпечити автоматичне виправленняпомилок, максимальне масштабування і роботу в режимі постійної підключеності (Always Online).
Дискова реалізація структур ReFS кардинально відрізняється від інших файлових систем Microsoft. Реалізувати свої ідеї розробники Microsoft змогли, застосувавши в ReFS концепцію B ± дерев, добре знайому по базах даних. Папки в файлової системі структуровані у вигляді таблиць з файлами в якості записів. Вони, в свою чергу, отримують певні атрибути, що додаються в якості підтаблиць, створюючи ієрархічну деревоподібну структуру. Навіть вільне місце на диску організовано у вигляді таблиць.
Поряд з реальною 64-бітної нумерацією всіх елементів системи це виключає появу «вузьких місць» при подальшому її масштабування
Як результат, ядром системи в ReFS стала таблиця об'єктів - центральний каталог, в якому перераховані всі таблиці в системі. Є у такого підходу важлива перевага: ReFS відмовилася від складного управління журналом і фіксує нову інформацію про фото у вільному місці - це запобігає її перезапісиваніе.
« листям Каталогу»Є типізовані записи. Для об'єкта-папки існують три основні типи записів: описатель каталогу, індексна запис і описувач вкладеного об'єкта. Всі такі записи упаковані у вигляді окремого B ± дерева, що має ідентифікатор папки; корінь цього дерева є листом B ± дерева «Каталогу», що дозволяє упакувати в папку практично будь-яку кількість записів. На нижньому рівні в листах B ± дерева папки знаходиться в першу чергу запис описателя каталогу, що містить основні дані про папку (ім'я, «стандартна інформація», атрибут імені файлу і т.д.).
Далі в каталозі поміщені індексні записи: Короткі структури, що містять дані про елементи, що містяться в папці. Ці записи значно коротше, ніж в NTFS, - це в меншій мірі перевантажує тому метаданими.
В кінці поміщені записи елементів каталогу. Для папок ці елементи містять ім'я паки, ідентифікатор папки в «Каталозі» і структуру «стандартної інформації». Для файлів ідентифікатор відсутній - замість цього структура містить всі основні дані про фото, включаючи корінь B ± дерева фрагментів файлу. Відповідно, файл може складатися практично з будь-якого числа фрагментів.
Подібно NTFS, в ReFS принципово різниться інформація про файл (метадані) і вміст файлу (призначені для користувача дані). Однак захисні функції надаються і тим, і іншим однаково. Метадані за замовчуванням вживають запобіжних засобів за допомогою контрольних сум - такий самий захист (за бажанням) можна дати і призначених для користувача даних. Ці контрольні суми розташовуються на диску на безпечну відстань один від одного - так буде простіше відновити дані у разі виникнення помилки.
Розмір метаданих порожній файлової системи становить близько 0.1% від розміру самої файлової системи (тобто близько 2 Гб на том 2 Тб). Деякі основні метадані дублюються для більшої стійкості від збоїв
Варіант ReFS, який ми побачили в Windows Server 8 Beta, Має підтримку кластерів даних розміром тільки 64 Кб і кластерів метаданих розміром 16 Кб. Поки параметр «Розмір кластера» при створенні томи ReFS ігнорується і завжди приймається замовчує. При форматуванні файлової системи єдиним доступним варіантом для вибору розміру кластера також є 64 Кб.
Визнаємо: такого розміру кластера більш ніж вистачить для організації файлових систем будь-якого розміру. Побічним ефектом, правда, стає відчутна надмірність при зберіганні даних (файл розміром в 1 байт на диску займе повний блок 64 Кб).
З точки зору архітектури файлової системи ReFS має всі необхідні інструменти для безпечного відновлення файлів навіть після серйозного збою обладнання. Головний мінус системи журналів в файлової системі NTFS і їй подібних - то, що оновлення диска може пошкодити записані раніше метадані при збої живлення під час запису - цей ефект отримав вже стійке назва: т.зв. « обірвана запис».
Для запобігання обірваних записів, Розробники з Microsoft обрали новий підхід, при якому частини структур метаданих містять власні ідентифікатори, що дозволяє перевірити приналежність структур; посилання на метадані містять 64-біт контрольні суми блоків, на які проводиться посилання.
Будь-яке зміна структури метаданих відбувається в два етапи. Спершу створюється нова (змінена) копія метаданих у вільному дисковому просторі, і тільки після цього, в разі успіху, атомарної операцією поновлення посилання перекладається зі старою (незміненій) на нову (змінену) область метаданих. Тут це дозволяє обійтися без журналирования, автоматично зберігаючи цілісність даних.
Втім, описана схема не застосовується до призначених для користувача даних, так що будь-які зміни вмісту файлу пишуться безпосередньо в файл. Видалення файлу здійснюється перестроюванням структури метаданих, що зберігає попередню версію блоку метаданих на диску. Такий підхід дозволяє відновлювати видалені файли аж до їх перезапису новими даними користувачів.
Окрема тема - відмовостійкість ReFS при пошкодженні диска. Система здатна виявити всі форми ушкоджень диска, включаючи втрачені або збережені не в тому місці записи, а так же т. Н. бітовий розпад(Погіршення стану даних на носії)
Коли включена опція «цілісні потоки», ReFS перевіряє по контрольних сумах також і вміст файлів і завжди записує зміни файлів в сторонньому місці. Це дає впевненість у тому, що існували раніше дані не будуть втрачені при перезапису. Оновлення контрольних сум відбувається автоматично при записі даних, так що якщо в ході запису станеться збій, у користувача залишиться доступна для перевірки версія файлу.
Ще одна цікава тема в питанні безпеки ReFS - взаємодія з Storage Spaces. ReFS і Storage Spacesрозроблені так, щоб взаємодоповнювати один одного як два компонента єдиної системи зберігання даних. Крім поліпшення продуктивності Storage Spacesзахищають дані від часткових і повних збоїв диска за рахунок зберігання копій на кількох дисках. Під час збоїв при читанні Storage Spacesможуть зчитувати копії, а при збоях записи (навіть при повній втраті даних носія при читанні / запису) можливо «прозоро» перерозподіляти дані. Як показує практика, найчастіше подібний збій не має відношення до носія - він відбувається через пошкодження даних, або через втрату даних або збереження їх не в тому місці.
Якраз ці види збоїв ReFS може виявити, використовуючи контрольні суми. Виявивши збій, ReFS зв'язується з Storage Spacesдля того, щоб вважати всі можливі копії даних, і вибирає потрібну копію, грунтуючись на перевірці контрольних сум. Після цього система дає Storage Spacesкоманду на відновлення пошкоджених копій на основі вірних копій. Все це відбувається прозоро з прикладної точки зору.
Як вказується на сайті Microsoft, присвяченому Windows Server 8, Контрольні суми завжди включені для метаданих ReFS, і за умови, що те розміщений на дзеркальних Storage Spaces, Включається також автоматичне виправлення. Все цілісні потоки захищені тим же способом. Це створює наскрізне рішення з високим ступенем цілісності для користувача, завдяки якому щодо ненадійне сховище можна зробити досить надійним.
Згадані цілісні потоки захищають вміст файлу від всіх видів ушкоджень даних. Втім, ця характеристика в деяких випадках не застосовується.
Наприклад, для деяких додатків краще акуратне управління зберіганням файлів з певною сортуванням файлів на диску. Оскільки цілісні потоки перерозподіляють блоки кожен раз, коли вміст файлу змінюється, компоновка файлів для цих додатків занадто непередбачувана. Системи баз даних є яскравим прикладом цього. Як правило, такі програми самостійно ведуть облік контрольних сум вмісту файлів і мають можливість перевіряти і виправляти дані шляхом прямої взаємодії з інтерфейсами API.
Як ReFS діє в разі пошкодження диска або збій зберігання, думаю, зрозуміло. Складніше буває виявити і подолати втрати даних, пов'язані з « бітовим розпадом», Коли невиявлені вчасно ушкодження рідко читаються частин диска починають інтенсивно рости. На той час, як такі пошкодження будуть прочитані і виявлені, вони можуть вже торкнутися копії, які дані можуть бути втрачені через інших збоїв.
Щоб подолати процес бітового розпаду, В Microsoft додали фонову системну задачу, яка періодично очищає метадані і дані цілісних потоків на томі ReFS, що знаходиться на дзеркальному просторі зберігання. Очищення відбувається за допомогою зчитування всіх зайвих копій і перевірки їх на правильність за допомогою контрольних сум ReFS. Якщо контрольні суми не сходяться, копії з помилками виправляються за допомогою придатних копій.
Залишається загроза, яку можна умовно назвати «страшний сон сисадміна». Бувають випадки, хоч рідкісні, коли може бути пошкоджений навіть те на дзеркальному просторі. Наприклад, пам'ять несправну систему може пошкодити дані, які потім можуть виявитися на диску і пошкодити надлишкові копії. Крім того, багато користувачів можуть вирішити не застосовувати дзеркальні простору зберігання під ReFS.
Для таких випадків, коли тому пошкоджується, ReFS виконує «відновлення» - функцію, яка видаляє дані з простору імен в робочому томі. Її завдання - запобігти невиправні пошкодження, які могли б вплинути на доступність вірних даних. Наприклад, якщо єдиний файл в директорії отримав пошкодження і не може бути автоматично відновлено, ReFS видалить цей файл з простору імен файлової системи, відновивши решту томи.
Ми звикли до того, що файлова система не може відкрити або видалити файл, і адміністратор не може нічого з цим вдіяти.
Але оскільки ReFS може відновлювати пошкоджені дані, адміністратор зможе відновити цей файл з резервної копії, або за допомогою додатка створити його заново, уникнувши необхідності вимкнути систему. Це означає, що користувачеві або адміністраторові більше не буде потрібно проводити процедуру перевірки і виправлення диска в автономному режимі. Для серверів це дає можливість розгортати великі томи даних без ризику довгих періодів автономної роботи через пошкодження.
Звичайно, про практичність і зручність (або зворотних якостях) ReFS можна буде судити тільки після того, як комп'ютери з Windows 8 отримають широке поширення і пройде не менше півроку активної роботи з ними. Поки ж у потенційних користувачів «вісімки» більше питань, ніж відповідей на них.
Наприклад, такий: чи можна буде в Windows 8 легко і просто конвертувати дані з системи NTFS в ReFS і навпаки? Представники Microsoft заявляють, що ніякої вбудованої функції для перетворення форматів не передбачається, але інформацію все ж можна буде копіювати. Область застосування ReFS очевидна: спочатку вона може використовуватися лише як великий диспетчер даних для сервера (власне, вже використовується). Зовнішніх накопичувачів з ReFS поки не буде - тільки внутрішні. Очевидно, з часом ReFS буде оснащена великою кількістю функцій і зможе замінити застарілу систему.
У Microsoft говорять, що найімовірніше, це станеться вже з виходом першого пакету оновлень для Windows 8
Також в Microsoft стверджують, що протестували ReFS:
«Використовуючи складний великий набір десятків тисяч тестів, які створювалися для NTFS протягом більш ніж двох десятиліть. Ці тести відтворюють умови розгортання в ускладненому вигляді, з якими, як ми думаємо, система може зіткнутися, наприклад, при збої живлення, при проблемах, часто пов'язаних з масштабністю і продуктивністю. Отже, можна сказати, що система ReFS готова до тестового розгортання в керованому середовищі ».
При цьому, правда, розробники визнають, що будучи першою версією великої файлової системи, ймовірно ReFS потребують обережності в поводженні:
«Ми не характеризуємо ReFS для Windows 8 як бета-версію. Нова файлова система буде готова до випуску, коли Windows 8 вийде зі стадії "бета", тому що немає нічого важливішого, ніж надійність даних. Отже, на відміну від будь-якого іншого аспекту системи, тут необхідний консервативний підхід до первісного використання і тестування ».
Багато в чому саме з цієї причини вводитися в обіг ReFS буде згідно поетапного плану. Спершу - як храніліщной системи для Windows Server, потім - як сховище для користувачів, і вже в результаті - як завантажувальний тому. Втім, аналогічний «обережний підхід» при випуску нових файлових систем використовувався і раніше.
У цій статті розберемося які можливості надає ReFS і чим вона краща файлової системи NTFS. Як відновити дані з дискового простору ReFS. Нова файлова система ReFS від компанії Microsoft була спочатку представлена в ОС Windows Server 2012. Вона також включена в Windows 10, в складі інструменту Дисковий простір. ReFS можна використовувати для пулу дисків. З виходом Windows Server 2016 файлова система була покращена, незабаром вона буде доступна в новій версії Windows 10.
Які можливості надає ReFS і чим вона краща поточної NTFS системи?
зміст:скорочення від «Resilient File System», ReFS - ця нова система, створена на базі NTFS. На даному етапі ReFS не пропонує комплексну заміну NTFS для використання на диску домашніх користувачів. Файлова система має свої переваги і недоліки.
ReFS призначена для вирішення основних проблем NTFS. Вона більш стійка до пошкодження даних, краще справляється з підвищеним навантаженням і легко масштабується для дуже великих файлових систем. Давайте розглянемо, що це означає?
Файлова система використовує контрольні суми для метаданих, а також може використовувати контрольні суми для даних файлу. Під час читання або запису файлу, система перевіряє контрольну суму що б переконатися в її правильності. Таким чином здійснюється виявлення спотворених даних в режимі реального часу.
ReFS інтегрована з функцією Дисковий простір. Якщо ви налаштували дзеркальне сховище даних, то з допомогою ReFS Windows виявить і автоматично усуне пошкодження файлової системи, скопіювавши дані з іншого диска. Ця функція доступна як в Windows 10, так і Windows 8.1.
Якщо файлова система виявить пошкоджені дані, які не мають альтернативної копії для відновлення, то ReFS відразу видалити такі дані з диска. Це не зажадає перезавантаження системи або відключення пристрою зберігання інформації, як у випадку з NTFS.
Необхідність мати змогу користуватися chkdsk повністю зникає, так як файлова система автоматично коригується відразу в момент виникнення помилки. Нова системастійка і до інших варіантів пошкодження даних. NTFS під час запису метаданих файлу записує їх безпосередньо. Якщо в цей час виникає збій в електропостачанні або збій комп'ютера, ви отримаєте пошкодження даних.
Під час зміни метаданих ReFS створює нову копію даних і пов'язує дані з файлом, тільки після запису метаданих на диск. Це виключає можливість пошкодження даних. Ця функція називається копіюванням на запис, вона присутня і в інших популярних ОС Linux системах: ZFS, BtrFS, а також файлової системи Apple APFS.
ReFS сучасніша і підтримує набагато більші обсяги і довші імена файлів ніж NTFS. У довгостроковій перспективі це важливі поліпшення. У файлової системи NTFS ім'я файлу обмежена 255 символами, в ReFS ім'я файлу може містити до 32768 символів. Windows 10 дозволяє відключити обмеження на межу символів для файлових систем NTFS, але він завжди відключається на томах ReFS.
У ReFS більше не підтримуються короткі імена файлів у форматі DOS 8.3. На томі NTFS ви можете отримати доступ до C: \ Program Files \в C: \ PROGRA ~ 1 \для забезпечення сумісності зі старим програмним забезпеченням.
NTFS має теоретичний максимальний обсяг в розмірі 16 ексабайт, а у ReFS теоретичний максимальний обсяг - 262144 екзабайт. Хоча зараз це не має великого значення, але комп'ютера постійно розвиваються.
ReFS розроблялася не для підвищення продуктивності файлової системи в порівнянні з NTFS. Microsoft зробила систему ReFS набагато ефективніше в строго певних випадках.
Наприклад, при використанні з дисковим простором, ReFS підтримує «оптимізацію в режимі реального часу». Припустимо у вас є пул накопичувачів з двома дисками, один забезпечує максимальну продуктивність, інший використовується для обсягу. ReFS завжди буде записувати дані на більш швидкий диск, забезпечуючи максимальну продуктивність. У фоновому режимі файлову систему автоматично перемістить великі шматки даних на більш повільні диски для тривалого зберігання.
У Windows Server 2016 Microsoft покращила ReFS, для забезпечення кращої продуктивності функцій віртуальної машини. Віртуальна машина Microsoft Hyper-V використовує ці переваги (теоретично, будь-яка віртуальна машина може використовувати переваги ReFS).
Наприклад, ReFS підтримує клонування блоків, це прискорює процес клонування віртуальних машин і операцій злиття контрольних точок. Щоб створити копію віртуальної машини, ReFS потрібно тільки записати нові метадані на диск і вказати посилання на вже існуючі дані. Це пов'язано з тим, що в ReFS кілька файлів можуть вказувати на одні й ті ж базові дані на диску.
Коли віртуальна машина записує нові дані на диск, вони записуються в інше місце, а вихідні дані віртуальної машини залишаються на диску. Це значно прискорює процес клонування і вимагає набагато меншою пропускної здатності диска.
ReFS також пропонує нову функцію «Рідкісного VDL», Яка дозволяє ReFS швидко записувати нулі в великий файл. Це значно прискорює створення нового, порожнього файлу віртуального жорсткого диска фіксованого розміру (VHD). В NTFS ця операція може зайняти 10 хвилин, в ReFS - кілька секунд.
Не дивлячись на ряд переваг ReFS не може поки замінити NTFS. Windows не може завантажитися з розділу ReFS і вимагає NTFS. У ReFS не підтримуються такі функції NTFS як стиснення даних, шифрування файлової системи, жорсткі посилання, розширені атрибути, дедуплікація даних і дискові квоти. Але на відміну від NTFS, ReFS дозволяє виконати повне шифрування диска c допомогою BitLocker, включаючи системні структури диска.
Windows 10 не дозволяє відформатувати розділ в ReFS, ця файлова система доступна тільки в рамках Дискового простору. ReFS захищає дані використовуються на пулах з декількох жорстких дисків від пошкодження. У Windows Server 2016 ви можете форматувати томи за допомогою ReFS замість NTFS. Такий тому можна використовувати для зберігання віртуальних машин, але операційна система як і раніше може завантажуватися тільки з NTFS.
Hetman Partition Recovery дозволяє проаналізувати дисковий простір під управлінням файлової системою ReFS за допомогою алгоритму сигнатурного аналізу. Аналізуючи пристрій сектор за сектором програма знаходить певні послідовності байт і відображає їх користувачеві. Відновлення даних з дискового простору ReFS не відрізняється від роботи з файловою системою NTFS:
Майбутнє нової файлової системи досить туманно. Microsoft може доопрацювати ReFS для заміни застарілої NTFS у всіх версіях Windows. На даний момент ReFS не може використовуватися повсюдно і служить тільки для певних завдань.
Якщо вам уже довелося встановити і попрацювати з новими ОС від Microsoft: Windows Server 2012 і Windows 8, ви, ймовірно вже помітили, що тепер нові томи можна форматувати в файлової системі ReFS. Що ж таке файлова система ReFS? Абревіатура ReFS розшифровується, як Resilient File System, Тобто по-російськи «Відмовостійка файлова система».
Microsoft готує файлову систему ReFS в якості наступника найпопулярнішою на даний момент файлової системи NTFS, технологічні можливості якої вже підійшли до своїх кордонів. Зокрема при роботі з носіями даних великого розміру виникають складнощі з їх роботою: це і занадто тривалий час при виконанні операції перевірки на наявність помилок, і повільна робота журналу, і досягнення обмежень на максимальний розмір файлів на файлову систему NTFS.
Більшість нововведень ReFS лежить в області створення структур файлів і папок, і управління ними. Ці функції реалізовані з метою автоматичного виправлення помилок, забезпечення високої масштабованості і роботи в режимі Always Online (постійного підключення). Папки в файлової системі ReFS структуровані у вигляді таблиць з файлами в якості записів, які в свою чергу можуть мати власні атрибутами, організованими у вигляді підтаблиць, реалізую ієрархічну деревоподібну структуру B + -дерев, знайому нам по базах даних. Вільне місце на дисках також організовано в таблицях.
При розробці ReFS переслідувалися наступні цілі:
Основні можливості ReFS
Обмеження файлової системи ReFS
ReFS успадкувала багато функцій і семантики своєї попередниці NTFS, в тому числі:
Всі дані на файлової системі ReFS будуть доступні через ті ж самі API, які зараз використовуються для доступу до розділів NTFS.
У ReFS відмовилися від наступних функцій NTFS:
Підтримка ReFS з'явилася в ОС Windows 8 і Windows Server 2012, причому тільки для томів з даними. Тобто розділи з ReFS не можна використовувати для установки операційної системи і завантаження з нього. Згодом ReFS буде оснащена великою кількістю функцій і зможе повністю замінити застарілу систему NTFS. Ймовірно, все нові функції з'являться в першому Service Pack-е для Windows 8.
Крім того ReFS поки не можна застосовувати для знімних і переносних пристроїв зберігання (ReFS поки застосовується тільки для внутрішніх носіїв).
Неприємним моментом є той факт, що існуючі NTFS томи не можна конвертувати в ReFS на льоту. Дані доведеться переносити звичайним копіюванням.
Том можна відформатувати в файлову систему ReFS через консоль Disk Management. але Додаткові параметри, Наприклад, включення перевірки цілісності, можна включити тільки з командного рядка.
Наприклад, включити перевірку цілісності ReFS можна командою:
Format / fs: refs / q / i: enable
Не перевіряти цілісності.
