Файловая система Apple File System (APFS)

    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
    • +4
      Как я понял, AFS появится не в Sierra (по крайней мере, не для конечных потребителей), а в следующей версии, в 2017ом. И еще многие вещи до сих пор пока не работают: TimeMachine, FusionDrive, FileVault, её нельзя использовать для startup дисков и прочее.
      Так что все еще сырое и в разработке, но все таки очень приятно знать, что в apple не только над новыми смайликами трудятся.
      • 0
        не получилось бы как с ReFS когда один резет превращает весь раздел в тыкву.
        • 0
          у… поддержка регистрозависимых имен файлов… ((

          • 0
            Зачем?
            • +3
              Что бы жизнь мёдом не казалась.
              • +3

                Надо отметить, что регистронезависимое сравнение, строго говоря, зависит от локали.
                Например, в Турции: UPPER("windows") = "WİNDOWS", а не "WINDOWS", как в большей части света.


                Очень занимательно посмотреть, какие символы считаются одинаковыми при регистронезависимом сравнении в MySQL: http://collation-charts.org/mysql60/mysql604.utf8_general_ci.european.html

              • +2
                А то что основная масса FS регистрозависимые, вас не смущает? В быту регистронезависимые имена файлов доставляют не мало проблем, по краней мере для меня.
                • +1
                  Ага. регистрозависимые имена файлов — вот восторг!

                  file1.txt (l — мелкая L)
                  fiIe1.txt (I — заглавная i)

                  • +1
                    продолжу жаловаться.

                    Пользователи присылают мне в ПО(робот) файлы по электронной почте. Файлы наименованы: OMSK.xls, Ufa.xls, Moscow.xls

                    Пользователи именуют файлы не обращая внимания на регистр. Т.е. сегодня может быть OMSK.XLS, завтра Omsk.xls, послезавтра omsk.xls

                    Может я неправ, конечно, но регистронезависимая ФС избавляет меня от операции приведения имен файлов к единому регистру и облегчает отладку\работу

                    В чем смысл регистрозависимой фс — не могу понять, ну честно. Только в том, что в именах файлов можно использовать camelStyle?
                    textFile1.txt и TextFile1.txt
                    • +2
                      Пользователи просто из-под винды шлют файлы. А NTFS — одна из немногих ФС с такой фигней. Я как-то привык уже на EXT4 к регистрозависимости. Хотя явных плюсов того или другого подхода привести не могу.
                      • –2
                        Нужна веская причина для усложнения UX того или иного продукта. Иными словами — бритва окамма. Для меня, как программиста, до сих пор большим вопросом является регистро-зависимый синтаксис С. Хорошо что IDE помогают в этом, и тут даже появляются некоторые плюсы, но в целом? Я подозреваю что это было изначально сделано, чтобы парсерам было прощще, а потом все просто привыкли к этому. Итого вопрос — зачем создают сложности, там где их можно избежать? Мне в spotlight теперь придётся искать файл с учётом заглавных букв?
                        • +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;
                          • 0
                            > Для меня, как программиста, до сих пор большим вопросом является регистро-зависимый синтаксис С.

                            Регистрозависимый синтаксис в ЯП — однозначное благо, он защищает нормальных людей от говнокодеров, которые пишут кАк иМ НРавиТсЯ. Говорю как человек, довольно долго поддерживавший коммерческое ПО, написанное на паскале, у которого синтаксис регистронезависимый.
                            • 0
                              Я и в си и сишарпе могу так написать. Для этого есть Code-style. Более того — видел и не раз то о чём вы говорите в наших проектах.
                              • +2
                                Это не благо а лишний повод подстрелить себе ногу.
                            • 0
                              а что, на маках давно по-умолчанию она регистрозавсимая? сколько себя помню, всегда были проблемы с тем, что не так файл из кода ищещь и на симуляторе все ок, а не iPhone нет ресурса.
                              • 0
                                Не знаю как сейчас, но когда-то тоже сталкивался с проблемой регистрозависимости, когда прогал под айпад.
                                В симуляторе пофигу, а на айпаде регистрозависимость, хотя файловая система вроде одна.
                                Стало интересно, полез в управление разделами в маке
                                И там при форматировании был параметр регистрозависимость, по умолчанию выключен.
                                Скорей всего до сих пор так, только проверить не могу — на рабочем маке админские права не дают
                              • +1

                                На самом деле, это не NTFS регистронезависимая, это винда регистронезависимая по традиции. Если для винды сделать драйвер любой другой ФС — то ее тома будут вести себя точно так же. В противном случае существующие программы могут перестать работать, и это будет ошибкой.


                                PS FILE_FLAG_POSIX_SEMANTICS дает поведение "как в *NIX" — к примеру, можно создать два файла, отличающиеся только регистром символов.

                              • НЛО прилетело и опубликовало эту надпись здесь
                                • 0
                                  Справедливости ради — это два совершенно разных символа и в то же время буква в разных регистрах. Избыточные возможности тоже не всегда хорошо, хотя в данном случае думаю все доводы будут достаточно субъективными. Говоря за себя, я понятия не имею регистрозависима ли винда с NTFS или нет, хотя работаю только в ней сколько себя помню. Так ли это важно на самом деле?
                              • 0
                                Именно!
                                Если я захочу так назвать свои файлы — то фс не должна мне мешать. (про целесообразность не будем рассуждать)
                                • 0
                                  Если я не хочу иметь возможность так ошибиться — фс не должна давать мне такой возможности.
                                  • +1
                                    Предлагаете на уровне ОС запретить шрифты, в которых разные символы могут быть похожи друг на друга?
                                    • 0
                                      При чём здесь шрифты?
                                      • +2
                                        Проблема, описанная в комментарии выше по ветке заключается в том, что два разных символа выглядят одинаково в том шрифте, которым отображается тот комментарий. Ниже alexws54tk привёл пример другого шрифта, в котором подобные символы легко различимы. Ему, кстати, необязательно быть моноширинным.
                                        • 0
                                          Согласен. Не понял вас сразу.
                                • 0
                                  Шрифтопроблемы.
                                • +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
                                  

                                  И проблема исчезла.
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                  • +2
                                  • +3
                                    Ваш пример не имеет никакого отношения к ригистру.

                                    В основном регистронезависимые имена в файловый системах — это потеря производительность. Ведь если регистр учитывается, то можно просто сравнить байты, а если нет — сначала раскодировать символ(например Ć в unicode U+0106), потом сменить регистр(на ć), и только потом начинать сравнение. К слову, перекодировка нетривиальная задача. Причем это надо сделать 2 раза — для искомого и для всех «зарегистрированных» вариантов(существующих файлов, директорий, и т.д.) на пути. Кроме того тут присутствует не только чтение из памяти, но и запись в нее.
                                    В итого это большой расход памяти, нагрузка на кэш процессора и на шину данных памяти. Если Вы посмотрите сколько сравнений приходится делать FS для того чтоб открыть file.txt, то сразу станет понятно что к чему.

                                    Ну и есть, конечно, эстетический аспект. Я бы возмутился, если бы ко мне обращался человек как к NiAmStEr.
                                  • 0
                                    Смущает. Уже давно пытаюсь понять причину, как в языках программирования так и в FS (кроме привычки).
                                    • +1
                                      Основная масса — это никсовые FS. Которые по объёму не основная масса.
                                      И есть у меня страшное подозрение, что регистрозависимость в никсах пошла из-за банальной экономии ресурсов (ведь так банально проще).
                                      • 0
                                        Это как же так? Вы хотите сказать, что подавляющее количество серверов использует Win или OSX?
                                        К тому же Android использует ext4 в 90% случаев. Если еще сюда добавить сетевое оборудование и т.д. — думаю что *nix в большинстве =).
                                        Википедия позволяет быть ближе к реальности.
                                  • 0
                                    Пробовал жить на HFS+ с учетом регистра клавиатуры. Год на ней где-то был. Из проблем — только запускаемый из контейнера Steam. Все остальное работало штатно. Проблемы были при переезде на том без учета регистра. Но это была не необходимость, а от «нечего делать».
                                    • 0

                                      В документации написано, что это временное ограничение, которое может быть устранено в последующих версиях и/или в релизе APFS в 2017 году.

                                    • +1
                                      Было бы интересно почитать обзор на тему почему все же не взяли ZFS. Несколько раз же пытались перенести.

                                      А так ждем, жаль только что реализации для Linux скорее всего не скоро увидим.
                                      • 0
                                        где-то видел что ZFS чувствительна к ошибкам озу, поэтому дальше серверов вряд ли уйдёт.
                                        • +1
                                          Хотел бы я посмотреть на «нечувствительную к ошибкам озу» файловую систему.
                                        • 0
                                          Выскажу как предположение (поскольку сам с ZFS имел дело только в рамках небольшого домашнего сервачка на SmartOS), что ZFS все же сложна/избыточна для конечного пользователя: пулы, квоты, неадекватное поведение при переполнении носителя, ориентированность на многодисковые хранилища – это не то, что нужно среднестатистическому пользователю продукции Apple. Плюс упомянули, что во главу угла, помимо шифрования, встала адаптация под SSD и мобильные устройства. Мне кажется, Apple пошла по своему обычному пути: взяла лучшее из ZFS (copy-on-write, снапшоты и тд) и делает из этого максимально простой для юзера продукт. Более чем уверен, что в итоге все фишки будут спрятаны под капотом (т.е те же снапшоты будут использоваться только в Time Machine, например).
                                          Но это имхо, повторюсь, недостаточно хорошо знаком с ZFS для более обоснованных предположений.
                                          • 0
                                            Мне в BTRFS (и ZFS) нравится возможность прозрачно добавлять/удалять тома в существующую систему. Хотя сейчас мало кто уже открывает крышку компьютера без необходимости и эта фича не востребована.
                                            • 0
                                              В LVM это тоже есть.
                                              • 0
                                                LVM управляет только томами. Файловая система должна уметь расширяться и сжиматься при изменении размеров тома, что обычно непрозрачно (требует размонтирования). Да и у FS больше информации как разместить данные на нескольких носителях.
                                                • 0
                                                  Так вроде вы выше и писали про «добавлять/удалять тома». Многие системы не требуют размонтирования для расширения, а только для сжатия, даже NTFS, кажется, умеет.
                                                  Насколько я знаю, у Btrfs проблемы со стабильностью, а ZFS ещё не до конца портировали на Linux, когда последний раз в этом ковырялся, оказалось проще переехать на LVM. А вот дополнительные возможности ZFS при работе с физическими носителями разного типа весьма полезны, тут полностью согласен.
                                          • +1

                                            Думаю, если не лицензия, то, скрорее всего из-за прожорливаости ZFS к ОЗУ, а на телефоне или айпаде памяти и так мало.

                                          • +2
                                            ZFS хоть и открыта, но все тёрки идут из-за несовместимости лицензий и сейчас в прямом смысле бодаются юристы, чтобы сказать «кто прав, а кто виноват».
                                            • 0
                                              А работу с томами на уровне FS они не стали поддерживать. :-(
                                              Возможно, это связано с тем, что они считают/пропагандируют что компьютер надо заменять целиком, а рабочие данные хранить в облаке.
                                              • 0

                                                Интересно, то есть дедупликация давно есть в Linux, скоро появится в MacOS и отсутствует только под Windows...

                                                • 0
                                                  Дедупликация уже есть в Windows Server:
                                                  https://habrahabr.ru/company/microsoft/blog/158887/
                                                  • +1

                                                    Я её смотрел. Это какое-то странное решение, которое страшно даже для домашнего использования:


                                                    • дедупликация реализована не на уровне файловой системы, а на уровне приложения через File Streams;
                                                    • файлы распадаются на метаданные и данные;
                                                    • нет API для создания копии файла;
                                                    • нельзя грузиться с раздела, на котором настроена дедупликация;
                                                    • пенальти на производительность.

                                                    У меня сложилось впечатление, что данная фича в Windows сделана для галочки в рекламных буклетах.
                                                    Дедупликации на уровне файловой системы в Windows нет и, судя по всему, не планируется.

                                                • +1
                                                  Регистрозависимость удобна когда есть git репозитории которые регистрозависимы.
                                                  Работаю с репозиториями с которыми git работал некорректно из за регистронезависимой (по умолчанию) HFS+

                                                  Обхожу созданием дополнительного диска с HFS+ регистрозависимой файловой системой и храню оные git репозитории там.
                                                  Почему то содержимое git репозиториев на этом диске иногда портится.

                                                  В связи с чем: отличная новость, буду рад попробовать APFS для хранения регистрозависимых файлов.
                                                  • 0
                                                    При установке с нуля OS X можно выбрать какая HFS+ будет в системе, регистронезависимой или нет.
                                                  • 0
                                                    Эра бета-версий во всей красе. Apple выпускают незаконченную версию файловой системы и говорят: «тестируйте, но вы можете потерять все свои данные». Я понимаю, когда авторы видео-плеера предлагают бета версию своего продукта с новыми плюшками. Но когда корпорация рекламирует недоделанный продукт с закрытым исходным кодом, использование которого может (теоретически) повредить часть данных, то мне кажется, что где-то мы свернули не туда.

                                                    ИМХО, бета версии, частые релизы, новые фичи два раза в год, поддержка свежих эмодзи — это не то, что Я хочу видеть от производителя драйвера файловой системы. Мне кажется, что в таких критических системах должна рекламироваться надёжность, производительность и отказоустойчивость.
                                                    • 0
                                                      Так вроде они и не предлагают ставить ее на носители с важной информацией. Мне как раз было бы тревожнее, если бы они сразу ее объявили, как конечную версию и начали бы ее активно рекламировать. Поскольку, как не тестируй, какие-то ошибки в первое время будут всплывать и для начала ее обкатывают на энтузиастах.
                                                      • +1
                                                        Я не припомню, чтобы кто-нибудь выпускал бета-версию нового стандарта Wi-Fi, или пробную версию RAID контроллеров, или незаконченный драйвер видеокарты (исключение составляют только активно разрабатываемые операционные системы, наподобие ReactOS, Fantom OS, др.). Я ожидаю что такой важный компонент, как файловая система, должен быть отлажен, покрыт unit-тестами, проверен на различном железе, а только потом доступен всем желающим.

                                                        Странно, что разработчики смирились с фактом «как не тестируй, какие-то ошибки в первое время будут всплывать». Поэтому сейчас эра бета-версий в самом разгаре.
                                                        • +2
                                                          >незаконченный драйвер видеокарты
                                                          по-моему, половина из них незакончена.
                                                          • 0
                                                            > чтобы кто-нибудь выпускал бета-версию нового стандарта Wi-Fi

                                                            orly?

                                                            оборудование со стандартами (точнее с драфтами) 802.11n, ac и прочие выходило задолго до финального релиза стандарта

                                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.