Файлові системи: порівняння, секрети і унікальні особливості

1. Зміст статті Чому смартфон може не запускати програми з карти пам'яті? Чим ext4 принципово відрізняється...
2. Чорний ящик
3. Спільне коріння
4. Флеш-пам'ять як двигун прогресу
5. Від JFFS до F2FS
6. Екстенти і бітові карти
7. Дієта з обмеженням FAT
8. загадка
9. Як звільнити флеш-пам'ять смартфона
10. exFAT
11. Btrfs
12. бортові журнали
13. Підключаємо сторонні ФС в Windows
14. Можливості та обмеження файлових систем: зведена таблиця

Зміст статті

Чому смартфон може не запускати програми з карти пам'яті? Чим 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 до F2FS

Однією з перших спроб написати файлову систему, яка б враховувала принципи організації флеш-пам'яті, була 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 в Windows 7

Екстенти можна уявити як розширення індексних дескрипторів у вигляді відокремлених наборів блоків, які адресуються цілком як безперервні послідовності. Один екстент може містити цілий файл середнього розміру, а для великих файлів досить виділити десяток-другий екстентів. Це куди ефективніше, ніж адресувати сотні тисяч дрібних блоків по чотири кілобайт.

Змінився в ext4 і сам механізм запису. Тепер розподіл блоків відбувається відразу за один запит. І не заздалегідь, а безпосередньо перед записом даних на диск. Відкладене багатоблокових розподіл дозволяє позбутися від зайвих операцій, якими грішила ext3: в ній блоки для нового файлу виділялися відразу, навіть якщо він цілком уміщався в кеші і планувався до видалення як тимчасовий.

Управляємо розділами ext3 / ext4 в Windows

Дієта з обмеженням FAT

Крім збалансованих дерев і їх модифікацій, є й інші популярні логічні структури. Існують файлові системи з принципово іншим типом організації - наприклад, лінійним. Як мінімум однієї з них ти напевно часто користуєшся.

загадка

Відгадай загадку: о дванадцятій вона почала повніти, до шістнадцяти була дурнуватою товстункою, а до тридцяти двох стала жирною, так і залишившись простачкою. Хто вона?

Правильно, це історія про файлову систему FAT. Вимоги сумісності забезпечили їй погану спадковість. На дискетах вона була 12-розрядної, на жорстких дисках - спочатку 16-бітної, а до наших днів дійшла вже як 32-розрядна. У кожній наступній версії збільшувалося число адресованих блоків, але в самій суті нічого не змінювалося.

Популярна досі файлова система FAT32 з'явилася аж двадцять років тому. Сьогодні вона все так само примітивна і не підтримує ні списки управління доступом, ні дискові квоти, ні фонове стиснення, ні інші сучасні технології оптимізації роботи з даними.

Навіщо ж FAT32 потрібна в наші дні? Все так же виключно для забезпечення сумісності. Виробники справедливо вважають, що розділ з FAT32 зможе прочитати будь-яка ОС. Тому саме його вони створюють на зовнішніх жорстких дисках, USB Flash і картах пам'яті.

Як звільнити флеш-пам'ять смартфона

Картки microSD (HC), які використовуються в смартфонах, за замовчуванням відформатовані в FAT32. Це основна перешкода для установки на них додатків і перенесення даних з внутрішньої пам'яті. Щоб його подолати, потрібно створити на картці розділ з ext3 або ext4. На нього можна перенести всі файлові атрибути (включаючи власника і права доступу), тому будь-який додаток зможе працювати так, немов запустилось з внутрішньої пам'яті.

Windows не вміє робити на флешках більше одного розділу, але для цього можна запустити Linux (хоча б в виртуалке) або просунуту утиліту для роботи з логічної розміткою - наприклад, MiniTool Partition Wizard Free . Виявивши на картці додатковий первинний розділ з ext3 / ext4, додаток Link2SD і аналогічні йому запропонують куди більше варіантів, ніж у випадку з одним розділом FAT32.

Додаток Link2SD визначило другий розділ на картці microSD

Як ще один аргумент на користь вибору FAT32 часто називають відсутність в ній журналирования, а значить, більш швидкі операції записи і менший знос осередків пам'яті NAND Flash. На практиці ж використання FAT32 призводить до зворотного і породжує безліч інших проблем.

Флешки та карти пам'яті якраз швидко вмирають через те, що будь-яка зміна в FAT32 викликає перезапис одних і тих же секторів, де розташовані два ланцюжки файлових таблиць. Зберіг веб-сторінку цілком, і вона перезаписати раз сто - з кожним додаванням на флешку черговий дрібної гифки. Запустив портейбл-софт? Він настворювала тимчасових файлів і постійно змінює їх під час роботи. Тому набагато краще використовувати на флешках NTFS з її стійкою до збоїв таблицею $ MFT. Дрібні файли можуть зберігатися прямо в головній файловій таблиці, а її розширення і копії записуються в різні області флеш-пам'яті. До того ж завдяки індексації на NTFS пошук виконується швидше.

Інша проблема, з якою стикається більшість користувачів, - на розділ з FAT32 неможливо записати файл більше 4 Гбайт. Причина полягає в тому, що в FAT32 розмір файлу описується 32 бітами в таблиці розміщення файлів, а 2 ^ 32 (мінус одиниця, якщо бути точним) якраз дають чотири гіга. Виходить, що на свіжокуплені флешку можна записати ні фільм в нормальній якості, ні образ DVD.

Копіювання великих файлів ще півбіди: при спробі зробити це помилка хоча б видно відразу. В інших ситуаціях FAT32 виступає в ролі бомби уповільненої дії. Наприклад, ти скопіював на флешку портейбл-софт і на перших порах користуєшся їм без проблем. Через тривалий час у одній з програм (припустимо, бухгалтерської або поштової) база даних роздувається, і ... вона просто перестає оновлюватися. Файл не може бути перезаписаний, оскільки досяг ліміту в 4 Гбайт.

Менш очевидна проблема полягає в тому, що в FAT32 дата створення файлу або каталогу може бути задана з точністю до двох секунд. Цього недостатньо для багатьох криптографічних додатків, що використовують тимчасові мітки. Низька точність атрибута «дата» - ще одна причина того, чому FAT32 не розглядається як повноцінна файлова система з точки зору безпеки. Однак її слабкі сторони можна використовувати і в своїх цілях. Наприклад, якщо скопіювати на тому FAT32 будь-які файли з розділу NTFS, то вони очистяться від усіх метаданих, а також успадкованих і спеціально заданих дозволів. FAT просто не підтримує їх.

exFAT

На відміну від 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, і в цій області багато правових спорів.

Btrfs

Ще один яскравий представник файлових систем на основі 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

Використання файлових систем лімітовано їх підтримкою на рівні ОС. Наприклад, Windows не розуміє ext2 / 3/4 і HFS +, а використовувати їх часом треба. Зробити це можна, додавши відповідний драйвер.

відкритий драйвер ext2fsd для читання і запису на розділи ext2 / 3 з частковою підтримкою ext4. В останній версії підтримуються екстенти і розділи обсягом до 16 Тбайт. Не підтримуються LVM, списки контролю доступу і розширені атрибути.

Монтуємо розділ ext4 в Windows 10

Існує безкоштовний плагін ext4tc для Total Commander. Підтримує читання розділів ext2 / 3/4.

Плагін для Total Commander додає підтримку ext4

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.

Змонтувавши тому ext4 в Windows, можна працювати з ним як з будь-яким іншим

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 та багато інших програм для обслуговування цієї файлової системи.

Можливості та обмеження файлових систем: зведена таблиця

Файлова система Максимальний розмір томи Граничний розмір одного файлу Довжина власного імені файлу Довжина повного імені файлу (включаючи шлях від кореня) Граничне число файлів і / або каталогів Точність зазначення дати файлу / каталогу Права доступу Жорсткі посилання Символьні посилання Миттєві знімки (snapshots) Стиснення даних в тлі Шифрування даних в тлі Дедуплікація даних 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 байт) 255 символів Unicode (UTF-16) 32760 символів Unicode, але не більше 255 символів в кожному елементі 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 так так так так так так