Коллеги, хотелось бы вновь обсудить вопрос увеличения ресурса SSD.
Идея, думаю, не нова и заключается в следующем: создать разностный VHD, базовая часть которого будет храниться на SSD, а разница (сравнительно небольшая) на HDD. Таким образом значительно сокращается количество записей на SSD, а т.к. работающая система пишет не так много данных (и соответственно читает из этой области также не много), то размещение этой информации на HDD не должно привести к значительному падению производительности. Далее необходимо только периодически производить слияние дисков для поддержания производительности системы на должном уровне. Однако не всё оказалось так просто…
Окружение
Основная задача — иметь под рукой достаточно производительную и отзывчивую среду (что обеспечивается наличием в системе SSD) в виде хоста и виртуальных машин различного назначения.
Основная проблема — множество операций записи, которые генерирует хост и виртуальные машины при работе, что отрицательно сказывается на ресурсе SSD.
В качестве основного подопытного был выбран достаточно свежий Windows 2012 Server R2 (имеется большой интерес к RemoteFX). Но та же идея увеличения ресурса SSD будет справедлива и для Windows 8.1 Pro (только начиная с этой редакции поддерживается native boot, но отсутствует RemoteFX). Вариант с размещением на хосте только гипервизора (например, VMWare ESXi на быстрой USB 3.0 флешке) был отвергнут ввиду острой необходимости использовать всю мощь хоста в играх и другом требовательном к железу ПО.
В интернет есть множество статей о том, как установить операционную систему на VHD и запустить её в нативном режиме. Но все статьи описывают либо установку на VHD фиксированного размера, либо на разностный диск на том же томе, что и базовый. Об этой особенности работы с разностными дисками сказано на технете.
Изучаем вопрос
Изучение спецификации формата VHD показало, что в файле формата VHD может указываться относительный и абсолютный путь к родительскому образу.
Относительный путь сразу отбраковывается, а вот абсолютный стал интересным вариантом. Но практика показала, что есть явная проблема с тем, что буква диска назначается в неизвестный момент загрузки системы и, первая мысль, что не работает именно поэтому. Но в среде Windows есть ещё один способ адресации — через явное задание GUID тома вместо буквы, например: \?Volume{d460911b-7eb4-11e2-b6f8-806e6f6e6963}image.vhd
Для упрощения проверки был создан виртуальный диск с длинным именем (C:1234567890123456789012345678901234567890123456image.vhd) и разностный диск (D:image_diff.vhd). Открыв разностный VHD hex-редактором можно найти соответствующую ссылку на родительский VHD и изменить путь на \?Volume{d460911b-7eb4-11e2-b6f8-806e6f6e6963}image.vhd… После этого диск монтируется в систему через diskpart. Но… Установленная на него система не работает: ошибка 0xC03A000D (проблема с цепочкой образов диска). При первом приближении показалось, что проблема кроется в том, что при использовании жёсткого диска с MBR система генерирует случайные GUID для томов и какой GUID назначен томам — не известно.
Дальнейшее изучение вопроса показало, что начиная с Windows 8/2012 появился формат дисков VHDX и они также поддерживают Native boot. В спецификации по VHDX найдено упоминание о том, что в файлах данного формата изначально предусмотрено сохранение пути к родительскому VHDX в формате пути с указанием GUID тома (так называемый volume path). При этом оговаривается даже порядок поиска родительского диска: relative path, volume path, absolute win32 path.
После изучения созданного разностного диска формата VHDX и в hex-редакторе стало понятно, что действительно данная информация сохранена в файле. Однако сохраняется проблема с GUID томов MBR дисков. Но это решилось разбиением диска под GPT. При таком варианте разбиения диска GUID тома становится постоянным. При этом базовый диск должен располагаться на томе GPT, а разностный может размещаться как на диске GPT, так и на диске MBR.
Были проведены опыты по запуску системы с различными сочетаниями дисков и загрузчиков (BIOS, EFI), но результатов они не принесли. Система по-прежнему отказывается загружаться при разнесении файлов VHDX-диска.
Решено было потратить пару часов и изучить под микроскопом сам загрузчик (WindowsSystem32winload.exe и WindowsSystem32winload.efi) начиная с Windows 7. После этого всё стало на свои неутешительные места:
- Windows 7 — в загрузчике присутствует код только для работы с дисками формата VHD
- Windows 8/2012 — в загрузчике присутствует код для работы как с VHD так и с VHDX дисками… но в нём присутствует работа только с относительным путём (relative_path) к родительскому диску. И даже прописывание в этот параметр пути с GUID не даёт положительного результата
- Windows 8.1/2012R2 — загрузчик несколько вырос по размеру, но полноценной реализацией работы с VHDX так и не обзавёлся
Заключение
Таким образом получается, что Windows 8/2012 содержит в своём арсенале технологию создания гибридных дисковых систем, которая потенциально может увеличить ресурс SSD+HDD в разы. Но эта технология почему-то не до конца реализована в загрузчике, ввиду чего невозможно применить её на практике. Остаётся только надеяться, что в следующем обновлении (или релизе) загрузчик будет доработан.
Пока что остаётся рассматривать только вариант с классическим ускорением работы виртуальных машин: хостовая ОС размещается на HDD, базовый диск виртуальных машин размещается на SSD и создаётся снапшот на HDD, который периодически объединяется с базовым диском (по заданию или, например, при достижении размера снапшота в 1Гб). Ну или просто дождаться, когда SSD хотя бы сравняются с HDD по цене/объёму.
Хотелось бы также узнать мнение читателей по вопросу есть ли смысл таким образом увеличивать ресурс SSD? Может быть у сообщества есть ещё какие-нибудь идеи как организовать описанную схему? Может быть я что-то упустил?
Большое спасибо за уделённое внимание!
Автор: Landgraph
