Файловая система f2fs что это
Файловая система f2fs и Ubuntu 13.10
Алексей Федорчук
Ubuntu’вы страсти, 12.06.2013
Файловая система f2fs (Flash-Friendly File System — “Дружественная к Флэшкам Файловая система”) разработана специально для размещения на SSD и тому подобных твердотельных носителях информации. Она штатно поддерживается ядром Linux, начиная с версии 3.8.0 — той самой, которая входит в состав Ubuntu 13.04.
В принципиальной поддержке f2fs легко убедиться командой
в выводе которой мы увидим модуль
Однако по умолчанию он не задействован. Поэтому можно попытаться загрузить его обычным образом:
Попытка будет успешной, о чём нам сообщит команда
Интересно, что при этом вывод команды
будет по прежнему пуст. И после перезагрузки никакого намёка на этот модуль не обнаружится. Так что нужно обеспечить его загрузку на старте системы вручную. Для этого достаточно в файл /etc/modules добавить строку
Что можно сделать от лица суперпользователя либо в текстовом редакторе, либо последовательностью команд типа
Как нетрудно догадаться, этим достигается обязательность загрузки соответствующего модуля на стадии инициализации системы.
Однако от самой по себе поддержки любой файловой системы мало радости, если нет соответствующих инструментов для работы с ней. А для работы с f2fs их у нас в Ubuntu пока нет.
Впрочем, и получение этого инструментария — труд не великий. И заключается он в проверке доступности репозитория universe с последующей командой
Создание f2fs на разделе или raw-устройстве выполняется обычным образом:
в ответ на что последует такой вывод:
Приведённый пример относится к флэшке, почему и мы и видим сообщение об отсутствии поддержки TRIM — на любом современно SSD его, ясное дело, не будет.
После создания файловой системы f2fs возникает естественное желание опробовать её в деле. Для чего желательно её примонтировать куда-либо. Автоматически системой она не опознаётся, не смотря на обеспечение загрузки нужного модуля. То есть, в отличие от других файловых систем на внешних носителях, по умолчанию её не видно в файловых менеджерах типа Nautilus или Thunar.
К сожалению, разместить на f2fs корень файловой иерархии в настоящий момент нельзя. В инсталляторе Ubuntu такой возможности не предусмотрено. А «обходные пути», подобные тем, что применяются при установке с корнем на ZFS, упираются в то, что grub-probe не опознаёт f2fs, и никаких «корректировщиков», подобных GRUB for Native ZFS, пока (?) не существует.
Оставьте комментарий Отменить ответ
Для отправки комментария вам необходимо авторизоваться.
Как ускорить Android в пару шагов (переход на файловую систему F2FS)?
Возможно вы уже видели множество инструкций которые РЕАЛЬНО могут ускорить ваш Android, но есть кое-что, что действительно может заставить смартфон или планшет работать быстрей.
О чем речь?
Большинство материалов в сети по ускорению Android, являются не более чем пылью в глаза и реальной пользы не приносят, оставшиеся инструкции довольно сложные для усвоения и иногда не приносят того эффекта как от них ожидалось.
В 2012 году компания Samsung разработала принципиально новую файловую систему под названием F2FS. Ее главное преимущества над другими заключается в том, что она разработана изначально для флеш-памяти.
По итогу многих тестов файловая система F2FS превосходит по производительности используемую в в Android EXT4, ознакомиться с детальными результатами можно на сайте Opennet или форуме XDA.
Необходимые инструменты
Для Вариант 1
Для Вариант 2
Инструкция по переходу на
файловую систему F2FS
Вариант 1
После выполнения процедуры, все данные будут удалены!
Вариант 2
После выполнения процедуры, все данные будут удалены!
После длительной первой загрузки появится окно приветствия где необходимо произвести первоначальную настройку смартфона или планшета и лично проверить на сколько быстрее стал работать Android!
Вот и все! Больше статей и инструкций читайте в разделе Статьи и Хаки Android. Оставайтесь вместе с сайтом Android +1, дальше будет еще интересней!
Разборки с F2FS
Нейл Браун (Neil Brown)
Перевод Алексея Федорчука. версия 2, причёсанная
Оригинал, 10 октября 2012
От переводчика. Это на сегодняшний день наиболее полное описание файловой системы F2FS. В ней рассматривается именно та её реализация, которая была передана в исходных текстах разработчикам ядра Linux (которые включили её в версию 3.8. Перед прочтением настоятельно рекомендуется ознакомиться с работой Валерии Авроры про log-структурированные файловые системы, иначе кое-что здесь будет не понятно — вне зависимости от степени владения (или не владения) английским.
Когда техно-гик получает новую игрушку, у него всегда появляется желание разобрать её и посмотреть, как она работает. Это побуждение на практике иногда получается подавить, но в конкретном случае с F2FS для данного гика желание оказалось слишком сильным. Так что всё нижеследующее является результатом разборки с этой новой файловой системой на предмет посмотреть, как она работает.
F2FS — это «Дружественная к Флэшкам Файловая система» (flash-friendly file system), новая файловая система для Linux, недавно анонсированная инженерами Samsung. В отличие от jffs2 и LogFS, F2FS ориентирована не на твердотельные накопители как raw-устройства, а на обычные носители типа SSD, eMMC, SD-карты и другие — те, что уже имеют встроенный FTL (Flash Translation Layer). В ответ на то, что «железо» становится умнее, мы должны разрабатывать ещё более умный софт для управления им, то есть «умный в превосходной степени». Похоже на воспитание, не так ли?
F2FS основана на дизайне log-структурированной файловой системы (LFS), что неудивительно, учитывая требования флэш-накопителей. Для тех, кто не знаком с log-структурированным дизайном, перечислю его основные элементы:
Поскольку FTL обычно использует log-структурированный дизайн для обеспечения требуемых флэшками выравнивания износа и отложенной записи, это означает, что существует две активных log-структуры — одна в прошивке и одна в операционной системе. F2FS разработана с учётом этого и оставляет большинство задач FTL, занимаясь в основном повышением производительности. Так, например, F2FS не занимается распределением записи для выравнивания износа.
Особенность F2FS, оправдывающая её название как Дружественной к Флэшкам, — то, что она собирает блоки в отдельные куски, которые будут записаны одновременно и последовательно, что ей сделать легче, чем FTL. Вместо создания одного большого куска для записи, F2FS фактически создаёт до шести параллельно записываемых кусков. Как мы увидим, при этом создаются различные виды блоков с различным сроком существования. Группировка блоков с похожими характеристиками предназначена для облегчения требуемой LFS «сборки мусора» (garbage collection).
«Масштабируемость» является важным качеством — F2FS не всегда записывает непрерывными потоками, но к этому стремится. Некоторые метаданные, а иногда даже некоторые данные, записываются случайными единичными блоками. Это было бы неприемлемо для обычной log-структурированной файловой системой, но F2FS позволяет избежать сложности, делая небольшие обновления при необходимости, оставляя остальную работу FTL.
Прежде чем перейти к подробностям того, как F2FS делает то, что делает, дадим список того, что она не делает.
Так, от файловой системы copy-on-write мы могли бы ожидать «дешёвых» снапшотов, за счёт сохранения старой копии. F2FS не даёт такой возможности, и не способна на это в ее нынешнем виде из-за сохранения метаданных в двух местах, что будет подробно описано позже.
Среди других отсутствующих функций — квоты, экспорт NFS, расширенные атрибуты (xattrs). Все они могут быть добавлены при необходимости, хотя включение квот с правильным восстановлением после сбоев будет сложным. Однако их появление в будущих релизах нас не удивит.
Блоки, сегменты, секции и зоны
Подобно большинству файловых систем, F2FS состоит из блоков. Все блоки имеют размер 4 КБ, хотя он неявно связан с размером системной страницы. Так что для архитектур IA64 и PowerPC это вряд ли будет верно. Адресация блоков 32-битная, так что общее количество адресуемых байт в файловой системе не более 2 (32+12) байт, или 16 терабайт. Для нынешних объёмов флэш-накопителей это не является существенным ограничением.
Блоки собираются в сегменты, состоящие из 512 блоков — размером 2 МБ. Документация описывает это как умолчание (которое можно изменить), но этот размер довольно глубоко встроен в код. Каждый сегмент содержит резюмирующий блок, содержащий список принадлежности каждого блока в сегменте (файла плюс смещение). Резюме в основном используется при очистке, для определения, какие блоки нуждаются в перемещении и как после этого должны обновляться иноды. В одном резюмирующем блоке могут комфортно размещаться данные для обычных 512 блоков (оставляя немного дополнительного пространства для других целей), так что 2 МБ — естественный размер сегмента. Больше было бы непрактично, меньше — расточительно.
F2FS имеет шесть секций, открытых для записи, в каждую из которых в любое время могут записываться различные виды данных. Различные секции позволяют хранить содержимое файлов отдельно от инодов, а также разделять их на «горячие», «теплые» и «холодные» в соответствии с изменяемой эвристикой. Например, каталоги рассматриваются как «горячие», и хранятся отдельно от файлов данных, поскольку они имеют разную «продолжительность жизни». «Холодные» данные, как ожидается, останутся неизменными в течение достаточно долгого времени, так что секции, заполненные «холодными» блоками, скорее всего, не потребуют очистки. Иноды, определённые как «горячие», согласно ожиданиям, будут обновляться в ближайшее время, так что по прошествии короткого времени секция, заполненная «горячими» инодами, будет содержать очень мало «живых» блоков, и, следовательно, легко очищаться.
Секции объединяются в зоны. Они могут содержать любое целое число секций, хотя по умолчанию опять-таки одну. Единственная цель зон — попытаться сохранить шесть открытых секций в разных частях устройства. Теоретически представляется, что флэш-устройства часто образованы из ряда отдельных суб-устройств, каждое из которых может обрабатывать запросы ввода-вывода независимо друг от друга и, следовательно, параллельно. Если зоны размечены так, чтобы выстроиться в линию с суб-устройствами, то шесть открытых участков могут быть открыты для параллельной записи, обеспечивая оптимальное использование устройства.
Эти зоны, заполненные секциями сегментов из блоков, составляют «главную область» файловой системы. Существует также «мета-область» файловой системы, которая содержит различные метаданные, такие как уже упомянутые резюмирующие блоки. Эта область не управляется обычными log-структурными линиями и, таким образом, оставляет больше работы для FTL. Она достаточно мала, так что это не создаёт проблем.
Существует три способа управления записью в этой области. Во-первых, небольшое количество данных предназначено только для чтения (суперблок), которое никогда не перезаписывается после создания файловой системы.
Во-вторых, имеются уже упоминавшиеся резюмирующие блоки. Они просто обновляются на месте. Это может привести к неопределённости в отношении «правильного» содержания блока после сбоя, однако для резюмируемого сегментна это не существенно. Информация в нем перед использованием проверяются на валидность, и в случае её повреждения она извлекается в процессе восстановления из других источников.
Третий способ — выделение удвоенного объёма на каждый блок в двух различных местах, так что он состоит из двух экземпляров, первичного и вторичного. Из них только один является «живым» в данное время, а «не-живой» просто обновляется после copy-on-write по запросу LFS. Этот подход к метаданным является главным препятствием для создания снапшотов. F2FS журналирует небольшое количество обновлений в этой группе при создании точек проверки (checkpoint), которые могут несколько облегчить задачи FTL.
Файлы, иноды и индексирование
Большинство современных файловых систем используют B-деревья или аналогичные структуры для управления индексами при поиске блоков файла. Для btrfs B-деревья столь важны, что этой структуре данных она обязана своим названием. Для F2FS это не так.
Многие файловые системы уменьшают размер индекса с помощью «экстентов», использующих начало и длину списка блоков вместо списков всех их адресов в явном виде. Опять же, в F2FS этого нет (хотя один экстент на инод поддерживается для «подсказки»).
В F2FS используется дерево индексов, которое очень напоминает оригинальную файловую систему Unix и её потомков, например ext3. Индексный дескриптор (инод) содержит список адресов начальных блоков файла, некоторые адреса косвенных блоков (которые сами по себе содержат дополнительные адреса), а также некоторых вторичных и третичных косвенных блоков. Если ext3 содержит 12 прямых адресов и по одному на каждый из косвенных адресов, то в F2FS имеется 929 прямых адресов, по два косвенных и дважды косвенных адреса, и один третичный косвенный адрес. Это позволяет адресовать для одного файла почти 4 ТБ, или четверть максимального размера файловой системы.
Очевидно, что все это требует немного большего размера инода, чем таковой в ext3. Копирование при записи весьма неудобно для объектов, которые меньше, чем размер блока, так что F2FS резервирует для каждого инода полный блок в 4 КБ, обеспечивая достаточно пространства для индексирования. Здесь остаётся даже место для хранения (базового) имени файла, или одного из его имен, вместе с инодом родительского файла. Это упрощает восстановление недавно созданных файлов во время восстановления после сбоя и уменьшает количество блоков, которые должны быть записаны для такого файла для его сохранности.
Учитывая, что индексный дескриптор настолько велик, можно было бы ожидать, что небольшие файлы и, конечно, небольшие символические ссылки будут храниться непосредственно в индексном дескрипторе. Однако F2FS не делает этого — скорее всего, ещё не делает. Это достаточно легко добавить при оптимизации, так что скорее всего такая фича скоро появится.
Как уже упоминалось, индексный дескриптор содержит один экстент, который представляет собой резюме части дерева индекса. Он говорит, что некоторый диапазон блоков в файле является непрерывным на устройстве и дает адрес этого диапазона. Файловая система пытается сохранить наибольший экстент из здесь записанных, и использует его, чтобы ускорить поиск адреса. В общем случае файл записывается последовательно без каких-либо существенных разрывов, в результате весь файл находится в одном экстенте, что делает поиск в дереве индекса ненужным.
Удивительно, но, кажется, в иноде не нашлось достаточно места для хранения 64-разрядной временной метки, так что вместо запаса в несколько веков на будущее при наносекундном разрешении, обеспечивается только запас до 2038 года при односекундном разрешении. Этот просчёт был отмечен в рассылке LWN http://lwn.net/Articles/519032/ и может быть исправлен в будущих релизах.
Одной из неудобных особенностей любой файловой системы с copy-on-write является то, что всякий раз при записи блока его адрес изменяется, так что его родитель в индексном дереве должен измениться и переместиться, и так далее, вплоть до корня дерева. Журналируемая природа LFS означает, что прокрутка вперёд во время восстановления может восстановить последние изменения в индексации дерева, так что все изменения не должны записываться сразу. Но в конце концов они должны быть записаны, что увеличивает работу при чистке.
Это еще одна область, в которой F2FS использует лежащий в его основе FTL. Среди содержимого «мета-области» имеется NAT (Node Address Table) — таблица адресов узлов. Здесь слово «узел» относится к инодам и косвенно индексируемым блокам, а также к блокам, используемым для хранения расширенных аттрибутов (xattr). Когда адрес инода хранится в каталоге, или индекс блока хранится в иноде или ином индексе блока, это не блок хранимых адресов, а смещение в NAT. Фактический адрес блока хранится в NAT по этому смещению. Это означает, что, когда блок данных записан, мы все еще нуждаемся в обновлении и записи узла, который указывает на это. Но запись этого узла требует только обновления начала NAT. NAT является частью метаданных, он использует два местоположения журнала (которые зависят от FTL для сбора записи), и поэтому не требует дальнейшей индексации.
Каталоги
Оригинальная файловая система Unix (когда она стала поддерживать 256-байтные имена файлов) использовала ту же схему каталогов, что и ext2 — последовательный поиск файлов среди всех записей каталога. Это просто и эффективно, но не очень хорошо масштабируется на большие каталоги.
Более современные файловые системы, такие как ext3, XFS, btrfs, использующие различные схемы, включающие B-деревья, иногда индексированные по хэшу имени файла. Одна из проблем с B-деревьями заключается в том, что иногда узлы должны быть разделены, и некоторые записи каталога могут быть перемещены в файл. Это создаёт дополнительные проблемы обеспечения стабильного адреса для telldir () и, вероятно, причиной того, что telldir () часто называют убогим интерфейсом.
Легче всего представить структуру каталогов в виде серии хэш-таблиц, последовательно хранимых в файле. Каждая хэш-таблица имеет ряд довольно больших «корзин». Поиск проходит от первой хэш-таблицы в следующую, на каждом этапе происходит линейный поиск через соответствующую «корзину», пока либо имя не будет найдено, либо последняя хэш-таблица не будет просмотрена. Во время поиска любое свободное пространство в подходящей «корзине» записывается и в случае необходимости получает имя.
Первая хэш-таблица имеет только одну «корзину» размером в два блока по размерам, для первых нескольких сотен записей, используемых при простом линейном поиске. Вторая хэш-таблица имеет две»корзины», потом четыре, потом восемь и так далее, до 31-й таблицы, имеющей около миллиарда «корзин», каждая размером в два блока. Последующие хэш-таблицы — если вам требуется их так много — все имеют одинаковое количество «корзин», как 31-й таблице, но теперь они имеют размер в четыре блока.
Суперблоки, точки проверки и другие метаданные
Все файловые системы имеют суперблок, и F2FS не исключение. Однако в ней делается четкое различие между теми частями суперблока, которые предназначены только для чтения и теми, которые могут изменяться. Они хранятся в двух отдельных структурах данных.
Ранее мы уже упоминали таблицы адресов узлов (NAT) и область резюме сегмента (SSA), которые также входят в «мета-область» наряду с суперблоком (SB) и точками проверки (CP). Ещё один элемент метаданных называется таблицей информации о сегментах — SIT (Segment Info Table).
SIT содержит 74 байт на сегмент и хранится отдельно от резюме сегмента, потому что он намного более изменчив. В первую очередь в нём отслеживается, какие блоки все еще находятся в активном использовании, потому что сегмент может быть повторно использован, когда он не имеет активных блоков, или может быть очищен, когда количество активных блоков низко.
Когда для NAT или SIT требуются обновления, F2FS не делает их немедленно, но хранит их в памяти до записи следующей точки проверки. Если обновлений относительно немного, то они не записываются в их окончательное «место обитания», но вместо этого журналируются в некоем свободном пространстве в резюме сегмента блоков, которые записываются в это время. Если общее количество обновлений, требуемых для резюме сегмента блоков, достаточно мало, даже если они еще не записаны, то обновления SIT, NAT и SSA журналируются в блоке точки проверки, который всегда записывается в неё. Таким образом, когда F2FS свободна для некоторой работы, которую она могла бы оставить FTL, она старается быть дружелюбной и выполняет только случайные обновления блока, когда это действительно нужно. Когда F2FS требуются многочисленные случайные обновления блока. она будет выполнять несколько из них одновременно, чтобы хоть немного снизить нагрузку на FTL.
Знать, когда завязывать
Обработка условий в традиционных файловых системах сравнительно легка. Если места не осталось, вы просто получаете сообщение об ошибке. С log-структурированными файловыми системами всё не так просто. В них может быть много свободного пространства, но оно может быть в разных секциях и потому не может быть использовано до их очистки, то есть более плотной упаковки данных в меньшем количестве секций. Она, как правило, имеет смысл, потому что log-структурированная файловая система всегда имеет свободные участки, куда можно скопировать данные для очистки.
FTL принимает именно такой подход, обеспечивая как очистку, так и защиту от чрезмерного износа. Это FTL обрабатывает внутри, и заниматься этим F2FS смысла нет. Поэтому F2FS просто производит запись везде, где это возможно. Таким образом, можно ожидать деградации производительности F2FS при её заполнении, но это является общей чертой многих файловых систем, так что тут нет большого сюрприза.
Обзаведусь ли ею я?
F2FS включает ряд оптимизаций, направленных на облегчение нагрузки на FTL. Было бы очень полезно выяснить, насколько они фактически приводят к сокращению числа операций записи. Это поможет подтвердить, что оптимизация полезна или, напротив, не требуется. Так, сбор статистики о том, как часто «выстреливают» различные оптимизации, поможет укрепить уверенность в файловой системе.
F2FS кажется, была написана без особого расчёта на распараллеливание рабочих нагрузок. В частности, все представления запросов на запись осуществляется в рамках единого семафора. Так, вероятно, F2FS — это не файловая система для обработки больших объёмов данных на 256-ядерной «рабочей лошадке». Однако она должна прекрасно показывать себя на мобильных устройствах еще немало лет.
Между тем, я бы использовал F2FS? Учитывая, что мой телефон является столь же игрушкой, сколь и рабочим инструментом, подозреваю, что да. Правда, перед этим в первую очередь я хотел бы убедиться в наличии надёжных бэкапов. Но потом… Я, вероятно, всё равно сделаю это.
Файловая система F2FS ускорит флэшки и продлит им жизнь
Linux для хакера
В списке рассылки разработчиков ядра Linux представлен патч с поддержкой новой журнально-структурированной файловой системы F2FS (Flash-Friendly File System), а также соответствующая программа mkfs.f2fs для форматирования разделов.
Файловая система F2FS предназначена для более эффективной работы с флэш-памятью NAND, которая широко используется в устройствах вроде SSD, eMMC и SD-картах. В наше время флэш-память используется повсеместно: от мобильных телефонов до серверов.
Дело в том, что у микросхем NAND есть специфические особенности, которые отличают её от традиционных магнитных накопителей с вращающимися дисками. Самое главное отличие — это ограничение на количество циклов записи-считывания. Есть и другие особенности, связанные с внутренней геометрией расположения чипов в носителе и работой контроллера. Естественно, файловая система должна учитывать эти особенности и максимально бережно относиться к носителю, путём равномерного распределения нагрузки. Журнально-структурированная (log-structured) файловая система предполагает, что все данные записываются последовательно и никогда не перезаписываются. Для очистки старого «мусора» используется отдельная процедура. В этом принципиальное отличие от журналируемых файловых систем, которые не слишком подходят для работы с флэш-памятью.
Напомним, что предыдущая журнально-структурированная файловая система LogFS c учётом особенностей флэш-памяти была представлена 16 мая 2010 года и включена в ядро Linux 2.6.34. До LogFS были UbiFS и Yaffs2. Однако, создатели F2FS постарались превзойти всех предшественников. Их разработка работает через FTL (интерфейс управления флэш-памятью на микросхеме), поддерживает разные алгоритмы для размещения файлов и разные алгоритмы очистки.
Новая файловая система F2FS разработана и передана в open source компанией Samsung, крупнейшим в мире производителем микросхем NAND. В первую очередь F2FS предназначена для использования в Android-смартфонах, где до сих пор часто встречается файловая система Ext4. Система F2FS превосходит Ext4 по работе с флэш-памятью в большинстве бенчмарков.
Конечно, ничто не мешает использовать F2FS на десктопе или сервере. Для форматирования раздела под F2FS достаточно выполнить следующие команды:
Файловые системы Linux в 2020 году: плюсы, минусы, подводные камни
Как вы знаете, перед установкой любой операционной системы Linux вам нужно отформатировать жесткий диск и выбрать наиболее предпочтительную файловую систему. Тут у нас, в 2020, в фаворитах ходит EXT4, и она кажется лучшим вариантом из возможных, но давайте рассмотрим альтернативы, прежде чем слепо отказываться от них?
«Fourth Extended Filesystem», что дословно переводится как «Четвертая расширенная файловая система» полностью обратно совместима с EXT2 и EXT3 и считается стандартом для большинства дистрибутивов Linux, оставаясь такой же популярной, как и ее предшественники.
На сегодняшний день это один из самых безопасных и стабильных вариантов, поскольку он поддерживает ведение журнала, предотвращая (насколько это возможно) потерю данных после сбоя системы или потери питания.
Двумя мощнейшими функциями EXT4 являются так называемые «экстенты» и «отложенное распределение», которые разумно управляют тем, как данные записываются на носитель, для повышения производительности и уменьшения фрагментации.
BtrFS
«b-tree file system» изначально была разработана Oracle и продолжает расти в популярности, так что многие считают ее истинным преемником династии EXT.
Btrfs поставляется с расширенными функциями, такими как автоматическая дефрагментация и прозрачное сжатие. Он следует принципу копирования при записи, сохраняя новые итерации данных и метаданных вместо того, чтобы воздействовать на существующие («теневое копирование»). Это также позволяет делать снимки различных состояний файловой системы, а также легко реплицировать, переносить и инкрементировать резервные копии. Оперативные и автономные проверки файловой системы еще больше снижают вероятность потери данных.
Отдельно стоит отметить, что BtrFS весьма SSD-френдли, поскольку она автоматически отключает свои функции, которые полезны для механических жестких дисков, но могут изнашивать SSD.
XFS была создана Silicon Graphics почти три десятилетия назад для их графических рабочих станций, специализирующихся на рендеринге 3D-графики.
Однако, её поддержка журналирования ограничена, особенно если сравнивать с более современными альтернативами, и, возможно, она более склонна к потере данных. Также плохо масштабируется для более типичных повседневных и, в основном, однопоточных сценариев, например, при удалении нескольких фотографий из папки «Изображения». Другими словами, это история про настройку собственного дата-центра, а не обычной домашней машины.
Одна из (относительно) более новых файловых систем, «Flash-Friendly File System», как следует из самого названия, является одним из лучших вариантов для использования с хранилищем на основе флешь-памяти.
Изначально созданный для этой цели компанией Samsung, F2FS разбивает носитель на более мелкие части, которые в свою очередь делит на еще более мелкие части, которые в свою очередь делит, ну вы поняли. А дальше она старается использовать множество этих зон вместо повторного использования одних и тех же. В сочетании с поддержкой TRIM / FITRIM это делает её более удобной для флешь-носителей с ограниченным числом операций записи.
Нет смысла углубляться в возможности F2FS, потому что, если речь идет об использовании с обычными носителями, она – абсолютно заурядная заурядность, не выделяющаяся ни в отношении скорости, ни в отношении безопасности, и любая другая файловая система предложит вам набор функций получше. Хотя, стоит отметить, что дискуссия принимает совершенно другой оборот, когда речь заходит за флешь-хранилища, для которых она и разрабатывалась.
OpenZFS/ZFS
ZFS отличается от всех альтернатив тем, что сочетает файловую систему с менеджером томов. По этой причине он управляет не только файлами и каталогами, но и физическими носителями, на которых они находятся. Благодаря этому каждое устройство хранения может быть назначено пулу, который обрабатывается как один ресурс. Если вам не хватает места, вы можете добавить новое хранилище в этот пул, чтобы расширить его, позволяя ZFS позаботиться о деталях.
ZFS также следует принципу copy-on-write, так называемого, копирования при записи, где вместо изменения существующих данных он сохраняет только изменения («дельты») между старой и новой версиями. Это обеспечивает прозрачное, интеллектуальное хранение нескольких копий данных, не занимая много места, которое может работать как резервное копирование или снэпшоты. Пользователь может откатиться к предыдущим состояниям файловой системы, отменить изменения или наоборот: перенести все изменения в клоны существующих данных.
Журналируемая файловая система от IBM была одной из первых файловых систем, которая поддерживала журналирование, что привело к снижению вероятности потери данных. Она использует экстенты, как и многие другие современные альтернативы, а также группы размещения, такие как XFS, с целью обеспечения высокой производительности чтения / записи.
Не отдавая предпочтения какой-либо одной функции, она отлично подходит для различных задач при разных нагрузках.
К сожалению, это также означает, что она не является превосходной ни в одной. Кроме того, есть кое-какие проблемы, которые негативно влияют на оценку пользователей при выборе файловой системы для своего хранилища. Например, она может отложить обновление своего журнала на неопределенное время, увеличивая вероятность потери данных и почти сводя на нет тот факт, что это файловая система журналирования. Лучше параллельные записи, которые наиболее полезны для серверов и больших баз данных, но работают хуже, чем EXT4 в более популярных сценариях использования настольных компьютеров.
Это, вероятно, причины, по которым она не так популярна, как другие файловые системы, которые либо быстрее работают, либо лучше защищают данные от потери.
Что вам стоит использовать?
Если вы не боитесь иметь дело с несколько менее зрелой экосистемой, вам стоит также рассмотреть BtrFS.
Для использования на сервере, где вы хотите полностью исключить любую возможность потери данных, там, где стабильность – второе имя, вам стоит попробовать ZFS. Впрочем, чтобы смочь использовать ее на всю катушку, вам придется уйти в чтение с головой.
Для флэш-носителей F2FS является лучшим вариантом, это даже не обсуждается.
Какую бы файловую систему вы ни выбрали, не забудьте заранее полностью стереть ваш жесткий диск, если вы хотите сделать его существующий контент практически не восстанавливаемым.
Не забывайте использовать комментарии, чтобы высказать ваше ценное мнение по поводу файловых систем и статьи в общем.