Вот, например, данные на моём 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.

Вчера я рассмотрел производительность файловых операций при включенном и выключенном FileVault без дополнительной нагрузки. Для полноты картины я решил хоть слегка приблизиться к схеме типичного использования компьютера – ведь редко бывают ситуации, когда файловые операции не идут параллельно. Если запущен браузер и, например, torrent-клиент, то и первый, и особенно второй активно обращаются к диску.

Поэтому я запустил сканирование файловой системы с чтением из каждого найденного файла 100 блоков (51200 байт) и записью их в один файл. И параллельно запустил бенчмаркинг iozone.

Основной скрипт mainread.sh:

#!/bin/bash
while true ;
do
	find / -type f -print -exec /Users/test/read.sh {} \;
done

Вспомогательный скрипт read.sh:

#!/bin/sh
dd if="$1" of=/Users/test/tmp/test.bin count=100 2> /dev/null

Результат представлен ниже. Я добавил во вчерашнюю таблицу данные по работе с параллельной нагрузкой:

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

Уже года полтора, проезжая по ул. Глыбочицкой возле магазина Эльдорадо, на офисе страховой компании “N” я вижу огромное объявление о том, что из автомобиля украден ноутбук, но ворам предлагают полную стоимость ноутбука в обмен на его возвращение. Объявление уже растрёпано и части его нет. Я сомневаюсь, что ноутбук вернули. В этом случае железо по сравнению с данными стоит копейки. Вариант полной потери данных рассматривать не будет – конечно же, бекапы нужно иметь обязательно (причём диск с ними не должен храниться в сумке с ноутбуком). Давайте подумаем о том, что к данным может получить доступ злоумышленник – либо конкурент, либо просто “интересующийся”, который может использовать данные в своих целях. Страшно представить, если на ноутбуке хранятся базы данных по персональным данным и кредитным картам клиентов.

Неискушённые люди думают, что пароль на вход в систему (а скорее всего его нет) может спасти данные от чужих глаз. Да, но замок спасает от честных людей – воры его взломают за секунды. И что дальше? Имея физический доступ, можно не напрягаясь сбросить пароль входа в Mac OS X или получить административный доступ за 5 минут. А уже администратор получит доступ ко всем данным, если они находятся в открытом виде.

Здесь на помощь приходит штатная технология FileVault. Домашний каталог находится в зашифрованном по алгоритму AES-128 образе SparseBundle (в 10.5 для удобства резервного копирования через TimeMachine от монолитных образов Sparse Image перешли к набору файлов по 8 MB). К сожалению, для того, чтобы Time Machine провела резервное копирование каталога FileVault, нужно выйти из системы (сделать logout, а не shutdown).

Меня сдерживали от перехода на FileVault логичные мысли о уменьшении производительности файловых операций. Это был голос здравого смысла, но пришло время узнать, насколько замедляет работу системы включение FileVault.

Для тестирования я создал двух пользователей – одного с включённым FileVault, второго – с обычным домашним каталогом. Для каждого из них я по очереди запустил утилиту IOZone (это кроссплатформенная утилита с открытыми исходными кодами, она работает как на Unix, так и на Windows).

Описание тестов есть в документации IOZone (PDF). В заголовке указаны размеры блоков от 64 до 16384 KB, на которых производится тестирование. Значения приведены в KB в секунду. “8192 On” – тест при включённом FileVault, “8192 Off” – с выключенным. В процентах сравнивается разница в производительности между включенным и выключенным FileVault – 116% обозначает потеря 16% производительности на FileVault. Запуск: “/opt/local/bin/iozone -aRb fv1.xls”.

Результаты для размера файла 8196 KB (таблицу можно увеличить):

В среднем падение производительности для размера файла 8196 составило от 0 до 12%.

Результаты для размера файла 524288 KB:

В среднем падение производительности минимально, есть даже эффект кеширования, когда производительность улучшается (пример – Record Rewrite Test). Занятость CPU было не слишком значительным, к сожалению, у меня не было возможности произвести интервальные измерения.

Резюме. На тестах IOZone потеря производительности FileVault не настолько значительна, как казалось, средние 12% это отличная плата за безопасность данных.

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

Как я писал ранее, схема разделов Apple Partition Map не приспособлена к использованию на больших дисках – из-за 32-битных счётчиков максимальный размер диска при размере блока 512 байт может быть лишь 2 TB.

Apple серьёзно прорабатывала возможность адаптации Apple Partition Map для поддержки больших дисков, однако требуемые изменения привели бы к неработоспособности всех инструментов, работающих с разделами, поэтому было принято разумное решение переключиться на принципиально новую схему. После серьёзных размышлений Apple решила использовать GPT.

Схема разделов GUID partition table (GPT) была представлена Intel как часть реализации комплексной задачи по переходу на современное firmware для Intel-совместимых компьютеров. Традиционно на них было установлено firmware BIOS, использующее схему разделов Master Boot Record (MBR). Схема MBR имела большое количество ограничений, не позволяющих использовать её на современных компьютерах. Для преодоления этих ограничений компания Intel разработала современное firmware Extensible Firmware Interface (EFI), включающее в себя новую схему разделов GPT.

Одним из больших преимуществ схемы GPT было то, что она была закреплена в формальных стандартах (документы доступны для списывания):

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

В статье я использую такие источники:

• “Technical Note TN2166. Secrets of the GPT.“
• Книга “Mac OS X Internals. A Systems Approach”.
• Apple’s Transition from Apple Partition Map to the GUID Partition Tabl
• Стандарт “Extensible Firmware Interface Specification 1.10“
• Стандарт “UEFI Specification Version 2.3“

Вопрос о GPT не помещается в одну статью, поэтому я разобью его на три части:

1. Protective MBR
2. Partition Table Header
3. Partition Entry Array

Обзор GPT

GPT простая, но эффективная схема разделов. Общая схема использования блоков показана в таблице (n – количество блоков на диске, b – количество блоков, использующихся для описания массива с записями о разделах, обычно 32):

Меня лично восхитил блок 0 “Protective MBR” – это отличная “защита от дурака”. В нём в формате MBR вся область, используемая под схему разделов GPT и разделы GPT определены, как один раздел. Таким образом программы работы с разделами, ничего не знающие о GPT, не смогут случайно ничего изменить (конечно же, от намеренного изменения никто защитить не сможет). Такие программы видят диск GPT, как диск MBR с одним разделом неизвестного типа (0xEE).

GPT использует логическую адресацию блоков на диске Logical Block Addressing (LBA) в отличие от старой адресации Cylinder-Head-Sector (CHS). Размер блока обычно 512 байт, но он может быть и другим. Штатных утилит для просмотра размера блока я не нашёл, поэтому использую программу из книги “Mac OS X Internals” – для моего диска он действительно 512 байт.

В графическом виде GPT выглядит так (128 разделов – столько зарезервировано в Windows 2003 Server, насчёт Mac OS X посмотрим дальше):

Для экспериментов будем использовать USB-диск со схемой разделов GPT и двумя разделами:

LBA 0. Protective MBR

Формат MBR описан в таблице (из Unified Extensible Firmware Interface Specification):

PartitionRecord описан в следующей таблице. В описании указан общий формат, а после пометки GPT то, что должно быть для Protective MBR.

Первый (нулевой) блок содержит такие данные:

$ sudo dd if=/dev/disk4 of=/dev/stdout bs=512 count=1 skip=0 2>/dev/null | hexdump -C
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 fe  |................|
000001c0  ff ff ee fe ff ff 01 00  00 00 af ea 42 25 00 00  |............B%..|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200

MBR:
• 0000 440 bytes. BootCode. Все нули.
• 01B8 4 bytes. UniqueMBRSignature. 00 00 00 00.
• 01BC 2 bytes. Unknown. 00 00.
• 01BE 64 bytes. PartitionRecord (4 x 16-ти байтовых записей в формате IBM Partition Table). 00 fe ff ff ee fe ff ff 01 00 00 00 af ea 42 25
• 01FE 2 bytes. MBR signature (0xAA55). 55 AA – в обратной нотации (так уж повелось).
• Если размер блока больше 512 байт, то остальное – Reserved. Для нашего случая блок – 512

Рассмотрим информацию о разделе (00 fe ff ff ee fe ff ff 01 00 00 00 af ea 42 25)
• 0×00 1 byte. BootIndicator (0×80 = bootable/active, 0×00 = non-bootable, other = invalid). 00 – non-bootable.
• 0×01 3 bytes. StartingCHS. fe ff ff. Это древняя жуть, не будем искать разгадку – кто знает, куда нас заведёт это знание? Хорошо, что в EFI это не используется.
• 0×04 1 byte. OSType. Есть хороший ресурс со всеми типами разделов. 0xEE = Indication that this legacy MBR is followed by an EFI header.
• 0×05 3 bytes. EndingCHS. fe ff ff. Аналогично.
• 0×08 4 bytes. StartingLBA. 01 00 00 00 в обратной нотации читается как 00 00 00 01. Вспоминаем таблицу – “Must be 0×00000001″.
• 0x0C 4 bytes. SizeInLBA in little-endian format. af ea 42 25 = 0x2542eaaf = 625142447 блоков

Для проверки количества блоков посмотрим информацию по диску:

$ diskutil info disk4 | grep "Total Size"
   Total Size:               320.1 GB (320072933376 Bytes) (exactly 625142448 512-Byte-Blocks)

Количество блоков в разделе 625142447, один блок – MBR, что даёт требуемое количество блоков на диске 625142448. В итоге программы, знающие только об MBR будут действительно видеть диск MBR с одним разделом типа 0xEE.

To be continued…

В следующей части разберём “Partition Table Header”.

В предыдущей статье я привёл описание раскладки разделов “Universal HD” для Apple Partition Map. Спасибо @akaDimiG – он натолнул меня на мысль посмотреть на таблицу разделов на установочном диске Mac OS X. Здесь используется раскладка APM “Universal CD”.

Mac OS X 10.5 Install DVD

$ pdisk /dev/rdisk3 -dump

Partition map (with 2048 byte blocks) on '/dev/rdisk3'
 #:                type name       length   base    ( size )
 1: Apple_partition_map Apple          15 @ 1
 2:  Apple_Driver_ATAPI Macintosh  302596 @ 16      (591.0M)
 3:           Apple_HFS Mac_OS_X  3756752 @ 302612  (  7.2G)
 4:          Apple_Free                 4 @ 4059364

Device block size=2048, Number of Blocks=4059368 (7.7G)
DeviceType=0x0, DeviceId=0x0

Mac OS X 10.4 Install DVD

$ pdisk /dev/rdisk3 -dump

Partition map (with 512 byte blocks) on '/dev/rdisk3'
 #:                type name        length   base     ( size )
 1: Apple_partition_map Apple           63 @ 1
 2:  Apple_Driver_ATAPI*Macintosh        8 @ 64
 3:           Apple_HFS Mac_OS_X  11059160 @ 72       (  5.3G)
 4:          Apple_Free                 10 @ 11059232

Device block size=512, Number of Blocks=11059242 (5.3G)
DeviceType=0x0, DeviceId=0x0
Drivers-
1:   4 @ 64, type=0x701

Обратите внимание на раздел 2 (Apple_Driver_ATAPI) – здесь располагаются драйвера под Mac OS 9 для ATAPI CD.