Pull to refresh

SSD и native boot VHD: а счастье было так близко…

Reading time 4 min
Views 18K
Коллеги, хотелось бы вновь обсудить вопрос увеличения ресурса 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-диска.

Решено было потратить пару часов и изучить под микроскопом сам загрузчик (Windows\System32\winload.exe и Windows\System32\winload.efi) начиная с Windows 7. После этого всё стало на свои неутешительные места:
  1. Windows 7 — в загрузчике присутствует код только для работы с дисками формата VHD
  2. Windows 8/2012 — в загрузчике присутствует код для работы как с VHD так и с VHDX дисками… но в нём присутствует работа только с относительным путём (relative_path) к родительскому диску. И даже прописывание в этот параметр пути с GUID не даёт положительного результата
  3. Windows 8.1/2012R2 — загрузчик несколько вырос по размеру, но полноценной реализацией работы с VHDX так и не обзавёлся

Заключение


Таким образом получается, что Windows 8/2012 содержит в своём арсенале технологию создания гибридных дисковых систем, которая потенциально может увеличить ресурс SSD+HDD в разы. Но эта технология почему-то не до конца реализована в загрузчике, ввиду чего невозможно применить её на практике. Остаётся только надеяться, что в следующем обновлении (или релизе) загрузчик будет доработан.

Пока что остаётся рассматривать только вариант с классическим ускорением работы виртуальных машин: хостовая ОС размещается на HDD, базовый диск виртуальных машин размещается на SSD и создаётся снапшот на HDD, который периодически объединяется с базовым диском (по заданию или, например, при достижении размера снапшота в 1Гб). Ну или просто дождаться, когда SSD хотя бы сравняются с HDD по цене/объёму.

Хотелось бы также узнать мнение читателей по вопросу есть ли смысл таким образом увеличивать ресурс SSD? Может быть у сообщества есть ещё какие-нибудь идеи как организовать описанную схему? Может быть я что-то упустил?

Большое спасибо за уделённое внимание!
Tags:
Hubs:
+3
Comments 36
Comments Comments 36

Articles