Содержание
Роль файловой системы Apple — Служба поддержки Apple (RU)
Файловая система Apple (APFS) — собственная файловая система, которая была разработана с учетом новейших требований к шифрованию. APFS используется на всех платформах Apple — iPhone, iPad, iPod touch, Mac, Apple TV и Apple Watch. Она оптимизирована для использования флеш-памяти/SSD и имеет такие функции, как надежное шифрование, копирование при записи с использованием метаданных, совместное использование пространства, клонирование файлов и каталогов, снимки, быстрое определение размера каталогов, атомарные примитивы безопасного сохранения и усовершенствованные принципы файловой системы, а также уникальную технологию копирования при записи, которая использует объединение ввода/вывода для обеспечения максимальной производительности без ущерба для надежности данных.
Совместное использование пространства
APFS выделяет пространство для хранения по запросу. Если один контейнер APFS содержит несколько томов, свободное пространство контейнера используется совместно и может быть выделено любым томам по мере необходимости.
Каждый том использует только часть контейнера, поэтому доступное пространство определяется как общий размер контейнера за вычетом пространства, используемого всеми томами контейнера.
Несколько томов
В macOS 10.15 или новее контейнер APFS, используемый для загрузки операционной системы на Mac, должен содержать как минимум пять томов, первые три из которых скрыты от пользователя.
Предзагрузочный том. Этот том не зашифрован. Он содержит данные, необходимые для загрузки каждого системного тома в контейнере.
Том виртуальной памяти. Этот том не зашифрован. Он используется macOS для хранения зашифрованных файлов подкачки.
Том восстановления. Этот том не зашифрован. Он должен быть доступен без снятия защиты с системного тома, чтобы выполнять запуск recoveryOS.
Системный том. Содержит следующие данные:
все необходимые файлы для загрузки Mac;
все встроенные нативные приложения macOS (эти приложения раньше находились в папке «/Программы», а теперь их можно найти в папке «/Система/Программы»).
Примечание. По умолчанию ни один процесс, даже системный процесс Apple, не имеет права записи в системный том.
Том данных. Содержит изменяемые данные, например:
любые данные в папке пользователя, в том числе фото, музыку, видео и документы;
установленные пользователем приложения, включая AppleScript и Automator;
пользовательские программные среды и демоны, установленные пользователем, организацией или приложениями сторонних разработчиков;
другие папки, которые принадлежат пользователю и доступны ему для записи, например: «/Программы», «/Библиотеки», «/Пользователи», «/Volumes», «/usr/local», «/private», «/var» и «/tmp».
Для каждого дополнительного системного тома создается том данных. Предзагрузочный том, том виртуальной памяти и том восстановления являются общими и не имеют дубликатов.
В macOS 11 или новее для системного тома создается снимок. Операционная система загружается со снимка системного тома, а не просто с изменяемого системного тома, подключенного только для чтения.
В iOS и iPadOS хранилище делится по крайней мере на два тома APFS:
системный том;
том данных.
Дата публикации: 13 мая 2022 г.
См. такжеUUID группы томов APFS (vuid)Безопасность подписанного системного тома в iOS, iPadOS и macOSШифрование тома с помощью FileVault в macOSУправление FileVault в macOS
Файловая система APFS: зачем она стала нужна
О том что прежняя файловая система у Apple была отсталой и никуда не годилась, вот уже лет десять говорили и писали тысячи экспертов и авторов. На момент её замены на APFS ей было уже лет тридцать, модными новшествами она и в самом деле не блистала, но, как ни странно, если её отсталость кому-то и мешала, то очень немногим. Её не замечали, то есть, она отлично справлялась со своими обязанностями. С ней не было проблем, чего не скажешь о новой файловой системе – неплохой, но все еще слишком юной.
APFS — новая файловая система Apple
Файловые системы Mac’ов, начиная с самой первой из них, вызывали у тех, кто знает толк в файловых системах, презрение и чувство собственного превосходства.
В самом первом Mac’e, в 1984 году, файловая система даже не была иерархической. MFS (Macintosh File System) обладала целым рядом уникальных особенностей, которые для первого Mac’а были намного нужнее чем самые современные и не до конца продуманные механизмы современных (на тот момент) файловых систем – я имел дело с VAX/VMS, по сравнению с файловой системой которых MFS была из каменного века. Но для первого Mac’а она была абсолютно достаточной. Сначала в первом Mac’е планировалось использовать файловую систему из Lisa OS, вполне себе иерархическую и современную на тот момент, которая, в свою очередь, происходила от SOS, очень приличной файловой системы для Apple II и Apple III – но амбициозные и безумные задачи стоявшие перед первым Mac’ом не оставили для неё места. MFS в той ситуации была одним из блестящих и остроумных инженерных решений, без которых Mac’а бы просто не было.
Что такое HFS
К иерархической системе вернулись через полтора года, в сентябре 1985 года. Когда Стив был уволен из Apple.
Новую файловую систему назвали, не без вызова, просто и со вкусом: HFS. Операционную систему Mac’ов называли System, а иерархическую файловую систему – иерархической файловой системой (Hierarchical File System, или HFS). А какие еще могут быть операционные и файловые системы? В системах где от файловых систем требовались особые способности, они быстро усложнялись и развивались. В Mac’ах этого не требовалось. Пока к середине 90-х у HFS не возникла серьезная проблема, с которой надо было что-то делать: размеры дисков, по сравнению с 1985 годом, существенно увеличились. Типичный размер диска в конце 80-х – 40-80 Мегабайт. В конце 90-х размеры дисков уже измерялись в единицах Гигабайт. А HFS была 16-битной. На томе можно было разместить не более 65535 файлов. В результате, даже если в файле нужно было хранить один или два символа, на диске для него выделялось килобайт десять, а то и двадцать.
Читайте также: Как работает функция Sidecar на iPad и Mac
С файловой системой надо было что-то делать, и немедленно.
Но компания была на грани гибели, несла убытки, как стало известно через несколько лет, через 2-3 месяца, если бы ничего не изменилось, ей грозило неминуемое банкротство. Как они этого избежали я не буду рассказывать, но примерно в то же время Стив, как будто случайно, зашел в один из офисов компании, где шло совещание, с блокнотиком – будто бы просто посидеть. Когда совещание закончилось, он уволил почти все руководство подразделения, и назначил на руководящий пост инженера который предложил что-то, что Стиву понравилось. Короче, самодур и все такое. С тем инженером я в 1998 общался, речь на том совещании шла о новой файловой системе. Вариантов было два: либо, в течение 3-4 лет, разрабатывать современную и насыщенную вкусностями (от которых эксперты индустрии будут в восторге) FS, а потом, в течение нескольких лет, доводить её до приличного состояния – либо быстро и просто устранить реальные проблемы, на что требовалось максимум полгода – по мнению тех кто предлагал этот путь. Через 3 или 4 месяца, в Mac OS 8.
1, появилась HFS+. 32-битная.
APFS есть не только в Mac, но и iPhone, iPad и Apple Watch
Фактически, это была та же самая HFS, с относительно небольшими изменениями. Даже с переходом на исправленную и доработанную копию самой себя были проблемы. Недолго. Именно эта файловая система, вплоть до марта 2017 года, была файловой системой в macOS (как бы она не называлась), в iOS, в tvOS и в watchOS. Как обычно, “спецификации” у файловой системы были, мягко говоря, очень бледными. Но проблем с ней почти не было, разве что в серверном бизнесе Apple, который так и остался всего лишь эпизодом. Но, что бы о нем не говорили тогда и потом, очень ярким и интересным. Если бы с iPhone ничего не получилось, в Mac’ах на смену HFS+ пришла бы ZFS, году в 2008 или 2009. Но, к счастью или к несчастью, с iPhone все получилось.
С 2005 по 2009 Apple Computer, плавно превратившаяся на середине этого пути в просто Apple, активно интересовалась ZFS, уникальной файловой системой разработанной в Sun Microsystems.
Это практически безграничная файловая система, 128-битная, пределы на которые она рассчитана скорее всего никогда не будут достигнуты, а по набору функций и признаков современной файловой системы едва ли не самая-самая в мире. До 2007 года, пока Apple была Apple Computer, “яблочный” вариант этой файловой системы успешно развивался, в Леопарде (в той самой версии Mac OS X, срок выхода которой перенесли из-за аврала по поводу подготовки самого первого iPhone к выходу в свет) ZFS должны была появиться в серверном варианте системы – но, внезапно, Apple утратила к ней интерес.
Предлагаем подписаться на наш канал в «Яндекс.Дзен». Там вы сможете найти эксклюзивные материалы, которых нет на сайте.
Как появилась APFS
До 2007 года у компании (точнее, у Стива) все еще были сомнения в успехе главной инновации десятилетия – iPhone, в 2007 году эти сомнения были развеяны. В индустрии до сих пор ходят слухи о том, что Apple не справилась с внедрением ZFS в Mac OS X. Есть еще одна версия: кто-то не то в Sun Microsystems, не то в Oracle Corporation (вскоре купившей Sun), забыл упомянуть Стива в какой-то речи, или как-то не так его упомянул.
Реальная причина очевидна: поворот в сторону мобильных устройств (в которых HFS+ хватило бы на годы, и ведь хватило же) был рискованным, но сулил Apple намного большее. Как только на этом фронте наметился реальный успех, серверное направление стали потихоньку закрывать.
Крейг Федериги разрабатывает APFS
В 2014 году (по другим данным, в 2012 – но скорее всего, все-таки в 2014) в Apple началась разработка новой файловой системы. Для того чтобы взяться за столь трудоемкий проект, нужны были серьезные причины. Какие-то планы на будущее, с которыми HFS+ стала бы несовместимой. Файловые системы создаются долго и трудно. На это уходят годы. В 2016 году APFS была объявлена. В марте 2017 она дебютировала в iOS, достаточно успешно. В том же году, осенью, APFS в составе High Sierra пришла и на Mac’и. Чтобы состояться, операционной или файловой системе нужно дожить до версии 3.1. Им нужно переболеть детскими болезнями, научиться справляться с житейскими ситуациями, повзрослеть. Я не знаю к чему готовятся в Apple, для чего им понадобилась “современная файловая система” именно сейчас, но мощь этого неизвестного замысла уже впечатляет.
У APFS все еще много недостатков, но главный из них (юность) очень быстро проходит. О том что представляет из себя APFS, и какие из её целей уже озвучены – расскажу в другой раз.
macOS CatalinaSSD в MacКомпьютеры AppleОперационные системы Apple
Форматы файловой системы, доступные в Дисковой утилите на Mac
Дисковая утилита на Mac поддерживает несколько форматов файловой системы:
Файловая система Apple (APFS): Файловая система, используемая macOS 10.13 или более поздней версии.
Mac OS Extended: Файловая система, используемая macOS 10.12 или более ранней версии.
MS-DOS (FAT) и ExFAT: Файловые системы, совместимые с Windows.
Откройте для меня Дисковую утилиту
Файловая система Apple (APFS)
Файловая система Apple (APFS), файловая система по умолчанию для компьютеров Mac, использующих macOS 10.13 или более поздней версии, обеспечивает надежное шифрование, совместное использование пространства, моментальные снимки, быстрое изменение размера каталога и улучшенные основы файловой системы.
Хотя APFS оптимизирован для хранения Flash/SSD, используемого в последних компьютерах Mac, его также можно использовать в более старых системах с традиционными жесткими дисками (HDD) и внешним хранилищем с прямым подключением. macOS 10.13 или более поздней версии поддерживает APFS как для загрузочных томов, так и для томов данных.
APFS выделяет дисковое пространство внутри контейнера (раздела) по запросу. Когда один контейнер APFS имеет несколько томов, свободное пространство контейнера является общим и автоматически выделяется для любого из отдельных томов по мере необходимости. При желании вы можете указать размеры резерва и квоты для каждого тома. Каждый том использует только часть общего контейнера, поэтому доступное пространство равно общему размеру контейнера за вычетом размера всех томов в контейнере.
Выберите один из следующих форматов APFS для компьютеров Mac с macOS 10.13 или более поздней версии.
APFS: Использует формат APFS. Выберите этот вариант, если вам не нужен зашифрованный или чувствительный к регистру формат.
APFS (зашифрованный): Использует формат APFS и шифрует том.
APFS (с учетом регистра): Использует формат APFS и учитывает регистр в именах файлов и папок. Например, папки с именами «Домашнее задание» и «ДОМАШНЕЕ ЗАДАНИЕ» — это две разные папки.
APFS (с учетом регистра, с шифрованием): Использует формат APFS, учитывает регистр в именах файлов и папок и шифрует том. Например, папки с именами «Домашнее задание» и «ДОМАШНЕЕ ЗАДАНИЕ» — это две разные папки.
Вы можете легко добавлять или удалять тома в контейнерах APFS. Каждый том в контейнере APFS может иметь свой собственный формат APFS — APFS, APFS (зашифрованный), APFS (с учетом регистра) или APFS (с учетом регистра, с шифрованием).
Mac OS Extended
Выберите один из следующих форматов файловой системы Mac OS Extended для совместимости с компьютерами Mac, использующими macOS 10.12 или более ранней версии.
Mac OS Extended (в журнале): Использует формат Mac (в журнале HFS Plus) для защиты целостности иерархической файловой системы.
Выберите этот вариант, если вам не нужен зашифрованный или чувствительный к регистру формат.Mac OS Extended (в журнале, с шифрованием): Использует формат Mac, требует пароль и шифрует раздел.
Mac OS Extended (с учетом регистра, в журнале): Использует формат Mac и учитывает регистр в именах папок. Например, папки с именами «Домашнее задание» и «ДОМАШНЕЕ ЗАДАНИЕ» — это две разные папки.
Расширенная версия Mac OS (с учетом регистра, в журнале, с шифрованием): Использует формат Mac, учитывает регистр в именах папок, требует пароль и шифрует раздел.
Выберите этот вариант, если вам не нужен зашифрованный или чувствительный к регистру формат.Форматы, совместимые с Windows
Выберите один из следующих форматов файловой системы, совместимых с Windows, если вы форматируете диск для использования с Windows.
См. также Схемы разделов, доступные в Дисковой утилите на MacВведение в Дисковую утилиту на странице MacMan для diskutil
Что нового в файловых системах Apple — WWDC19 — Видео
Скачать
Добрый день, дамы и господа.
Добро пожаловать в сеанс файловой системы. На этом занятии мы рассмотрим несколько тем, связанных с файловыми системами. Во-первых, мы рассмотрим роль файловой системы в защите системного программного обеспечения в macOS.
Мы собираемся описать, как работает репликация томов в APFS. И, наконец, мы поговорим о новой и очень интересной функции, появившейся на устройствах под управлением iOS и iPadOS, — доступе к внешним файлам на внешнем носителе. Но прежде чем мы начнем, давайте реанимируем то, что недавно произошло с APFS. APFS была файловой системой по умолчанию — на iOS и tvOS с версии 10.3 и на macOS с High Sierra.
Одной из функций, представленных в APFS, является встроенный менеджер томов.
Концепция тома не нова для APFS. Они существовали в HFS Plus.
Том HFS Plus является прямым сопоставлением с — в этом разделе. И он занимает непрерывный диапазон блоков на диске.
Из-за этого однозначного сопоставления с разделами и томами HFS Plus невозможно легко добавить.
Чтобы добавить новый том на разбитый на разделы диск, сначала необходимо уменьшить размер существующего тома. И тогда вы можете добавить новый том. Тома APFS гораздо более гибкие, потому что они делят собственное дисковое пространство со своими братьями и сестрами.
И эта гибкость позволяет более высоким уровням системы реализовывать функции, которые иначе было бы невозможно реализовать с томами старого стиля.
Один из нас — одна из функций, которую мы реализуем, — защита системного программного обеспечения от вредоносных или случайных обновлений.
Возможно, вы помните, что еще во времена macOS El Capitan мы представили концепцию защиты целостности системы.
Используется для управления доступом к части иерархии каталогов.
Некоторые каталоги будут защищены от записи, в то время как изменения в других частях файловых систем будут разрешены. В этом году мы делаем еще один шаг вперед. Мы делаем всю корневую файловую систему доступной только для чтения.
Очевидно, что система, в которой вы не можете установить новое программное обеспечение или где пользователь не может сохранить данные, не особенно полезна.
Чтобы понять, как мы можем примирить эти две противоречащие друг другу цели: доступ только для чтения и возможность записи одновременно, давайте посмотрим, что происходит при обновлении с macOS Mojave до macOS Catalina. Типичный контейнер в macOS Mojave будет иметь один основной том и несколько служебных томов. Например, ВМ. Основной объем используется для хранения как пользовательских данных, так и системного программного обеспечения.
Когда мы начинаем обновление. Когда мы начинаем обновление до macOS Catalina, мы сначала меняем роль основного тома и помечаем его как том данных.
Затем мы можем удалить некоторые части иерархии директив, которые содержат только системное программное обеспечение.
Как только это будет сделано, мы можем перейти к следующему этапу, где мы создадим новый пустой том, который будет использоваться только для хранения системного программного обеспечения.
Мы заполним этот том системным содержимым. И как только этот процесс завершится, мы сможем объявить о победе на фронте защиты. Мы доступны только для чтения. Мы защищены. Это хорошо, но этого недостаточно.
Нам все еще нужно как-то связать новый системный контент с пользовательским контентом. И для этого мы вводим понятие группы томов. Группа томов — это один том данных и один системный том. И они относятся к нему как к единому целому.
Пользовательский интерфейс представляет его как один диск. Они разделяют состояние шифрования. Если ваши тома зашифрованы, то для разблокировки обоих томов можно использовать один и тот же пароль. Почти все выглядит как единое целое.
Одного не хватает. Нам все еще нужно как-то обеспечить иллюзию единой иерархии каталогов. Традиционно это делалось путем монтирования файловых систем поверх каталогов в корневой файловой системе.
С количеством точек пересечения, которые нам нужно ввести, и количеством томов, которые требуются в файловой системе, этот подход становится довольно дорогим.
Поэтому, чтобы справиться с этим, мы представили новую концепцию под названием Firmlink. Firmlink — это новый объект файловой системы.
Аналогичен Symlink. Но в отличие от Symlink, Firmlink поддерживает обратный и прямой путь, что соответствует его представлению. И эта последовательность очень важна. Если вам когда-либо приходилось иметь дело с приложением, которое абсолютно настаивает на том, что оно должно находиться в определенном каталоге, например, с приложениями. Вы знаете, что вы должны иметь возможность идти как от вершины файловой системы от дороги вниз к листьям, так и обратно и получить один и тот же путь. Мы можем сделать это с помощью Firmlinks.
Жесткие ссылки — это точка перехода из каталога на системном томе в каталог на томе данных.
У них только взаимно однозначное сопоставление. Один источник. Одна цель.
Вы не можете использовать Firmlink для пересечения границы группы томов.
Фирменные ссылки довольно прозрачны для пользователя и приложения.
Они создаются программой установки во время установки. И их не должны замечать.
Как только мы получим этот новый инструмент, мы сможем использовать его для объединения томов. Установщик создаст запись на системном томе.
И указать им соответствующие тома на томе данных.
И как только это будет сделано, у нас будет единая иерархия каталогов. Мы можем перезагрузиться, смонтировать root только для чтения и наслаждаться защитой, которую он нам дает.
Жизнь удалась. Все защищено. Все работает. Но вы все равно должны помнить, что тома разделяются в процессе установки. Невозможно избежать этого. Это произойдет. В предварительной версии для разработчиков мы решили оставить корневую файловую систему доступной для записи, чтобы вам было проще тестировать приложение. Если вы хотите имитировать ваше поведение, которое будет реализовано в дальнейшем, вы можете создать специальный файл в корневом каталоге и при перезагрузке ваши тома будут смонтированы только для чтения.
Это изменится в следующей сборке поверх следующего семени.
В выпускной сборке вы по-прежнему сможете монтировать корневую файловую систему для чтения и записи, если отключите защиту целостности системы.
Но это не постоянное изменение. При перезагрузке он вернется в состояние только для чтения. Вы можете перемонтировать его только для чтения, снова для чтения и записи.
И снова он вернется в то же состояние при перезагрузке.
Как вы можете себе представить, это довольно большое изменение в способе формирования и установки macOS. И это могло поймать некоторые приложения. Если, например, ваше приложение использует сложную структуру файловой системы или поставляется с установочным пакетом, убедитесь, что оно работает на новом корневом разделе, доступном только для чтения.
Если вы пишете утилиту резервного копирования, которая заботится о номерах инодов, идентификаторах файловой системы и т. п., убедитесь, что вы протестировали ее, потому что предположения, которые у вас могли быть ранее, могут оказаться неверными.
Так что суть в том, что тест, тест, тест. А затем я передам слово Джону Беккеру, чтобы он рассказал о репликации томов.
Спасибо, Макс.
Добрый день. Меня зовут Джон, и я собираюсь рассказать о репликации томов с помощью APFS. Итак, давайте приступим прямо к делу. Что такое репликация тома? Ну, основная идея довольно проста. Мы хотели бы скопировать один том на другой том.
Звучит просто. Но важным аспектом этого является то, что мы хотим, чтобы точность этой копии была как можно выше. В общем, недостаточно просто делать пофайловые копии. Мы хотим копировать весь объемный контент. Все данные, все метаданные, атрибуты тома. Если исходный том содержит загрузочную ОС, мы хотим копировать метаданные, которые делают этот том загрузочным, чтобы цель нашей копии также была загрузочной. Теперь я собираюсь рассказать о репликации в контексте утилиты командной строки Apple Software Restore, или ASR. ASR существует очень давно. Многие из вас могут быть знакомы с ним. И его основной функцией является репликация тома.
Теперь, с ASR, очень часто источником нашей репликации является образ диска. И в этом контексте мы часто называем процедуру выполнения этой репликации на целевом томе восстановлением, отсюда и название Apple Software Restore. Но вы услышите, как я использую термины «восстановление» и «реплицирование» как взаимозаменяемые.
Так кому это нужно? Кому нужен этот функционал? Что ж, если вы работаете в сфере образования или корпоративных ИТ, если вы создаете большие лаборатории с большим количеством машин или пишете утилиты для резервного копирования, то репликация — это функция, которая вам, вероятно, нужна или которую вы хотите использовать с некоторой регулярностью. Как мы увидим, некоторые из новых функций APFS представляют собой проблему, связанную с тем, как мы можем выполнять репликацию.
С другой стороны, также см., эти новые функции также предоставляют возможность сделать репликацию более мощной и гибкой операцией. Итак, я хочу сделать резервную копию всего на секунду и рассказать о том, как репликация выглядела в прошлом до APFS.
Теперь, как Макс продемонстрировал ранее, с предыдущими файловыми системами, такими как HFS Plus, файловая система, или, я должен сказать, том, находится во взаимно однозначном отношении с разделом, который его содержит. И это означает, что том поддерживается непрерывным блочным устройством. Таким образом, репликация может включать просто создание блочной копии всего раздела. Конечно, если мы копируем все блочное устройство, мы копируем всю информацию о файловой системе этого тома. Теперь могут быть некоторые сложности, как на этой диаграмме. У нас есть исходный и целевой разделы разного размера. Но есть способы, как мы можем это исправить. Так что по большому счету блочное копирование — очень эффективный и относительно простой способ репликации. Но, конечно, с APFS есть некоторые новые функции, которые усложняют эту картину.
Итак, APFS, как сказал вам Макс, имеет некоторые функции, такие как управление томами и разделение пространства. И, как мы видим, если мы посмотрим на том 1 на диаграмме здесь, он разбросан по разделу-контейнеру.
И поэтому это не непрерывное блочное устройство.
И это может быть — его данные могут перемежаться с данными для другого тома в том же контейнере, как том 2 в этом примере.
Кроме того, мы, конечно же, заботимся о безопасности и конфиденциальности. И поэтому мы должны думать о шифровании. Теперь с APFS шифрование выполняется на уровне файловой системы. Более того, на компьютерах Mac с чипом безопасности T2 для внутренних устройств хранения это шифрование включено постоянно. И он напрямую привязан к оборудованию, а это означает, что он специфичен для этого устройства хранения на этом Mac. И поэтому, если мы попытаемся скопировать блоки для этого тома и перенести их куда-то еще, их будет невозможно расшифровать. Таким образом, в результате блочные копии на самом деле не являются возможным способом репликации с томами APFS. Так как же нам согласовать это с потребностями, которые у нас есть? Что ж, в macOS Catalina мы представляем репликацию томов APFS с ASR. АСР и АПФС. Да, спасибо.
ASR и APFS тесно интегрированы. И ASR может заставить APFS генерировать поток из исходного тома. Затем этот поток записывается на целевой том. Теперь, поскольку APFS генерирует этот поток, он знает, где ему нужно прочитать части исходного тома.
Так что не проблема, что исходный том не является непрерывным блочным устройством.
Что касается шифрования, то если источник тома зашифрован, то будет — данные из него будут расшифровываться на лету по мере формирования потока. И, конечно же, если исходный том защищен FileVault, то его необходимо разблокировать с помощью действий пользователя перед выполнением этой репликации. Если целевой том сам по себе зашифрован, то данные находятся в — или данные зашифрованы, когда они записываются из потока в целевой том. И поэтому в этом случае эти данные шифруются с самого начала к тому времени, когда они достигают целевого тома. Хорошо? Еще одна приятная особенность этой репликации заключается в том, что при создании потока данные тома дефрагментируются на лету.
Метаданные сжаты, поэтому результирующий поток и, следовательно, конечный целевой объем очень хорошо оптимизированы. Это может быть отличным способом — например, для мастеринга изображений. Если вы создаете образ, и последним шагом является выполнение операции репликации, тогда объем вашего образа будет очень хорошо оптимизирован.
Итак, когда мы делаем восстановление, репликацию, как бы вы это ни называли, есть несколько вариантов, которые мы можем использовать. Я просто хочу назвать пару из них. Первый действительно очень похож на восстановление, к которому мы привыкли. Мы можем указать исходный том. Вы можете указать целевой том. Идея состоит в том, что целевой том будет полностью стерт и заменен. Или его содержимое заменено содержимым исходного тома. Теперь в этом случае у нас будет том 2 в качестве нашего целевого тома. Итак, наше восстановление будет выглядеть примерно так. Вы увидите образец командной строки прямо здесь.
В результате содержимое тома 2 стирается и заменяется содержимым исходного тома.
Таким образом, восстановленный том и исходный том совпадают. Обратите внимание, кстати, что в этом примере в целевом контейнере также есть еще один том. И этот том остался в покое. Его содержимое сохраняется. Он никоим образом не является частью операции репликации. Но у нас есть еще один вариант: вместо того, чтобы указывать целевой том и стирать его, мы можем вместо этого создать совершенно новый том, который станет целью на лету. И мы делаем это, указав весь контейнер в качестве цели. И это говорит ASR, что мы действительно хотим создать совершенно новый том и восстановить его. Вы можете увидеть еще один образец командной строки. В результате создается и восстанавливается новый том. Таким образом, в этом случае том 1 и том 2 остаются в покое.
Теперь я хочу на секунду отойти от репликации. И я хочу поговорить о снапшотах в APFS. Таким образом, моментальный снимок — это всего лишь моментальный захват всего состояния тома. Так, например, у нас может быть том с несколькими файлами на нем.
Мы можем сделать снимок этого тома. В результате получается стоп-кадр того, как выглядит этот том в момент создания моментального снимка. Если мы вносим последующие изменения в том, например удаляем файл или добавляем несколько новых файлов, моментальный снимок по-прежнему охватывает все состояние, существовавшее на момент его создания.
Итак, в этом случае, если мы посмотрим на живой том, окажется, что того файла, который был удален, там нет. Но в каком-то смысле он все еще там, потому что это часть этого моментального снимка.
Вы можете задаться вопросом: «Ну, а какое это имеет отношение к репликации?» Что ж, еще раз, новое с macOS Catalina, теперь мы можем делать восстановление, репликацию снимков.
Итак, чтобы понять, что это значит — Спасибо.
Чтобы понять, что это значит, рассмотрите вот этот том слева. В нем есть два снимка, Snap 1 и Snap 2. Они содержат некоторые общие файлы, желтые, некоторые файлы, которые находятся в одном снимке, а не в другом, некоторые файлы, которые находятся в другом, а не в одном, и файл, который не является снимком.
Я могу восстановить этот том до целевого тома здесь справа. В настоящее время он пуст. И идея здесь, конечно, в том, что в конце этого восстановления целевой том выглядит как исходный том. Но вместо того, чтобы восстанавливать сортировку — живую версию исходного тома, как она сейчас выглядит, я могу вместо этого восстановить моментальный снимок. Поэтому, если, например, я хочу восстановить моментальный снимок 1, я могу указать, что именно этот моментальный снимок я хочу восстановить. И в результате моя цель теперь выглядит как Snap 1. Обратите внимание, в частности, что те два файла, которые были удалены из исходного тома, вернулись к жизни в целевом томе.
Сделав это, я, возможно, захочу добавить несколько новых файлов в свой целевой том. Но тогда, может быть, теперь я хочу восстановить Snap 2 на этот целевой том. И, конечно же, опять же, идея состоит в том, что в конце этой операции живой целевой том должен выглядеть как Snap 2 из исходного тома. Но обратите внимание, что и на исходном, и на целевом томах уже есть Snap 1.
Было бы здорово, если бы вместо того, чтобы копировать весь Snap 2, я мог бы просто скопировать то, что отличается от Snap 1 и Snap 2? Ну, действительно, я могу. Мы называем эту разницу между двумя моментальными снимками дельтой моментального снимка. Идея заключается в том, что когда я восстанавливаю дельту моментального снимка, я указываю два моментальных снимка, различие которых я хочу получить. Выполняю восстановление. И, конечно же, в конце живой целевой том выглядит как Snap 2 из источника. Но есть три вещи, которые я хочу, чтобы вы заметили в отношении этого целевого тома. Во-первых, все те файлы, которые не были частью моментального снимка на цели, были удалены.
Во-вторых, файлы, которые были в Snap 1, но не были в Snap 2, были удалены из живого целевого тома. Они, конечно, все еще существуют в Snap 1 на целевом томе. И, в-третьих, нам нужно было скопировать только те файлы, которые были частью Snap 2, а не частью Snap 1.
Хорошо? Теперь это действительно мощная функция.
Это отличный способ делать инкрементальные релизы. Представьте, что вы обновляете лабораторию, заполненную 100 машинами. Вы можете сэкономить много времени и пропускную способность сети, если копируете только разницу между парой снимков исходного изображения.
Вот что я хотел сказать о репликации. Возьмите домой очки здесь. Более сложная файловая система требует более сложных механизмов репликации.
Репликацию тома APFS действительно лучше всего выполнять с помощью ASR, поскольку он обеспечивает высочайшую точность копий. И он обрабатывает шифрование по мере необходимости. И, наконец, теперь мы можем восстанавливать снимки в дельтах снимков с помощью ASR. И на этом я передам это Биллу, который расскажет о внешнем доступе к файлам для iOS. Спасибо. Спасибо, Джон. Добрый день. Вы, наверное, помните, что два года назад мы представили приложение «Файлы» и новый поставщик файлов — API.
Вместе они предлагают отличные возможности для облачных документов.
В этом году мы думали, что сможем сделать больше.
Итак, в этом году мы рады объявить о поддержке iOS для доступа к файлам в сетевых ресурсах и на USB-накопителях.
Для USB-накопителей мы поддерживаем все, от компактных флэш-памяти и CF, карт и флешек до USB-рейдов.
Мы поддерживаем несколько файловых систем. Мы поддерживаем незашифрованную APFS, незашифрованную HFS Plus, а также поддерживаем FAT и ExFAT. Эта функция доступна на всех устройствах iOS и iPadOS. Он доступен на iPad Pro с портом USB-C. А для устройств Lightning он доступен с соответствующими адаптерами.
Переходя к общим сетевым ресурсам, мы поддерживаем подключение к серверам SMB 3.0.
Мы поддерживаем подключение через Wi-Fi, сотовую связь и Ethernet.
Здесь много интересных функций. Но один, который мы хотели бы назвать, предназначен для наших устройств iOS, устройств iPadOS. Мы поддерживаем поиск с использованием протокола поиска Windows.
Таким образом, все эти устройства могут искать ваш сервер SMB, если он поддерживает протокол WSP.
Мы также очень рады объявить, что это включает сервер SMB и macOS Catalina.
Прежде чем продолжить, я хотел бы поговорить о безопасности. Безопасность — это функция, которую пользователи ожидают от iOS. Два инструмента, которые мы использовали для обеспечения этой безопасности, — это разделение процессов и разделение привилегий. При разработке этой функции мы помнили об этом и включили их с нуля.
Таким образом, для всех наших томов и общих файлов манипуляции с файловой системой происходят не в ядре, а в выделенном пространстве процесса. Это разделение помогает нам обеспечить безопасность, которую ожидают пользователи iOS.
Теперь посмотрим на это в действии.
Хорошо, у меня есть iPad.
И я не знаю, может быть, вы этого не видите. Но у меня подключена флешка.
А у меня есть почта. А в файлах, слева, вы можете увидеть локации. айклауд драйв. Если бы у нас был сторонний облачный провайдер, он бы тоже был там указан. И мы видим пункт назначения для нашего USB-устройства.
Когда мы выбираем его, мы видим наши фотографии, наши документы, все файлы и каталоги там. И мы можем манипулировать ими так же, как и любым другим файлом в приложении «Файлы». Таким образом, чтобы скопировать один, вы просто выбираете его, готовите к перетаскиванию, выбираете место назначения, перетаскиваете и опускаете. И вы можете видеть, что он уже в папке.
Еще одна вещь, которую мы любим делать с устройствами, это копирование фотографий на них. Фотографии, у меня есть фотография томатов, сделанная другом в Индии.
Сохраним на USB. Для этого мы просто выбираем документ, идем в «Поделиться», идем вниз по списку, чтобы сохранить в «Файлы». Как видите, в качестве пункта назначения у нас указан USB-накопитель. Мы просто выбираем его. Это уже есть. Нажимаем сохранить. И он скопирован. Я ожидаю, что многие из вас являются разработчиками приложений. И вам интересно, как ваше приложение может воспользоваться этим. Эта функция доступна для всех без исключения приложений, связанных с iOS 13 или более поздней версии.
Итак, перестройте приложение. И вы можете воспользоваться.
Чтобы увидеть это в действии, давайте посмотрим на Numbers. Когда я открываю Numbers, это начинается — это начинается с моего iCloud Drive.
USB указан как место назначения. Мы выбираем его.
И там мы можем увидеть все наши документы. Наши фотографии затемнены, потому что они не являются документами Numbers. И затем мы видим, что у нас есть два документа Numbers на этом диске.
Давайте откроем один из них. Это сравнение кредита, сравнивающее две разные суммы кредита и две разные процентные ставки.
Просто для сравнения посмотрим, что произойдет, если мы повысим процентную ставку.
№ О. Установите 20, а не 200.
О, нет. Ну, это безумие. И вы можете видеть на… смотрите в реальном времени, как меняются суммы процентных ставок.
Итак, что это значит для вас как для разработчиков? Как я уже сказал, он доступен, если вы подключены к iOS 13 или более поздней версии.
Так что пересоберите свое приложение и протестируйте.
Мы добавляем в iOS пять различных типов файловых систем. Эти файловые системы действуют немного иначе, чем APFS во внутренней флэш-памяти.
Одно отличие состоит в том, что в iOS всегда были файловые системы с учетом регистра. FAT и ExFAT нечувствительны к регистру.
И HFS, и APFS можно настроить любым способом.
Системный вызов Clone может быть доступен не всегда.
Итак, каковы эти различия — если они важны для вас или таковы, пожалуйста, обратите внимание на возможности тома. Есть два разных API или несколько API, которые могут получить их для вас. Один из них, который я хотел бы назвать, — это resourceValues в NSURL.
Они могут дать вам параметры для файловой системы, с которой вы работаете.
Другим важным моментом является то, что перемещение файла может занять некоторое время. Поэтому, пожалуйста, поместите свои временные файлы рядом с вашими рабочими файлами. Если нет, верно, это полезно.
Потому что Save-Save использует переименование в самом конце, чтобы пользователь всегда видел хороший файл. Они либо видят документ, с которого начали, либо видят новое сохранение.
Чтобы это работало, нам нужно это переименование. И это работает, только если они оба находятся в одной файловой системе.
Кроме того, если вы не будете осторожны с временными файлами, они могут оказаться в вашем контейнере во внутренней памяти. И это приведет к большому количеству ненужного ввода-вывода.
Файловый менеджер может помочь вам в этом. Если вы запросите URL-адрес для itemReplacementDirectory, подходящего для ваших документов, он предоставит вам временный каталог в той же файловой системе.
Другое дело, что внешние устройства могут уйти.
Сеть может выйти за пределы диапазона. Файловый сервер может выйти из строя. CAT может отсоединить кабель.
Такое может случиться. И ваше приложение должно быть устойчивым к этому. Одна вещь, которую я особенно хотел отметить, это то, что mmap может быть опасным.
Это может быть действительно мощно. Но если файл исчезнет, ядро может сообщить вам об этом только с помощью ошибки BUS.
Так вот, если вы используете NSData, есть подсказка, которую вы можете дать NSData и сказать mmap эти данные из файла, если это безопасно.
Последний момент заключается в том, что внешние устройства, все они, имеют более высокие задержки, чем APFS на внутренней флэш-памяти.
Так что, если вы выполняете значительные операции ввода-вывода, выполняйте одновременно несколько операций.
Подводя итог сегодняшней беседе, Макс рассказал нам о том, как мы делаем корневой том доступным только для чтения для повышения безопасности. Джон рассказал нам о ASR и о том, как вы можете использовать ASR для репликации томов, включая дельты моментальных снимков. И я говорил с вами о том, как мы добавляем поддержку внешних файлов в iOS и iPadOS и как это позволит вам получать доступ к файлам на USB-накопителе и в сетевых ресурсах.
Для получения дополнительной информации у нас есть лаборатория после этого сеанса.