Disk Utility пока не может работать с CoreStorage, поэтому приходится использовать командно-строковую утилиту diskutil.

Нахожу, какой раздел мне нужно перекодировать (Data):

$ diskutil list
/dev/disk2
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk2
   1:                        EFI                         209.7 MB   disk2s1
   2:                  Apple_HFS Legacy                  50.0 GB    disk2s2
   3:                  Apple_HFS Data                    449.6 GB   disk2s3

Запускаю конвертирование, обязательно указываю ключевую фразу (данные не уничтожаются во время этой операции):

$ diskutil corestorage convert /dev/disk2s3 -stdinpassphrase
New passphrase for converted volume: **********
...
Finished CoreStorage operation on disk2s3 Data
Encryption in progress; use `diskutil coreStorage list` for status

С разделом можно работать сразу же, его шифрование производится в фоновом режиме. Процесс достаточно длительный. Я даже перевёл ноутбук в Sleep, не дождавшись окончания, но после просыпания шифрование продолжилось. Статус шифрования можно посмотреть командой (прогресс не виден, только статус Converting/Complete):

$ diskutil coreStorage list
...
        Logical Volume Family 3E0D6C21-4178-4597-9F79-91E13A02E6FA
        ----------------------------------------------------------
        Sequence:               6
        Encryption Status:      Unlocked
        Encryption Type:        AES-XTS
        Encryption Context:     Present
        Conversion Status:      Converting
        Has Encrypted Extents:  Yes
        Conversion Direction:   forward

Когда шифрование завершится, “Conversion Status:” станет “Complete”.

Сделал замеры производительности до и после шифрования, результаты приведены ниже.

Последовательное и случайное чтение/запись небольших файлов

Без шифрования

С шифрованием

Скорость операций случайного чтения/записи почти не изменилась. Последовательных – изменилось незначительно. Интересно приведение скорости записи после шифрованию к нормальному виду (на первом графике скорость записи выше скорости чтения). Возможно шифрование привело к дефрагментации диска.

Чтение/запись больших файлов размером от 1 до 10 MB

Без шифрования

С шифрованием

Скорость изменилась незначительно, на глаз до 4-7%. Всплеск скорости записи после шифрования вероятно вызвано эффектом кеширования, добавляемым подсистемой шифрования.

Чтение/запись больших файлов размером от 10 до 100 MB

Без шифрования

С шифрованием

Кривые чтения и записи стали отличаться, на мой взгляд из-за большей ресурсоёмкости шифрования записи. Скорость записи ухудшилась на 15%, чтения – на 5%.

Чтение/запись файла 200 MB

Без шифрования

С шифрованием

Скорость записи ухудшилась на 8%, чтения – на 2%.

Вывод

При включении шифрования AES-XTS на жёстком диске 5400 rpm в ноутбуке с процессором Core 2 Duo без поддержки команд AES-NI наблюдается ухудшение скорости записи до 15%, а скорости чтения – до 8%. Что вполне приемлемо как плата за безопасность данных.

После включения FileVault 2 на моём ноутбуке пришло время создания очередного клона диска с данными (пока незашифрованного) и я решил совместить приятное с полезным – сравнить время создания клона одного и того же раздела на одинаковые внешние USB-диски.

На первом диске я создал логический том CoreStorage с шифрованием AES-XTS, на втором – без шифрования. И сделал два клона оригинального незашифрованного раздела с данными на 350 GB.

Замечу, что тестирование не отражает реальное падение производительности на шифрование данных – скорость упирается в производительность USB-интерфейса. Но для конкретного случая оно достаточно интересно.

На раздел с шифрованием клонирование шло 3 часа и 26 минут с эффективной скоростью 26.12 MB/s:

На раздел без шифрования – 3 часа и 23 минуты с эффективной скоростью 26.41 MB/s:

Таким образом для дисков, подключаемых по USB, разница при включенном шифровании AES-XTS несущественна. Поэтому если вам не важна кроссплатформенность и вы не хотите, чтобы ваши данные попали в чужие руки, то шифрование дисков крайне рекомендую.

К сожалению, пока Disk Utility не поддерживает работу с томами CoreStorage, и зашифрованные разделы нужно создавать вручную.

Пока только при настройке диска для Time Machine я видел возможность включения шифрования:

Я хочу создать на новом диске два зашифрованных логических раздела.

Диск пуст:

$ diskutil list
/dev/disk4
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                                                   *500.1 GB   disk4

Создаю Logical Volume Group. Синтаксис:

Usage:  diskutil coreStorage create lvgName
        MountPoint|DiskIdentifier|DeviceNode ...
Create a CoreStorage logical volume group from one more more disks.
The specified disks will become the initial set of PVs.
All existing data on the drive will be lost.
Ownership of the affected disk is required.
Example: diskutil coreStorage create MyLVG disk1

Команда:

$ diskutil corestorage create lvgCS disk4
Started CoreStorage operation
Unmounting disk4
Repartitioning disk4
Unmounting disk
Creating the partition map
Rediscovering disk4
Adding disk4s2 to Logical Volume Group
Creating Core Storage Logical Volume Group
Switching disk4s2 to Core Storage
Waiting for Logical Volume Group to appear
Discovered new Logical Volume Group "332FA822-E709-42BD-819F-38D846BBBFB2"
Core Storage LVG UUID: 332FA822-E709-42BD-819F-38D846BBBFB2
Finished CoreStorage operation

Создаю зашифрованный Logical Volume. Синтаксис:

Usage:  diskutil coreStorage createVolume lvgUUID type name size
        [-stdinpassphrase | -passphrase [passphrase]]
Add a new logical volume to a CoreStorage logical volume group.
Type is the file system to initialize on the new logical volume. Valid types
are Journaled HFS+ or Case-sensitive Journaled HFS+ or their aliases.
Size is the amount of space to allocate from the parent logical volume group.
Valid sizes are floating-point numbers with a suffix of B(ytes), S(512-byte-
blocks), K(ilobytes), M(egabytes), G(igabytes), T(erabytes), P(etabytes),
or (%) a percentage of the current size of the logical volume group.
Example: diskutil coreStorage createVolume
         11111111-2222-3333-4444-555555555555 jhfs+ myLV 10g

Команда создания первого раздела размером в 60% от родительского LVG (UUID LVG взял в результатах предыдущей команды):

$ diskutil corestorage createvolume 332FA822-E709-42BD-819F-38D846BBBFB2 \
	jhfs+ lvCS1 60% -stdinpassphrase
Passphrase for new volume: ***********
Started CoreStorage operation
Waiting for Logical Volume to appear
Formatting file system for Logical Volume
Initialized /dev/rdisk3 as a 279 GB HFS Plus volume with a 24576k journal
Mounting disk
Core Storage LV UUID: 11391E12-477A-44DA-AE48-F92B74C2512B
Core Storage disk: disk3
Finished CoreStorage operation

Команда создания второго раздела размером в 40%:

$ diskutil corestorage createvolume 332FA822-E709-42BD-819F-38D846BBBFB2 \
	jhfs+ lvCS2 40% -stdinpassphrase
Passphrase for new volume: ***********
Started CoreStorage operation
Waiting for Logical Volume to appear
Formatting file system for Logical Volume
Initialized /dev/rdisk5 as a 74 GB HFS Plus volume with a 8192k journal
Mounting disk
Core Storage LV UUID: B07706D0-8A64-4952-BB16-D5DEC2691687
Core Storage disk: disk5
Finished CoreStorage operation

Смотрю, что получилось:

$ diskutil corestorage list
+-- Logical Volume Group 332FA822-E709-42BD-819F-38D846BBBFB2
    =========================================================
    Name:         lvgCS
    Sequence:     3
    Free Space:   119907090432 B (119.9 GB)
    |
    +-< Physical Volume 0C7E6C96-6890-49ED-9B70-2D66789A34CE
    |   ----------------------------------------------------
    |   Index:    0
    |   Disk:     disk4s2
    |   Status:   Online
    |   Size:     499763888128 B (499.8 GB)
    |
    +-> Logical Volume Family 04AE431E-3C70-4F48-8F60-885ED7121980
    |   ----------------------------------------------------------
    |   Sequence:               2
    |   Encryption Status:      Unlocked
    |   Encryption Type:        AES-XTS
    |   Encryption Context:     Present
    |   Conversion Status:      NoConversion
    |   Has Encrypted Extents:  Yes
    |   Conversion Direction:   -none-
    |   |
    |   +-> Logical Volume 11391E12-477A-44DA-AE48-F92B74C2512B
    |       ---------------------------------------------------
    |       Disk:               disk3
    |       Status:             Online
    |       Sequence:           2
    |       Size (Total):       299767734272 B (299.8 GB)
    |       Size (Converted):   -none-
    |       Revertible:         No
    |       LV Name:            lvCS1
    |       Volume Name:        lvCS1
    |       Content Hint:       Apple_HFS
    |
    +-> Logical Volume Family 18E88D4F-FF92-4E31-AB2C-75F175DDAB63
        ----------------------------------------------------------
        Sequence:               2
        Encryption Status:      Unlocked
        Encryption Type:        AES-XTS
        Encryption Context:     Present
        Conversion Status:      NoConversion
        Has Encrypted Extents:  Yes
        Conversion Direction:   -none-
        |
        +-> Logical Volume B07706D0-8A64-4952-BB16-D5DEC2691687
            ---------------------------------------------------
            Disk:               disk5
            Status:             Online
            Sequence:           2
            Size (Total):       79938060288 B (79.9 GB)
            Size (Converted):   -none-
            Revertible:         No
            LV Name:            lvCS2
            Volume Name:        lvCS2
            Content Hint:       Apple_HFS

Размонтирую разделы через Finder, подключаю диск повторно. Разделы зашифрованы:

    +-> Logical Volume Family 04AE431E-3C70-4F48-8F60-885ED7121980
    |   ----------------------------------------------------------
    |   Sequence:               2
    |   Encryption Status:      Locked
    |   Encryption Type:        AES-XTS
    |   Encryption Context:     Present
    |   Conversion Status:      NoConversion
    |   Has Encrypted Extents:  Yes
    |   Conversion Direction:   -none-
    |   |
    |   +-> Logical Volume 11391E12-477A-44DA-AE48-F92B74C2512B
    |       ---------------------------------------------------
    |       Disk:               -none-
    |       Status:             Locked
    |       Sequence:           2
    |       Size (Total):       299767734272 B (299.8 GB)
    |       Size (Converted):   -none-
    |       Revertible:         No
    |       LV Name:            lvCS1
    |       Content Hint:       Apple_HFS

Можно разблокировать разделы командой “diskutil corestorage unlockvolume”, а можно ввести пароль в приглашении:

Для смены пароля нужно сначала размонтировать раздел, а потом выполнить команду:

Usage:  diskutil coreStorage changeVolumePassphrase|passwd lvUUID
        [-recoverykeychain file] | [-oldpassphrase old]
        [-newpassphrase new] | [-stdinpassphrase]
Change an encrypted logical volume's password. Beyond the CoreStorage UUID,
you will be prompted interactively for parameters that you do not specify.
Parameters must be given in the above order.
Example: diskutil coreStorage changeVolumePassphrase
         11111111-2222-3333-4444-555555555555

Процесс смены:

$ diskutil corestorage changeVolumePassphrase 11391E12-477A-44DA-AE48-F92B74C2512B
Old passphrase:
New passphrase:
Repeat new passphrase:
Started CoreStorage operation
Logical Volume passphrase has been changed
Core Storage LV UUID: 11391E12-477A-44DA-AE48-F92B74C2512B
Finished CoreStorage operation

У команды diskutil есть и скрытые команды из группы corestorage, их можно посмотреть в статье “Undocumented CoreStorage Commands“.

Я, как и у многие люди, связанные с системным администрированием, немного параноик. Я считаю, что мои данные хотят украсть. Пусть они реально никому, кроме меня (“и множества злоумышленников, которые спят и видят, как получить мои фотографии, подборку музыки и фильмов, и…”, – это слова моего внутреннего параноика) и не нужны, но защититься не помешает.

Что произойдёт, если ноутбук украдут?

Самый простой случай – вор сразу же переформатирует диск и поставит чистую версию операционной системы. Останется купить новый ноутбук, восстановиться из Time Machine и спокойно продолжить работу. Этот сценарий характерен для умного вора, который знает о функции “Find My Mac” и о системе Pray.

Но есть другой случай – вор или глуп, или любопытен. Если глуп, то начнёт пользоваться ноутбуком, не трогая систему. Недавняя история поимки такого вора описана в статье “Why you don’t steal from a hacker“. Всё закончилось плачевно для вора и отлично для владельца ноутбука.

Если вор любопытен и умён, то сразу же отключит сетевые интерфейсы, чтобы даже случайно система не вышла в Интернет, и начнёт изучать, чем бы можно поживиться.

Начнёт изучать документы, ключи доступа, попробует добраться до Keychain, посмотрит историю команд в shell и возможно наткнётся на пароль (в моей практике был случай, когда очень быстрый коллега в сессии излишне любопытного пользователя вбивал пароль администратора, но вбил не в поле запроса пароля, а просто в shell, и пароль администратора попал в .history). Пароль в клиническом случае может быть единым для системы и для базы 1Password. Можно дальше не продолжать. А дальше – или проникновение, или шантаж.

Надеюсь, вы не думаете, что запрос пароля при входе в систему кого-то остановит? Firmware Password (по крайней мере раньше) сбрасывался фокусом с вынимаем одной из нескольких планок памяти, а затем очисткой PRAM. Потом – single user mode, пара команд, и пароль изменён. Если же не хочется возиться с Firmware Password, то диск вынимается из ноутбука, подключается к другому компьютеру и доступ ко всем данным получен.

Для защиты от описанной ситуаций был реализован FileVault. В первой версии пользовательский домашний каталог помещался в зашифрованный контейнер (sparse bundle image), ключом к которому служил пользовательский пароль. Не зная пароля, контейнер невозможно было открыть. Не нужно исключать возможность угадывания пароля, но если пароль был сложным, то данные были в полной безопасности.

За безопасность нужно платить. Для того, чтобы сделать резервную копию данных в Time Machine, нужно было выйти из учётной записи. Сделать выборочное восстановление через интерфейс Time Machine было нельзя. Включение шифрования ухудшало производительность файловых операций порой на 50%. Были и другие мелкие сложности.

В OS X Lion вошла улучшенная версия – FileVault 2, система шифрования полного диска, использующая алгоритм XTS-AES 128.

В процессе изучения вопроса я обращался к статьям MacFixIt “About FileVault 2 in OS X 10.7 Lion” и ArsTechnica “File system changes in Lion“.

Желающие разобраться с математическими моделями могут прочитать документ “IEEE P1619TM/D16 Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices” и “Не такой уж ты и страшный, XTS-AES“.

Незашифрованными остаются раздел с EFI (интересующихся процессом обычной загрузки отсылаю к статье “Процесс загрузки Apple Mac Intel“) и Recovery HD:

$ diskutil list
/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *160.0 GB   disk0
   1:                        EFI                         209.7 MB   disk0s1
   2:          Apple_CoreStorage                         159.2 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

1. После инициализации “железа” EFI находит Recovery HD и передаёт управление загрузчику /System/Library/CoreServices/boot.efi, находящемуся на этом разделе.
2. У загрузчика есть два варианта – запустить EfiLoginUI из com.apple.boot.x и показать стартовый экран с запросом пароля входа, или же, если была нажата комбинация Option-R – оболочку восстановления системы из com.apple.recovery.boot.
3. Ключи для расшифровки диска хранится в файле EncryptedRoot.plist.wipekey в каталоге /com.apple.boot.x/System/Library/Caches/com.apple.corestorage. Пользовательский пароль расшифровывает ключи к диску, находящийся в этом файле. Дальше они хранится в памяти, расшифровка содержимого диска производится “на лету”. Каждый раз при изменении пользовательского пароля, добавлении нового пользователя и подобных операциях EncryptedRoot.plist.wipekey перегенерируется.

FileVault работает и для пользователей, входящих через OpenDirectory – их аттрибуты доступа кешируются на случай отсутствия соединения с сервером каталогов.

Производительность дисковых операций при включенном FileVault 2 согласно тестам Anandtech ухудшается не более, чем на 20-30%, что вполне приемлемо. Однако стоит учитывать, что есть зависимость от процессора и диска. Новые процессоры Intel используют наборы инструкций AES-NI для ускорения работы с AES Intel® Advanced Encryption Standard Instructions (AES-NI) и с шифрованием диска справляются лучше, чем старые процессоры Core 2 Duo. Решение каждый принимает сам на основании собственного железа.

При краже Mac’а получить доступ к данным будет практически невозможно (при условии сложного пароля и неочевидных ответов на вопросы восстановления ключа в Apple). Придётся просто купить новый Mac и особо не беспокоиться о компрометации паролей и использовании данных.

Time Machine работает теперь без необходимости выхода из учётной записи. Теперь нужно беречь данные Time Machine, а лучше размещать их в зашифрованном разделе (как это сделать, описано в статье Mac OS X Lion FileVault 2 and Time Machine External Drive Encryption).

Из “особенностей” нужно помнить, что при загрузке с зажатым Option раздел “Recovery HD” будет недоступен, для загрузки с него нужно удерживать комбинацию клавиш Command-R.

Активация

Активация FileVault 2 проста. System Preferences/Security & Privacy/FileVault, Click the lock to make changes, Turn On FileVault. Обязательно нужно в надёжном и обязательно зашифрованном месте сохранить ключ и ответы на вопросы восстановления ключа (если выбрали его сохранение в Apple). Система предложит перезагрузиться. Сразу же при загрузке будет запрошен ваш пароль и после входа вы сразу же сможете работать. Ждать часами завершения шифрования раздела не нужно, эта операция производится в фоновом режиме пока вы полноценно работаете:

С запуском iCloud появится возможность “Find My Mac”, в которой по аналогии с “Find My iPhone/iPad” при появлении Mac в сети можно отобразить сообщение с воспроизведением звукового сигнала, заблокировать Mac или даже уничтожить содержимое зашифрованного диска (могу предположить, что удаляются ключи шифрования и диск становится бесполезным массивом данных):

При получении команды блокировки (как только Mac станет доступен через Интернет) компьютер перезагружается, после чего запрашивается 6-ти значный код (вспомнился [троян Trojan.Win32.Buzus.hjzy](http://av-school.ru/desc/a-2117.html), который портит MBR и требует денег за код разблокировки):

Удобно, не так ли?

Если же вы организованы и не хотите терять производительность в угоду безопасности, то достаточно создать зашифрованный sparse bundle image и хранить секретные данные там. Я описывал процесс в статье “Работа с зашифрованными образами с помощью Knox (за деньги) и без него (бесплатно)“.

Вот, например, данные на моём iPhone:

$ ls -al tmp/iphone/
drwxr-xr-x  2 ole ole   68 2010-05-26 15:36 ApplicationArchives
-rw-r--r--  1 ole ole    0 2010-03-21 16:06 com.apple.itdbprep.postprocess.lock
-rw-r--r--  1 ole ole    0 2010-03-21 16:06 com.apple.itunes.lock_sync
drwxr-xr-x  4 ole ole  204 2010-03-21 16:09 DCIM
drwxr-xr-x  2 ole ole  102 2010-06-02 02:06 Downloads
drwxr-xr-x  2 ole ole  102 2010-04-05 20:45 iPhoneDrive
drwxr-xr-x  7 ole ole  238 2010-03-21 16:19 iTunes_Control
drwxr-xr-x  3 ole ole  170 2010-06-03 10:53 Photos
drwxr-xr-x  2 ole ole   68 2010-03-21 16:06 Podcasts
drwxr-xr-x  2 ole ole   68 2010-06-02 17:03 PublicStaging
drwxr-xr-x  2 ole ole   68 2010-03-21 16:06 Purchases
drwxr-xr-x  2 ole ole  238 2010-03-28 14:35 Recordings
drwxr-xr-x  2 ole ole  136 2010-06-03 10:53 Safari

С Mac’а это можно сделать, например, используя небесплатную программу PhoneView (мне она досталась можно сказать бесплатно пару лет назад в составе MacHeist Bundle, поэтому грех ею не воспользоваться).

Для этого нужно включить в настройках программы “Show Entire Disk (Advanced Disk Mode)”:

Вот такие данные доступны для iPad:

Почему я не показал результат для iPhone? Недавно я поставил iPhone OS 4.0 beta 4, и PhoneView отказался к нему подключаться:

Разбирая архив на CD и DVD с фотографиями, я скопировал их все на жесткий диск. Воспользовавшись программой Tidy Up!, обнаружил массу дубликатов. Ну думаю, сейчас я их. Удалю. Да вот ничего подобного. На попытку переместить все выбранные файлы в корзину программа отвечает отказом удалить некоторые файлы в связи с тем, что они (файлы) залочены. Копировались с CD и DVD со всеми их свойствами. И это в самых разных директориях и поддиректориях. Интерфейс Tidy Up! не предусматривает пакетную разлочку таких файлов, средствами Mac OS X тоже сделать ничего не удалось. Может напишешь команду в терминале как разлочить все файлы в данном директории включая все поддиректории?

Речь шла о блокировке, которую в том числе можно сделать в Finder Get Info:

В процессе поиска решения нашёл документ Apple KB с главой “Advanced tip about deleting locked files“.

Блокировка файла в Finder обозначает установку флага uchg, также известного как “immutable flag”. Если файл заблокирован, то его нельзя удалить или изменить:

$ rm testfile.txt
override rw-r--r--  ctrld/staff uchg for testfile.txt? y
rm: testfile.txt: Operation not permitted

$ date > testfile.txt
-bash: testfile.txt: Operation not permitted

Снять флаг можно в консоли командой chflags:

$ chflags nouchg testfile.txt

Если вам нужно проделать эту операцию для большого каталога и его содержимого, то нужно использовать ключ “-R”:

$ chflags -R nouchg bigdirectory

Ключи ls для просмотра флагов:

$ ls -lO testfile.txt
-rw-r--r--  1 ctrld  staff  uchg 0 Mar 25 10:27 testfile.txt

Системы хранения заметок – достаточно интересная категория программ. Я до сих пор не нашёл идеальной программы, но постепенно движусь в этом направлении. Evernote не нравится сохранением web-страниц, Together – странной дисковой активностью, Yojimbo – отсутствием программы под iPhone.

Недавно в комментариях к статье “Синхронизация данных Yojimbo через Dropbox” мы с 8bituser обсуждали достоинства и недостатки двух систем хранения заметок (Together и Yojimbo). Я приведу его аргументы в пользу Together, они очень полезны:

А я с Yojimbo кое-как переполз на Together. У меня файл базы был 140мб, каждый бэкап тайммашины…

И потом хотелось как-то на айфоне иметь доступ ко всему этому. В Together всё хранится не в базе, а открыто. Сделал его базу прямо в стандартной папке Documents (по дефолту в папке Together, которая в Documents, так не очень удобно и не красиво показалось), скрыл то, что мне не надо (там порядка 8 папок и файл Together.lock, теперь имею там каталоги Notes, Documents, Web Pages, Images и их симлинкаю на дропбокс, и таким образом всё есть на айфоне, причем быстро, не 140мб каждый раз пересылать туда-сюда, а только новые или измененные файлы.

Ну и достаточно удобно к этим папкам доступ из Stacks в режиме List могу открыть любой файл даже без открытого самого Together.

Плюс когда в Together кидаешь кусочек чего-то со страницы, он запоминает линк страницы и можно даже этот кусочек подредактировать удалив что-то или добавив.

Смартфолдеры тоже есть, с тэгами тоже не особо складывается, разве что для тех же смартфолдеров они нужны помимо раскрашивания.

Из минусов только то, что кусочки с веб-страниц кидать нужно в Shelf, а не прямо на иконку в доке, но уже привык, а всё остальное очень похоже, чуть больше удобности и гибкости. Причем у этого Shelf очень удобно быстро заметку написать или скопипастить в него.

Одни плюсы вобщем, переходи, чем дальше с Yojimbo тем болезненней переход :))

Да, Yojimbo невозможно использовать на iPhone, и это его большой минус. Я до сих пор ещё не определился, оставаться ли на Yojimbo или переходить на Together. Мне больше нравится первый. Но пока я стараюсь вести заметки в обеих системах. Сравнительный анализ – это тема отдельной статьи.

Сейчас же я хочу показать, как можно обойти главную проблему Yojimbo, а именно то, что данные хранятся в базе данных SQLite3 в едином файле и малейшее изменение приводит к необходимости записи в Time Machine всего файла. Для небольших баз это несущественно, но если ваши данные занимают сотни мегабайт, то это становится уже ощутимой проблемой.

Идея проста – нужно разместить данные в SparseBundle Image. Этот образ представляет собой набор 8-ми мегабайтных файлов (band’ов), и при изменении его содержимого меняются далеко не все band’ы, что даёт возможность уменьшить объём данных, записываемых в бекап Time Machine.

Подготовка SparseBundle Image

Создать образ можно или через программу Disk Utility, или в консоли через hdiutil. Через графический интерфейс для меня сложнее, поэтому именно этот метод я и рассмотрю :-)

Запускаем Disk Utility (/Applications/Utilities/Disk Utility), создаём образ:

Я решил разместить образ в каталоге Documents, но вы его можете расположить там, где вам удобно. Параметры такие:

Мне достаточно пока 100 MB, формат файловой системы стандартный “Mac OS X Extended (Journaled)”, схему разделов я привычно поменял с “Apple Partition Map” на “GUID Partition Map“. Самое главное – поставить формат образа “sparse bundle disk image”.

Если вы хотите секретности, то можно создать образ с шифрацией AES (128 бит вполне достаточно, но у вас могут быть другие соображения):

Ту же самую операция можно выполнить и через консоль:

$ hdiutil create -size 100m -type SPARSEBUNDLE -imagekey \
  sparse-band-size=4096 -fs JHFS+X -volname Yojimbo -layout GPTSPUD \
  ~/Documents/Yojimbo

Так даже лучше поступить, так как можно изменить размер band’а со стандартных 8 MB до 2 MB (4096 512-байтовых блока) или даже до минимального значения 1 MB (2048 512-байтовых блока).

Увеличение размера образа

Размер образа я поставил 100 MB. При необходимости можно его увеличить. Через Disk Utility мне это сделать не удалось (система рапортовала, что размер изменён, затем о том, что образ не изменён):

2010-03-12 17:33:14 +0200: Growing partition 0 of “Yojimbo.sparsebundle” from 100 MB to 500 MB.
2010-03-12 17:33:14 +0200: Resizing “Yojimbo.sparsebundle” was successful.
2010-03-12 17:33:26 +0200: Image “Yojimbo.sparsebundle” will not be changed.

Поэтому я вернулся в любимую консоль и там это сделал быстро и логично.

Если образ уже примонтирован, то нужно его отмонтировать:

$ hdiutil eject /Volumes/Yojimbo

Увеличение максимального размера образа до 500 MB (обратите внимание, что размер образа увеличивается по необходимости, а не выделеятся весь заявленный размер):

$ hdiutil resize -size 500m ~/Documents/Yojimbo.sparsebundle

Если в образе было много изменений, то можно его сжать (но для данного случая это почти бессмысленно, предварительно нужно сделать vacuum на базу данных SQLite, и только потом сжимать образ):

$ hdiutil compact ~/Documents/Yojimbo.sparsebundle

Монтирование образа:

$ hdiutil mount ~/Documents/Yojimbo.sparsebundle

Образ также можно примонтировать, открыв его в Finder.

Я заодно меняю иконку для этого образа, перетаскивая png-файл, найденный в Google на иконку в Get Info:

Затем меняю иконку и для смонтированного образа:

Теперь всё красиво.

Автоподключение образа при старте системы

Воспользуемся небольшим трюком – для автоподключения образа нужно его поместить в Login Items пользователя. Заходим в “System Preferences/Accounts/Login Items”. Рядом открываем окно Finder с папкой Documents. Перетаскиваем образ Yojimbo.sparsebundle в список Login Items:

Теперь после старта системы образ будет смонтирован в точку /Volumes/Yojimbo. Если вы выбрали шифрацию, то лучше поставить автозапоминание пароля в KeyChain, иначе придётся каждый раз этот пароль вводить (но это опять-таки “up to you” – достаточно сомнительное решение вводить шифрацию, и по сути обходить эту шифрацию, ставя автоввод пароля).

Перенос данных Yojimbo в SparseBundle

Перед этой операцией данные уже должны быть, для чего нужно хотя бы раз запустить Yojimbo. Дальнейшие операции лучше проводить в терминале, “Alias” в Finder – это далеко не unix symbolic link. Да, из Yojimbo нужно выйти.

$ cd ~/Library/Application\ Support

Делаем резервную копию данных:

$ mv Yojimbo Yojimbo.backup

Создаём символический линк, говорящий, что все данные будут располагаться в смонтированном образе:

$ ln -s /Volumes/Yojimbo .
$ ls -al Yojimbo
lrwxr-xr-x  1 ctrld  staff  16 Mar 12 18:18 Yojimbo -> /Volumes/Yojimbo

Копируем все файлы, включая скрытые, начинающиеся с “.”. Сейчас перечень такой, но в других версиях он может поменяться, поэтому команду копирования возможно придётся адаптировать

$ ls -a Yojimbo.backup/
.ContentIndex.version	ContentIndex.skindex	Database.sqlite		State.plist
SyncState.plist
$ cp Yojimbo.backup/{.[A-Z]*,[A-Z]*} /Volumes/Yojimbo/
$ ls -a Yojimbo/
.ContentIndex.version	.fseventsd		Database.sqlite		SyncState.plist
.Trashes		ContentIndex.skindex	State.plist

Символический линк сделан. Запускаем Yojimbo, убеждаемся, что все данные на месте.

Но не беспокойтесь, если что-то пошло не так – старые данные есть в каталоге ~/Library/Application\ Support/Yojimbo.backup. Откат:

$ cd ~/Library/Application\ Support
$ rm Yojimbo
$ cp -r Yojimbo.backup Yojimbo

Эффект от перехода на SparseBundle Image

Как определить, что band поменялся? Достаточно посмотреть на время его модификации. Я сейчас покажу данные, которые я собрал для старого образа, в котором размер band был 8 MB.

После изменения одного комментария в 11:55 поменялись два файла – 0 и 1:

$ ls -al ~/Documents/Yojimbo.sparsebundle/bands
-rw-r--r--   1 ctrld  staff  8388608 Mar 11 11:55 0
-rw-r--r--   1 ctrld  staff  8388608 Mar 11 11:55 1
-rw-r--r--   1 ctrld  staff  8388608 Mar 11 11:26 2
-rw-r--r--   1 ctrld  staff  5386240 Mar 11 11:43 3
-rw-r--r--   1 ctrld  staff  2437120 Mar 10 20:51 5
-rw-r--r--   1 ctrld  staff   913408 Mar  9 16:21 6
-rw-r--r--   1 ctrld  staff  8388608 Mar  9 16:21 b
-rw-r--r--   1 ctrld  staff  1757184 Mar  9 16:21 c

Это значит, что в Time Machine будет помещены два файла суммарным размером 16 MB, но не весь файл базы данных 25.7 MB, как было бы без SparseBundle:

$ ls -al /Volumes/Yojimbo/Database.sqlite
-rw-r--r--@  1 ctrld  staff  26961920 Mar 11 11:50 Database.sqlite

Если уменьшить размер band до 2 MB, то количество файлов может уменьшиться. Конечно же, чем больше база данных, тем больше эффект.

Копируются ли данные в Time Machine из открытого образа SparseBundle Image?

Проделаю эксперимент. Запускаю Yojimbo и меняю один комментарий.

$ ls -al /Volumes/Yojimbo/Database.sqlite
-rw-r--r--@  1 ctrld  staff  26961920 Mar 11 12:00 Database.sqlite

$ ls -al ~/Documents/Yojimbo.sparsebundle/bands
-rw-r--r--   1 ctrld  staff  8388608 Mar 11 12:01 0
-rw-r--r--   1 ctrld  staff  8388608 Mar 11 12:01 1
-rw-r--r--   1 ctrld  staff  8388608 Mar 11 11:26 2
-rw-r--r--   1 ctrld  staff  5386240 Mar 11 12:00 3
-rw-r--r--   1 ctrld  staff  2437120 Mar 10 20:51 5
-rw-r--r--   1 ctrld  staff   913408 Mar  9 16:21 6
-rw-r--r--   1 ctrld  staff  8388608 Mar  9 16:21 b
-rw-r--r--   1 ctrld  staff  1757184 Mar  9 16:21 c

Поменялись три файла – 0, 1 и 3.

С помощью dtrace смотрю за файлами, которые обрабатывает демон backupd Time Machine:

open:entry backupd /Users/ctrld/Documents/Yojimbo.sparsebundle/bands/3
open:entry backupd /Users/ctrld/Documents/Yojimbo.sparsebundle/bands/0
open:entry backupd /Users/ctrld/Documents/Yojimbo.sparsebundle/bands/1

Да, при открытом образе данные помещаются в бекап (в отличие от домашнего каталога в FileVault без выхода из системы).

Восстановление данных из бекапа

А вот здесь моего терпения не хватило, продолжу в другой раз :-) Могу сказать, что первая попытка восстановления из бекапа прошла безупречно, но когда я начал повторять процесс, у меня возникли сложности с dtrace, и я отложил исследование.

После двухнедельного использования FileVault я перевёл свой домашний каталог на обычную схему без шифрования. Причина в том, что субъективно типичные файловые операции стали выполняться медленнее. Например, при открытии iTunes на списке приложений под iPhone процесс отрисовки иконок достаточно заметен. Были и другие случаи, которые мне доставляли дискомфорт. Мои данные не содержат каких-то критичных сведений, все пароли зашифрованы, поэтому я и откатился обратно. Сразу же почувствовал, что ноутбук стал летать.

Но до отката я провёл несколько тестов файловой системы программой QuickBench, чтобы показать различие в производительности при использовании FileVault и без него. Диск – штатный для MacBook Pro 2.8 GHz 500 GB 5400 rpm Hitachi.

Тест чтения/записи без FileVault:

Тест чтения/записи с FileVault:

При включенном FileVault при работе с данными чанки, из которых состоит SparseBundle Image, считываются в память и за счёт этого производится кеширование. Поэтому скорость последовательного чтения и записи, а также случайной записи высока до блоков 64 KB включительно, после чего резко падает и становится хуже, чем без использования FileVault. Особенно это проявляется для случайного чтения, которое как раз и применяется при операциях, похожих на загрузку иконок приложений в iTunes.

Тест чтения/записи файлов 2-10 MB без FileVault:

Тест чтения/записи файлов 2-10 MB c FileVault:

Скорость записи с включённым FileVault падает чуть ли не в 4 раза для файлов от 7 MB. Только для файлов 2 MB она высока за счёт размера чанка и кеширования. Скорость чтения не так сильно деградирует, но всё-таки процентов 15 есть.

Тест чтения/записи файлов 20-100 MB без FileVault:

Тест чтения/записи файлов 20-100 MB с FileVault:

Скорость записи с FileVault уменьшается процентов на 50%. Скорость чтения также страдает.

Делаем вывод, что некоторые операции с FileVault быстрее за счёт кеширования, но интегральная производительность хуже. Поэтому включать FileVault нужно только для тех случаев, когда это действительно необходимо. Если же вы хотите зашифровать свои данные, то лучше сделать отдельный шифрованный Sparse Bundle Image, в котором хранить только критичные данные (и не запоминать в KeyChain пароль к нему). Краткое описание, как его создать в Terminal.app, можно посмотреть в моей статье “Работа с образами дисков в Terminal.app (hdiutil)” (это же можно сделать и через Disk Utility).

Недавно я перешёл на криптование домашнего каталога через FileVault, до этого проанализировав вопрос в статьях “Влияние FileVault на производительность файловых операций” и “Производительность FileVault при параллельной файловой активности“. Результаты были хороши. Реальное же использование криптования слегка подкорректировало моё мнение – да, с включённым FileVault система работает при определённых операциях медленнее.

В итоге я понял, что большинство моих данных не настолько секретно, а действительно приватные данные можно скрыть в закриптованном образе Sparse Bundle, и жертвовать производительностью ради секретности для меня смысла нет.

Для того, чтобы упростить обратную конвертацию, я решил вынести самые большие каталоги временно из домашнего каталога. Привычный алгоритм выглядел просто – перенести Music, Photos, Videos, а дальше запустить консоль и, итеративно запуская “du -ks * | sort -rn”, найти оставшихся пожирателей дискового пространства.

$ cd ~
$ du -ks * | sort -rn
9155148	Library
4267588	Documents
546600	Dropbox
340496	Music
7712	Woopra
100	bin
...
$ cd Library
$ du -ks * | sort -rn
...

Этот метод хорош. Но он не из разряда “Mac Way”. И тут я вспомнил о программе DaisyDisk, которая является по сути красивой заменой приведённому выше процессу. Программа платная, стоит $19.95, но для разового поиска можно использовать программу в триальном режиме. Программа хорошая, и я её купил, зная, что она не раз мне ещё пригодится.

Немного пройдусь по функциям DaisyDisk в приложении к моей задаче. Стартовая точка – выбор диска или каталога, который нужно проанализировать:

Вы видите, почему я занялся переносом – на диске осталось мало места, и провести конвертацию домашнего каталога мне вряд ли удалось. Результат работы:

Можно спускаться в любой каталог и смотреть, что же занимает столько места, причём, в отличие от “du -ks *”, не нужно хранить результаты сканирования предыдущих каталогов. При наведении на каталог его графическое представление начинает мерцать.

Представляется весь диск. Внутреннее кольцо – каталоги относительно корневого, дальше идут дочерние. Например, можно пройтись по кругам, выявляя, что же занимает больше всего места.

Круг первый:

Круг второй:

Круг третий:

На уровне файлов можно запустить Preview, нажав пробел:

Да, я опечатался, написав “Треккинг в Непала”, хочется добавить в стиле юмористов “начАльника”. Но перерендерить фильм руки не доходят, тем более, что он только для себя и друзей.

Чтобы перейти на файл или каталог в Finder, достаточно нажать ” ⌘ + Click”, и по месту решить, что делать с объектом – удалять или нет:

Если какие-то каталоги недоступны для пользователя, то их просканировать можно, включив режим “Суперпользователя”:

DaisyDisk сканирует быстро весь диск. Как она это делает? Нет, она не делает это очевидным образом через проход по дереву. Она использует псевдокаталог /.vol, в котором анализирует inode:

open:entry DaisyDisk /.vol/234881026/9058507
open:entry DaisyDisk /.vol/234881026/9058511
open:entry DaisyDisk /.vol/234881026/8746896
open:entry DaisyDisk /.vol/234881026/9031043

В /.vol первое число обозначает Volume ID (идентификатор файловой системы), а второе – inode файла. А вот траверс файловой системы на базе inode – это отдельный вопрос.

$ ls -al /.vol/234881026/9058507
total 0
drwx------   3 ctrld  wheel  102 Feb 18 08:58 .
drwxrwxrwt  27 root   wheel  918 Feb 18 17:54 ..
srwx------   1 ctrld  wheel    0 Feb 18 08:58 Render

Следствие этого механизма сканирования: выполнить нахождение больших файлов внутри каталога FileVault текущего пользователя программа не может, она отображает его как обычный SparseBundle.

Однако решение есть – нужно просканировать не диск, а конкретный каталог, в итоге его содержимое будет проанализировано:

Программа проста, но тем не менее полезна. На мой взгляд она стоит каждого доллара из $19.95. Рекомендую.

В предыдущей статье “Схемы разделов в Mac OS X. GUID partition table. Часть 1 (MBR)” мы рассмотрели “Protective MBR”. Сегодня займёмся следующей структурой – Partition Table Header.

Напомню, что я использую такие спецификации:

• Extensible Firmware Interface Specification 1.10, раздел 11.2.2, страница 367.
• UEFI Specification Version 2.3, раздел 5 “GUID Partition Table (GPT) Format”, страница 91.

В нулевом блоке на диске находится Protective MBR. В следующем же – GUID Partition Table Header. Это структура, описывающая различные данные по диску, включая GUID для уникальной идентификации диска, адрес стартового блока массива записей о разделах, размер записи в этом массиве и т.д.

Формат описан в таблице:

За время, прошедшее с прошлой статьи о GPT, диск, на котором я ставил эксперименты, успел уйти под другие задачи, поэтому продолжим на флеш-драйве 8GB с GUID, разбитом на два раздела:

$ diskutil list /dev/disk3
/dev/disk3
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *8.0 GB     disk3
   1:                        EFI                         209.7 MB   disk3s1
   2:                  Apple_HFS Flash1                  4.0 GB     disk3s2
   3:                  Apple_HFS Flash2                  3.6 GB     disk3s3

Считываем Partition Table Header:

sudo dd if=/dev/disk3 of=/dev/stdout bs=512 count=1 skip=1 2>/dev/null | hexdump -C
00000000  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI PART....\...|
00000010  9b 3c cb 8f 00 00 00 00  01 00 00 00 00 00 00 00  |.<..............|
00000020  ff 5f ef 00 00 00 00 00  22 00 00 00 00 00 00 00  |._......".......|
00000030  de 5f ef 00 00 00 00 00  0d 70 a7 c1 50 34 a3 40  |._.......p..P4.@|
00000040  99 45 46 0a 87 cf 8c 9a  02 00 00 00 00 00 00 00  |.EF.............|
00000050  80 00 00 00 80 00 00 00  25 4d a5 b6 00 00 00 00  |........%M......|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200

Напомню, что BlockSize не обязательно 512, его можно узнать для каждого конкретного случая через вызов ioctl с селектором DKIOCGETBLOCKSIZE - программу я привёл в статье "Получение информации по диску через ioctl". На нашем диске BlockSize=512.

• 00-07 (0x00-0x07) 8 байт. Signature. 45 46 49 20 50 41 52 54 = "EFI PART".
• 08-11 (0x08-0x0B) 4 байт. Revision. 00 00 01 00 = 0x00010000 = Номер ревизии 1.0.
• 12-15 (0x0C-0x0F) 4 байт. HeaderSize. 5c 00 00 00 = 0x0000005c = 92 байтов.
• 16-19 (0x10-0x13) 4 байт. HeaderCRC32. 9b 3c cb 8f. Для того, чтобы вычислить CRC32, в это поле записываются нули, после чего CRC32 считается для блока размером HeaderSize, т.е. для 92 байт.

Для вычисления CRC32 я воспользовался кодом на C. Пожалуй, отдельно напишу программу для разбора GPT, сейчас же воспользуюсь скомпилированным кодом и Hex Fiend для "обнуления".

Считываем нужный нам блок в файл 1.dump:

$ sudo dd if=/dev/disk3 of=1.dump bs=512 count=1 skip=1

Считываем из него 92 байта и записываем в 2.dump (здесь поле HeaderCRC32 ещё не обнулено):

$ sudo dd if=1.dump of=2.dump ibs=1 obs=1 count=92

Запускаем Hex Fiend, обнуляем байты 0x10-0x13 и записываем в файл 3.dump:

В HeaderCRC32 было значение 9B 3C CB 8F = 0x8FCB2C9B. Запускаем вычисление CRC32:

$ ./crc_32 3.dump
FFFFFFFF8FCB3C9B      92 3.dump

Что и требовалось доказать, CRC32 верен.

• 20-23 (0x14-0x17) 4 байт. Reserved. 00 00 00 00. Все нули.
• 24-31 (0x18-0x1F) 8 байт. MyLBA. 01 00 00 00 00 00 00 00. Да, Partition Table Header начинается с 1-го блока (а MBR protective - с 0-го).
• 32-39 (0x20-0x27) 8 байт. AlternateLBA. ff 5f ef 00 00 00 00 00 = 0xEF5FFF = 15687679. Адрес альтернативной Partition Table Header. Детальнее смотрите описание к LastUsableLBA.

Проверим, действительно ли по адресу AlternateLBA находится Partition Table Header:

$ dd if=/dev/disk3 of=/dev/stdout bs=512 count=1 skip=15687679 2>/dev/null | hexdump -C
00000000  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI PART....\...|
00000010  fc 0d 5b f0 00 00 00 00  ff 5f ef 00 00 00 00 00  |..[......_......|
00000020  01 00 00 00 00 00 00 00  22 00 00 00 00 00 00 00  |........".......|
00000030  de 5f ef 00 00 00 00 00  0d 70 a7 c1 50 34 a3 40  |._.......p..P4.@|
00000040  99 45 46 0a 87 cf 8c 9a  df 5f ef 00 00 00 00 00  |.EF......_......|
00000050  80 00 00 00 80 00 00 00  25 4d a5 b6 00 00 00 00  |........%M......|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200

Да, так и есть, это копия PTH.

• 40-47 (0x28-0x2F) 8 байт. FirstUsableLBA. 22 00 00 00 00 00 00 00 = 0x22. Посмотрите, как вычисляется размер массива Partition Entry в описании поля SizeOfPartitionEntry. Первый блок на диске занят под Protective MBR, второй - под Partition Entry Header, затем в 0x20 блоках находится Partition Entry Array, т.е. занято 0x22 блока. Адресация блоков начинается с нуля, значит разделы можно располагать на диске, начиная с блока 0x22.
• 48-55 (0x30-0x37) 8 байт. LastUsableLBA. de 5f ef 00 00 00 00 00 = 0xEF5FDE = 15687646. Последний блок, который можно использовать под разделы.

Давайте посмотрим причину. Размер диска посмотрим в diskutil:

$ diskutil info /dev/disk3 | grep "Total Size:"
   Total Size:               8.0 GB (8032092160 Bytes) (exactly 15687680 512-Byte-Blocks)

TotalDiskSize = 15687680 = 0xEF6000
LastUsableLBA = 15687646 = 0xEF5FDE
AlternateLBA  = 15687679 = 0xEF5FFF

Схема GPT Partition Table показана на рисунке:

Alternate Partition Table Header находится в последнем блоке на диске, нумерация с нуля, т.е. она находится в блоке (TotalDiskSize - 1) = 0xEF6000 - 1 = 0xEF5FFF. Так и есть, этот адрес мы видели в поле AlternateLBA.

Перед Alternate Partition Table Header располагается копия Partition Entry Array размером 0x20 (смотрите комментарий к SizeOfPartitionEntry). 0xEF5FFF - 0x20 = 0xEF5FDF. Т.е. Partition Entry Array начинается с блока 0xEF5FDF, а последний блок, доступный для разделов, является 0xEF5FDE, и это значение мы видели в поле LastUsableLBA.

• 56-71 (0x38-0x47) 16 байт. DiskGUID. 0d 70 a7 c1 50 34 a3 40 99 45 46 0a 87 cf 8c 9a. К сожалению, пока я не нашёл, как генерируется это поле.
• 72-79 (0x48-0x4F) 8 байт. PartitionEntryLBA. 02 00 00 00 00 00 00 00 = 2. Массив GUID Partition Entry начинается со второго блока диска.
• 80-83 (0x50-0x53) 4 байт. NumberOfPartitionEntries. 80 00 00 00 = 0x80 = 128. Это максимальное количество разделов на диске.
• 84-87 (0x54-0x57) 4 байт. SizeOfPartitionEntry. 80 00 00 00 = 0x80 = 128 байт. Размер каждой записи Partition Entry равен 128 байт. Имея размер массива разделов и размер записи, получаем размер массива. 0x80 x 0x80 = 0x4000 = 16384 байт = 32 блока = 0x20
• 88-91 (0x58-0x5B) 4 байт. PartitionEntryArrayCRC32. 25 4d a5 b6 = 0xB6A54D25.

PartitionEntryArray начинается со второго блока и его размер 0x20 = 32 блоков:

$ sudo dd if=/dev/disk3 of=pea1.dump bs=512 count=32 skip=2

Проверяем CRC32:

$ ./crc_32 pea1.dump
FFFFFFFFB6A54D25   16384 pea1.dump

Вычисленное CRC32 совпадает с записанным в PartitionEntryArrayCRC32, всё верно.

• 92-BlockSize (0x5C-0x1FF) 512-92=420 байт. Reserved. 00 ... 00. Все нули.

Partition Table Header мы разобрали, в следующей части (последней) разберём Partition Entry Array. Заодно попробую найти, как генерируется DiskGUID.