64-битные иноды, атомарные транзакции, метки времени в наносекундах, клонирование директорий, встроенное шифрование
На вчерашней презентации WWDC 2016 компания Apple показала новые версии операционных систем macOS (Sierra) 10.12, iOS 10, tvOS 10, watchOS 3, приложение для обучения детей программированию Swift Playgrounds и новые эмодзи.
Казалось бы, ничего интересного. Однако, Apple всё-таки выкатила кое-что фундаментальное. Самая значительная разработка из всего упомянутого на презентации — это файловая система нового поколения Apple File System (APFS) в операционной системе macOS (Sierra) 10.12.
На сайте для разработчиков вскоре после презентации опубликована документация с основными характеристиками и описанием файловой системы, которая повторяет отдельные функции мощной свободной файловой системы ZFS.
Сейчас в компьютерах Apple используется файловая система HFS+, расширенная версия HFS (Hierarchical File System, иерархическая файловая система), созданной более 30 лет назад. Подобно своей предшественнице, HFS+ использует древовидную структуру, называемую B*-дерево, для хранения большей части метаданных. Отсюда и название «иерархическая файловая система».
Официальное представление HFS+ состоялось 19 января 1998 года, вместе с MacOS 8.1. С 2002 года в системе реализовано журналирование для повышения надёжности хранения информации. С версии OS X 10.3 журналирование включено по умолчанию, появилась возможность работать в режиме с учётом регистра имён.
Вплоть до версии OS X 10.7 разработчики продолжали дорабатывать HFS+ и реализовывать на уровне файловой системы новые функции для OS X. Но факт остаётся фактом: HFS изначально разрабатывалась во времена флоппи-дисков и крутящихся винчестеров, когда размеры файлов измерялись в килобайтах или мегабайтах. Сегодня многие работают с накопителями SSD, где хранятся миллионы файлов — гигабайты или терабайты данных. К файловой системе выдвигаются совершенно иные требования. Вместо доработки старого кода компания Apple решила наконец-то написать новую файловую систему с нуля.
Файловая система APFS нового поколения пока находится на стадии developer preview, то есть её не планируется выкатывать в массовое использование в ближайшее время. В данный момент нельзя использовать том APFS как загрузочный диск, его также нельзя применять в системе резервного копирования Time Machine, в Fusion Drive или с шифрованием File Vault. Но можно для обычного незагрузочного тома.
Предстоит ещё долгая доработка и тестирование, но уже потом APFS станет основной файловой системой Apple на десятилетия вперёд.
APFS, в отличие от HFS+, изначально различает регистр символов в названиях файлов и папок, и эту функцию нельзя отключить. Это следует иметь в виду всем, кто решит использовать APFS.
В принципе, Apple рекомендует для начала поэкспериментировать с APFS на внешнем накопителе, на котором не хранится ничего важного. Для этого предлагается использовать утилиту hdiutil.
Основные характеристики
В официальной документации перечислены общие характеристики файловой системы APFS в сравнении с HFS+.
Контейнеры и тома
Контейнер — это основной объект для хранения данных в APFS. Конейнеры обычно полностью совпадают с записями GUID Partition Table (GPT), у них собственная схема защиты от сбоев и распределения дискового пространства. Каждый контейнер содержит один или больше томов или файловых систем, в каждой из которых есть собственное пространство имён, то есть набор файлов и директорий.
APFS напрямую не поддерживает программный RAID, но её можно использовать с томами Apple RAID для поддержки Striping (RAID 0), Mirroring (RAID 1) и Concatenation (JBOD).
64-битные индексные дескрипторы (inode)
64-битные иноды значительно увеличивает пространство имён, по сравнению с 32-битными индентификаторами в HFS+. В 64-битной файловой системе APFS поддерживается более 9 квинтиллионов файлов на каждом томе. Этого должно хватить каждому, как говорил Билл Гейтс.
Наносекундные метки времени
В APFS значительно увеличена точность меток времени (таймстампов). APFS поддерживает установку меток времени с точностью до наносекунды. Для сравнения, в HFS+ метки времени выставлялись с точностью до секунды.
Наносекундные таймстампы очень важны в современных файловых системах, потому что они помогают реализовать атомарности и атомарных транзакций — одного из основных требований ACID к транзакционной системе (например, к СУБД). Атомарность гарантирует, что никакая транзакция не будет зафиксирована в системе частично. Будут либо выполнены все её подоперации, либо не выполнено ни одной.
Защита от сбоев
В APFS реализована инновационная схема метаданных copy-on-write, которую Apple называет «защитой от сбоев» (“Crash Protection”). Она гарантирует, что изменения в файловой системе и записи в журнал остаются в синхронизированном виде, если что-то происходит во время записи — например, пропадает электропитание.
Схема copy-on-write в ZFS
Разреженные файлы (sparse files)
Файл с атрибутом «разреженный» предполагает содержание блоков нулевых байт, не хранимых на накопителе, а подразумеваемых. В HFS+ не было поддержки разреженных файлов.
Расширенные атрибуты
APFS имеет встроенную поддержку расширенных файловых атрибутов, которая в HFS+ реализовалась через файл Attributes, то есть через B-дерево.
Шифрование
Apple заявляет, что шифрование является фундаментальным свойством, которое встроено в APFS на уровне файловой системы. Для каждого тома в контейнере APFS устанавливается одна из моделей шифрования: без шифрования, шифрование с одним ключом, шифрование с несколькими ключами. В последнем случае отдельные ключи применяются для шифрования файлов и метаданных. В зависимости от оборудования, APFS использует режим шифрования AES-XTS или AES-CBC.
Клонирование файлов и директорий
Клонирование — практически мгновенное копирование файла или директории, при котором не требуется дополнительное место для хранения данных. При модификации клона файловая система записывает только изменение данных. Таким образом, новая файловая система может хранить много версий больших файлов, отнимая меньше дискового пространства.
Снапшоты
Снапшоты — открытые только для чтения «слепки» файловой системы в томе. Операционная система может использовать снапшоты для более эффективной процедуры резервного копирования. То есть наконец-то Time Machine будет работать нормально (быстро).
Конечно, по своим возможностям APFS значительно уступает 128-битной файловой системе ZFS, которую поддерживают Linux, FreeBSD и другие свободные ОС, но со стороны Apple это шаг в правильном направлении.
Странно, что в предварительной документации не упомянута функция компрессии, которую HFS+, кстати, поддерживает.
Apple долго пыталась перенести ZFS на систему OS X, по этому поводу велась активная дискуссия в списках рассылки ZFS, были опубликованы предварительные снапшоты для следующей версии OS X. Позже была сделана реализация OpenZFS для OS X (O3X) и MacZFX.
Файловая система ZFS распространяется с открытым исходным кодом, и Apple вполне могла позаимствовать некоторые идеи для файловой системы APFS. Реализация open source для APFS пока не готова, компания Apple планирует опубликовать задокументировать и опубликовать формат APFS в 2017 году.
На конференции WWDC сегодня вечером состоится первая формальная сессия, где разработчикам более подробно продемонстрируют новые возможности APFS.
Комментарии (62)
Foolleren
14.06.2016 13:32не получилось бы как с ReFS когда один резет превращает весь раздел в тыкву.
alexmay
14.06.2016 13:51у… поддержка регистрозависимых имен файлов… ((
tmteam
14.06.2016 14:09Зачем?
Foolleren
14.06.2016 14:14+3Что бы жизнь мёдом не казалась.
Bozaro
14.06.2016 21:58+3Надо отметить, что регистронезависимое сравнение, строго говоря, зависит от локали.
Например, в Турции:UPPER("windows") = "WINDOWS", а не"WINDOWS", как в большей части света.
Очень занимательно посмотреть, какие символы считаются одинаковыми при регистронезависимом сравнении в MySQL: http://collation-charts.org/mysql60/mysql604.utf8_general_ci.european.html
0xcffaedfe
14.06.2016 14:29+2А то что основная масса FS регистрозависимые, вас не смущает? В быту регистронезависимые имена файлов доставляют не мало проблем, по краней мере для меня.
alexmay
14.06.2016 14:46+1Ага. регистрозависимые имена файлов — вот восторг!
file1.txt (l — мелкая L)
fiIe1.txt (I — заглавная i)
alexmay
14.06.2016 14:52+1продолжу жаловаться.
Пользователи присылают мне в ПО(робот) файлы по электронной почте. Файлы наименованы: OMSK.xls, Ufa.xls, Moscow.xls
Пользователи именуют файлы не обращая внимания на регистр. Т.е. сегодня может быть OMSK.XLS, завтра Omsk.xls, послезавтра omsk.xls
Может я неправ, конечно, но регистронезависимая ФС избавляет меня от операции приведения имен файлов к единому регистру и облегчает отладку\работу
В чем смысл регистрозависимой фс — не могу понять, ну честно. Только в том, что в именах файлов можно использовать camelStyle?
textFile1.txt и TextFile1.txt
Meklon
14.06.2016 15:17+2Пользователи просто из-под винды шлют файлы. А NTFS — одна из немногих ФС с такой фигней. Я как-то привык уже на EXT4 к регистрозависимости. Хотя явных плюсов того или другого подхода привести не могу.
tmteam
14.06.2016 15:34-2Нужна веская причина для усложнения UX того или иного продукта. Иными словами — бритва окамма. Для меня, как программиста, до сих пор большим вопросом является регистро-зависимый синтаксис С. Хорошо что IDE помогают в этом, и тут даже появляются некоторые плюсы, но в целом? Я подозреваю что это было изначально сделано, чтобы парсерам было прощще, а потом все просто привыкли к этому. Итого вопрос — зачем создают сложности, там где их можно избежать? Мне в spotlight теперь придётся искать файл с учётом заглавных букв?
alexmay
14.06.2016 15:44+1в спотлайте будет бардак… так что — именно так… ((
В идеале то, как сделано в MacOX сейчас, как мне кажется
— представление файла (в его паспорте) — регистрозависимое, представление в фс — регистроНЕзависимое.
В итоге — пользователю легко именовать файлы так, как ему вздумается, и разработчику — легко их искать.
Примерно так:
bash-3.2$ cd
bash-3.2$ touch file1.txt
bash-3.2$ touch fiIe1.txt
bash-3.2$ touch fiLe1.txt
bash-3.2$ ls -l fi*.txt
-rw-r--r-- 1 alexandre staff 0 14 июн 17:40 fiIe1.txt
-rw-r--r-- 1 alexandre staff 0 14 июн 17:40 file1.txt
bash-3.2$ cat fiie1.txt
bash-3.2$ echo sample > fiie1.txt
bash-3.2$ cat fiie1.txt
sample
bash-3.2$ cat fiIe1.txt
sample
bash-3.2$ uname -a
Darwin MacBook-Pro.local 15.6.0 Darwin Kernel Version 15.6.0: Tue May 17 20:05:28 PDT 2016;
Maccimo
14.06.2016 17:33> Для меня, как программиста, до сих пор большим вопросом является регистро-зависимый синтаксис С.
Регистрозависимый синтаксис в ЯП — однозначное благо, он защищает нормальных людей от говнокодеров, которые пишут кАк иМ НРавиТсЯ. Говорю как человек, довольно долго поддерживавший коммерческое ПО, написанное на паскале, у которого синтаксис регистронезависимый.tmteam
14.06.2016 17:45Я и в си и сишарпе могу так написать. Для этого есть Code-style. Более того — видел и не раз то о чём вы говорите в наших проектах.
ad1Dima
14.06.2016 16:03а что, на маках давно по-умолчанию она регистрозавсимая? сколько себя помню, всегда были проблемы с тем, что не так файл из кода ищещь и на симуляторе все ок, а не iPhone нет ресурса.
General_Failure
14.06.2016 21:15Не знаю как сейчас, но когда-то тоже сталкивался с проблемой регистрозависимости, когда прогал под айпад.
В симуляторе пофигу, а на айпаде регистрозависимость, хотя файловая система вроде одна.
Стало интересно, полез в управление разделами в маке
И там при форматировании был параметр регистрозависимость, по умолчанию выключен.
Скорей всего до сих пор так, только проверить не могу — на рабочем маке админские права не дают
mayorovp
14.06.2016 16:42+1На самом деле, это не NTFS регистронезависимая, это винда регистронезависимая по традиции. Если для винды сделать драйвер любой другой ФС — то ее тома будут вести себя точно так же. В противном случае существующие программы могут перестать работать, и это будет ошибкой.
PS FILE_FLAG_POSIX_SEMANTICS дает поведение "как в *NIX" — к примеру, можно создать два файла, отличающиеся только регистром символов.
themtrx
14.06.2016 21:19Позвольте объяснить Вам, не в чём смысл регистрозависимой ФС (или чего угодно другого регистрозависимого), но в чём причина: всё дело в том, что 'k' и 'K' — это не буква в разных регистрах. Это два совершенно разных символа, как 'j' и 'R', как 'ы' и '$'. Нравится это пользователю, или нет, но это факт, который он может учитывать и не испытывать никаких неудобств, или же не учитывать и жаловаться на несуществующую проблему. Ежели я возжелаю создать в одной папке file1 и File1, а затем ещё fiLE1 и FILE1, подразумевая четыре разных файла — что же, я не смогу сделать этого в регистронезависимой ФС. Я, конечно, понимаю, что главный закон ПО от Apple — всё должно быть так просто, чтобы этим смог пользоваться даже кот пользователя, но мне кажется, что не стоит забирать у пользователя возможность в угоду упрощения.
vxd_dev
15.06.2016 12:35Справедливости ради — это два совершенно разных символа и в то же время буква в разных регистрах. Избыточные возможности тоже не всегда хорошо, хотя в данном случае думаю все доводы будут достаточно субъективными. Говоря за себя, я понятия не имею регистрозависима ли винда с NTFS или нет, хотя работаю только в ней сколько себя помню. Так ли это важно на самом деле?
r00tGER
14.06.2016 15:38Именно!
Если я захочу так назвать свои файлы — то фс не должна мне мешать. (про целесообразность не будем рассуждать)tmteam
14.06.2016 16:16Если я не хочу иметь возможность так ошибиться — фс не должна давать мне такой возможности.
Boba_Fett
14.06.2016 16:21+1Предлагаете на уровне ОС запретить шрифты, в которых разные символы могут быть похожи друг на друга?
tmteam
14.06.2016 16:55При чём здесь шрифты?
Boba_Fett
14.06.2016 16:58+2Проблема, описанная в комментарии выше по ветке заключается в том, что два разных символа выглядят одинаково в том шрифте, которым отображается тот комментарий. Ниже alexws54tk привёл пример другого шрифта, в котором подобные символы легко различимы. Ему, кстати, необязательно быть моноширинным.
alexws54tk
14.06.2016 17:04+4Как сказал оратор выше, это «Шрифтопроблемы». ИМХО, в терминале должен стоять свой любимый
Моноширинный Шрифт.
% touch file1.txt % touch fiIe1.txt % touch fiLe1.txt % ls -l fi*.txt -rw-r--r-- 1 alex alex 0 июн 14 19:45 fiIe1.txt -rw-r--r-- 1 alex alex 0 июн 14 19:45 fiLe1.txt -rw-r--r-- 1 alex alex 0 июн 14 19:44 file1.txt
И проблема исчезла.
niamster
15.06.2016 03:15+3Ваш пример не имеет никакого отношения к ригистру.
В основном регистронезависимые имена в файловый системах — это потеря производительность. Ведь если регистр учитывается, то можно просто сравнить байты, а если нет — сначала раскодировать символ(например C в unicode U+0106), потом сменить регистр(на c), и только потом начинать сравнение. К слову, перекодировка нетривиальная задача. Причем это надо сделать 2 раза — для искомого и для всех «зарегистрированных» вариантов(существующих файлов, директорий, и т.д.) на пути. Кроме того тут присутствует не только чтение из памяти, но и запись в нее.
В итого это большой расход памяти, нагрузка на кэш процессора и на шину данных памяти. Если Вы посмотрите сколько сравнений приходится делать FS для того чтоб открыть file.txt, то сразу станет понятно что к чему.
Ну и есть, конечно, эстетический аспект. Я бы возмутился, если бы ко мне обращался человек как к NiAmStEr.
tmteam
14.06.2016 17:08Смущает. Уже давно пытаюсь понять причину, как в языках программирования так и в FS (кроме привычки).
mistergrim
14.06.2016 17:19+1Основная масса — это никсовые FS. Которые по объёму не основная масса.
И есть у меня страшное подозрение, что регистрозависимость в никсах пошла из-за банальной экономии ресурсов (ведь так банально проще).niamster
15.06.2016 15:30Это как же так? Вы хотите сказать, что подавляющее количество серверов использует Win или OSX?
К тому же Android использует ext4 в 90% случаев. Если еще сюда добавить сетевое оборудование и т.д. — думаю что *nix в большинстве =).
Википедия позволяет быть ближе к реальности.
DagothNik
14.06.2016 17:16Пробовал жить на HFS+ с учетом регистра клавиатуры. Год на ней где-то был. Из проблем — только запускаемый из контейнера Steam. Все остальное работало штатно. Проблемы были при переезде на том без учета регистра. Но это была не необходимость, а от «нечего делать».
vasechka
15.06.2016 02:34В документации написано, что это временное ограничение, которое может быть устранено в последующих версиях и/или в релизе APFS в 2017 году.
Spalf
14.06.2016 14:35+1Было бы интересно почитать обзор на тему почему все же не взяли ZFS. Несколько раз же пытались перенести.
А так ждем, жаль только что реализации для Linux скорее всего не скоро увидим.
iMisanthrope
14.06.2016 15:28Выскажу как предположение (поскольку сам с ZFS имел дело только в рамках небольшого домашнего сервачка на SmartOS), что ZFS все же сложна/избыточна для конечного пользователя: пулы, квоты, неадекватное поведение при переполнении носителя, ориентированность на многодисковые хранилища – это не то, что нужно среднестатистическому пользователю продукции Apple. Плюс упомянули, что во главу угла, помимо шифрования, встала адаптация под SSD и мобильные устройства. Мне кажется, Apple пошла по своему обычному пути: взяла лучшее из ZFS (copy-on-write, снапшоты и тд) и делает из этого максимально простой для юзера продукт. Более чем уверен, что в итоге все фишки будут спрятаны под капотом (т.е те же снапшоты будут использоваться только в Time Machine, например).
Но это имхо, повторюсь, недостаточно хорошо знаком с ZFS для более обоснованных предположений.
potan
14.06.2016 16:10Мне в BTRFS (и ZFS) нравится возможность прозрачно добавлять/удалять тома в существующую систему. Хотя сейчас мало кто уже открывает крышку компьютера без необходимости и эта фича не востребована.
Boba_Fett
14.06.2016 16:20В LVM это тоже есть.
potan
14.06.2016 16:33LVM управляет только томами. Файловая система должна уметь расширяться и сжиматься при изменении размеров тома, что обычно непрозрачно (требует размонтирования). Да и у FS больше информации как разместить данные на нескольких носителях.
Boba_Fett
14.06.2016 16:39Так вроде вы выше и писали про «добавлять/удалять тома». Многие системы не требуют размонтирования для расширения, а только для сжатия, даже NTFS, кажется, умеет.
Насколько я знаю, у Btrfs проблемы со стабильностью, а ZFS ещё не до конца портировали на Linux, когда последний раз в этом ковырялся, оказалось проще переехать на LVM. А вот дополнительные возможности ZFS при работе с физическими носителями разного типа весьма полезны, тут полностью согласен.
vasechka
15.06.2016 02:35+1Думаю, если не лицензия, то, скрорее всего из-за прожорливаости ZFS к ОЗУ, а на телефоне или айпаде памяти и так мало.
vasilisc
14.06.2016 14:43+2ZFS хоть и открыта, но все тёрки идут из-за несовместимости лицензий и сейчас в прямом смысле бодаются юристы, чтобы сказать «кто прав, а кто виноват».
potan
14.06.2016 16:06А работу с томами на уровне FS они не стали поддерживать. :-(
Возможно, это связано с тем, что они считают/пропагандируют что компьютер надо заменять целиком, а рабочие данные хранить в облаке.
Bozaro
14.06.2016 22:00Интересно, то есть дедупликация давно есть в Linux, скоро появится в MacOS и отсутствует только под Windows...
Spalf
15.06.2016 00:12Дедупликация уже есть в Windows Server:
https://habrahabr.ru/company/microsoft/blog/158887/Bozaro
15.06.2016 06:56+1Я её смотрел. Это какое-то странное решение, которое страшно даже для домашнего использования:
- дедупликация реализована не на уровне файловой системы, а на уровне приложения через File Streams;
- файлы распадаются на метаданные и данные;
- нет API для создания копии файла;
- нельзя грузиться с раздела, на котором настроена дедупликация;
- пенальти на производительность.
У меня сложилось впечатление, что данная фича в Windows сделана для галочки в рекламных буклетах.
Дедупликации на уровне файловой системы в Windows нет и, судя по всему, не планируется.
jakshi
15.06.2016 10:47+1Регистрозависимость удобна когда есть git репозитории которые регистрозависимы.
Работаю с репозиториями с которыми git работал некорректно из за регистронезависимой (по умолчанию) HFS+
Обхожу созданием дополнительного диска с HFS+ регистрозависимой файловой системой и храню оные git репозитории там.
Почему то содержимое git репозиториев на этом диске иногда портится.
В связи с чем: отличная новость, буду рад попробовать APFS для хранения регистрозависимых файлов.BjLomax
15.06.2016 13:31При установке с нуля OS X можно выбрать какая HFS+ будет в системе, регистронезависимой или нет.
sheknitrtch
15.06.2016 15:56Эра бета-версий во всей красе. Apple выпускают незаконченную версию файловой системы и говорят: «тестируйте, но вы можете потерять все свои данные». Я понимаю, когда авторы видео-плеера предлагают бета версию своего продукта с новыми плюшками. Но когда корпорация рекламирует недоделанный продукт с закрытым исходным кодом, использование которого может (теоретически) повредить часть данных, то мне кажется, что где-то мы свернули не туда.
ИМХО, бета версии, частые релизы, новые фичи два раза в год, поддержка свежих эмодзи — это не то, что Я хочу видеть от производителя драйвера файловой системы. Мне кажется, что в таких критических системах должна рекламироваться надёжность, производительность и отказоустойчивость.
Hyston
15.06.2016 17:04Так вроде они и не предлагают ставить ее на носители с важной информацией. Мне как раз было бы тревожнее, если бы они сразу ее объявили, как конечную версию и начали бы ее активно рекламировать. Поскольку, как не тестируй, какие-то ошибки в первое время будут всплывать и для начала ее обкатывают на энтузиастах.
sheknitrtch
16.06.2016 12:04+1Я не припомню, чтобы кто-нибудь выпускал бета-версию нового стандарта Wi-Fi, или пробную версию RAID контроллеров, или незаконченный драйвер видеокарты (исключение составляют только активно разрабатываемые операционные системы, наподобие ReactOS, Fantom OS, др.). Я ожидаю что такой важный компонент, как файловая система, должен быть отлажен, покрыт unit-тестами, проверен на различном железе, а только потом доступен всем желающим.
Странно, что разработчики смирились с фактом «как не тестируй, какие-то ошибки в первое время будут всплывать». Поэтому сейчас эра бета-версий в самом разгаре.v12aml
16.06.2016 14:33> чтобы кто-нибудь выпускал бета-версию нового стандарта Wi-Fi
orly?
оборудование со стандартами (точнее с драфтами) 802.11n, ac и прочие выходило задолго до финального релиза стандарта
Hyston
Как я понял, AFS появится не в Sierra (по крайней мере, не для конечных потребителей), а в следующей версии, в 2017ом. И еще многие вещи до сих пор пока не работают: TimeMachine, FusionDrive, FileVault, её нельзя использовать для startup дисков и прочее.
Так что все еще сырое и в разработке, но все таки очень приятно знать, что в apple не только над новыми смайликами трудятся.