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

Коллеги, хотелось бы вновь обсудить вопрос увеличения ресурса 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? Может быть у сообщества есть ещё какие-нибудь идеи как организовать описанную схему? Может быть я что-то упустил?

Большое спасибо за уделённое внимание!
Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 36

    +16
    Имхо, не имеет смысл устраивать эти танцы с бубном. На практике не встречал еще умерших SSD от исчерпания ресурса перезаписи, у ранних партий встречались глючные, умирающие контроллеры, а так проблем нет.
      0
      А у меня на древнем SSD из EeePC 900 скорость доступа к диску просела до десятка IOPS, работать стало почти невозможно. Хотя в новых SSD такие проблемы редко встречаются, насколько я знаю
        +4
        Могу предположить, что там отсутствует TRIM.
          +1
          это очень стрые SSD уже, правда. сейчас любой недорогой будет превышать их проиводительность на порядки
          +4
          Интересную информацию по ресурсу современных SSD встретил тут.

          Оказывается, современные SSD и 500Tb записи выдерживают без проблем, что серьезно превышает гарантированный производителем ресурс.
            0
            о, ценный коммент! огромное спасибо за ссылку.
              0
              на самом деле, там написано немножко странные вещи :)
              на примере Samsung 840 Pro 256 Gb:

              ресурс перезаписи памяти: 3000 раз, объём 256 gb, суммарное количество данных которое можно перезаписать = 750 Tb.
              что в почти полтора раза больше чем проверенные ими 500 Tb.

              Конечно если говорить о Evo-серии, или в целом о памяти с ресурсом 1000 циклов перезаписи — тогда это серьезные цифры,
              хотя все равно надо учитывать объём накопителя, т.к. например при одном и том же ресурсе накопитель вдвое большего объёма прожует (не сдыхая) вдвое больший объём данных. Это такой неочевидный момент после HDD :)
                0
                Полный идеальный ресурс, основанный на жизнеспособности ячеек памяти и ресурс, заявленный производителем для накопителя, это разные вещи.

                Intel's 335 Series 240GB — Intel гарантирует ресурс записи в 20Gb в день в течение трех лет. Это 22Tb.

                Полный идеальный ресурс при записи учитывать не совсем верно потому, что запись двух байт информации может привести к записи в два полных Flash блока, а они размером по 8Кб примерно, перезаписывается блок целиком (информация из статьи).
                  0
                  А откуда информация про 1000 на EVO? Я тогда вообще попал, т.к., см. ответ ниже про методику подсчёта, у меня тогда ресурс вообще ориентировочно падает до:

                  128*0,25*1000 = 32Тб

                  и вообще не выглядит таким впечатляющим как 750Тб…
                    0
                    Evo и Intel 520 точно умеют ремапить весь диск.

                    Еще 520-тка жмет записываемые данные, т.е. записав 1 Гб ноликов реально потратится что-то вроде 50 Мб места. Насчет Evo не знаю.
                      0
                      жмут точно все на базе SandForce
              +2
              А как насчёт — сделать огромным по размеру системный раздел HDD, поставить на него ОС + все виртуалки и при этом использовать Intel Rapid Storage для данного раздела?
                0
                Я правильно понимаю, что речь идёт об Intel Smart Response в данном случае? Не совсем понятно как эта технология поведёт себя с виртуальными машинами, попробую протестировать.
                  0
                  Да, я имею ввиду именно её.

                  Хз как с виртуалками, но так — работает прост она ура!

                  Под так я понимаю быструю загрузку ОС и всех приложений, а также быстрый отклик монстров типа автокада, аркгиса и т.д.
                    +1
                    Учитывая, что Vista и выше, если считают, что диск HDD — группируют часто используемые фрагменты исполняемых файлов, а W8 и выше еще и дефрагментирует NTFS-структуры на лету с учетом оптимизации seek-ов, то в теории (и в принципе по моим опытам подтверждалось) имеет смысл, действительно, либо использовать ISR, либо размещать на SSD разностные диски, а базовый образ — на HDD (т.е. наоборот по сравнению с подходом, который пытался реализовать автор поста)

                    Я в итоге просто перешел на Intel'овские SSD и успокоился. По деньгам и времени на обслуживание выходит дешевле, чем городить гибридные системы или менять дешевые и глючные SSD-шки.

                    Насчет ресурса я написал ниже, дублировать коммент не буду.
                +3
                А примонтировать диск не как «D:», а как «C:\D\» и использовать относительный путь в vhd?

                Но, по-моему, низкий ресурс SSD на запись, это уже urban myth.
                Пару лет как полностью перешел на SSD, используются в хвост и гриву — свопы, бакапы, виртуалки без поддержки TRIM — и никаких проблем.
                По SSDLife — они еще меня переживут.
                  0
                  Тоже думал так сделать, проверил, не работает, видимо монтирование происходит позже при загрузке системы.
                    0
                    А turnpoint на уровне файловой системы?
                      0
                      А NTFS такое поддерживает? Поделитесь ссылкой, где почитать?
                          0
                          Собственно там же в вики в разделе ограничений:
                          Junction points aren't supported by Windows boot process


                          Но чисто из спортивного интереса попробовал: не работает.
                            0
                            Понятно. А точно никак нельзя присвоить статичный GUID харддиску?
                              0
                              При разбивке MBR — нет, я так понял он «сохраняется» после установки системы в реестре.

                              А при разбивке GPT — томам назначаются статичные GUID, но в данной ситуации это не помогает, не воспринимает бутлоадер такой путь и всё.
                                0
                                Собственно, в лоадере сильно урезанный драйвер, по сравнению с полномасштабным который доступен после загрузки.
                  0
                  А вариант с использование turn-points? Что-то наподобие линков в линуксе.
                  Т.е. в папочке где лежит основной образ создается подпапка, которая линкуется на HDD, и путь в VHD указать в виде относительного пути subfolder\file?
                  • UFO just landed and posted this here
                    +1
                    С учётом того, что в VHD при записи постоянно читаются и обновляются битмапы 2Мб блока, положить VHD на HDD — не очень хорошая идея. Каждая операция чтения будет сначала делать seek на HDD, обнаруживать, что битмап пустой, и только после этого идти на HDD.

                    При записи же будет seek на чтение, чтение с ssd 2Мб блока, потом запись 2Мб на HDD, потом запись обновлённого bitmap.

                    Если данные на HDD, то для чтения данных потребуется две операции чтения — из битмапа и самих данных.

                      +1
                      Я еще прибавлю, что
                      1) Superfetch со временем переместит все часто используемые при загрузке и после загрузки фрагменты бинарников в contiguous регион диска, после чего
                      — разница между HDD-SSD сгладится
                      — SSD будет тупо простаивать

                      2) Вся файловая система и прочее тоже довольно быстро осядет на HDD, и зачем тогда было городить весь огород с SSD вообще?

                      3) Я угробил больше десятка SSD на виртуалках, но это ни разу не было исчерпание ресурса, всегда глюки прошивки. Даже когда на нем сидит 12 виртуалок куда непрерывно что-то пишется, и еще неиспользуемые виртуалки регулярно хибернейтятся (64 гб RAM) — за год выюзалось 16% по SMARTу, думаю, до апгрейда точно хватит
                        0
                        1) Для того чтобы поддерживать систему в актуальном состоянии — делать периодический merge для vhd.

                        2) Опять же периодический merge.

                        3) А вот это уже интереснее… Постараюсь у себя собрать статистику по записям на SSD, благо софт производителя такую информацию выдаёт.
                          0
                          1) 2) ах вот оно что! я думал, там 100500 виртуалок с общего образа, чтобы экономить N*обьем образа на SSD, а если только одна, то это еще более удивительно…

                          3) собирайте. Сколько всего, кстати, виртуалок и какой общий обьем стореджа сейчас?
                      +3
                      ИМХО это закат солнца вручную.

                      Во-первых, ресурсы современных SSD таковы, что обычными десктопными виртуалками его сложно израсходовать. Это должны быть базы данных, которые ежедневно терабайты пишут. И тут уже вопрос стоит в другой плоскости. Возможно в случае БД вы наоборот будете писать на SSD, не потому что ресурса жалко, а потому что перформанс нужен.

                      Во-вторых, формат VHDX поддерживает TRIM, информация о пустующих местах на диске передается из гостевой в хостовую ОС и используется в SSD, что разумеется во многих случаях будет значительно продлевать ресурс.

                      В третьих, большие дядьки для этого используют стороджи, в которых напихано и SSD и HDD, и сам стородж, исходя из заданой политики размещения данных, перераспределяет данные между дисками.
                        0
                        ТС, а зачем? Чтобы обеспечить только быстрое чтение файлов с SSD? так их не так много, лучше на память потратьтесь, а все процедуры записи у вас «выпадут» на долю не быстрого HDD :(

                        А что касается этого неистребимого мифа насчет ресурса SSD: почитайте www.outsidethebox.ms/14402/
                        Там конечно рассчёт странный, но суть в том что вы берете размер диска, множите на рекурс ячеек (зависит от типа памяти) и получаете `гарантированный` обьем который типа покрыт гарантией. это, как правило немаленькие такие числа :) у меня на 256 gb ssd с ресурсом по перезаписи 3000 раз получается 256 Gb* 3000 = 768000 что ~= 768 Tb (!)

                        А сколько вы пишете на свой диск — померяйте сами, софта и профильных тем хватает, начните с того же SSDReady (хоть он и подвирает, причем в вашу пользу, завышая цифры)
                          0
                          И берите с запасом, т.к. +25% неиспользуемого места обеспечат вам непроседающую производительность
                          см www.anandtech.com/show/6489/playing-with-op
                            0
                            Коллега, поправьте меня, если я не прав. Мне кажется, что приводимые расчёты не совсем верны. Берём SSD (у меня сейчас на 128Гб, поэтому для примера возьмём его). Устанавливаем софт, виртуалки и всё-всё-всё на SSD. В итоге мы получаем почти заполненный диск. И заполнен он практически неизменными данными.

                            На сколько я знаю SSD при записи оперирует только свободными на данный момент ячейками (зачем и делается TRIM для освобождения ячеек), т.е. те, что задействованы статической информацией не должны участвовать в расчёте. Т.о. для своей конфигурации (при использовании 100Гб из 128) активными остаются всего навсего 30Гб ячеек. И ресурс диска с 128*3000=384Тб падает до 30*3000=90Тб, т.е. примерно в 4 раза. Думаю вернее рассчитывать средний ресурс SSD по формуле Объём*0.25*ресурс_ячеек. Так получается:

                            64*0,25*3000 = 48Тб
                            128*0,25*3000 = 96Тб
                            256*0,25*3000 = 192Тб

                            Другими словами добиться того ресурса, который заявлен можно только периодической перетасовкой статичных ячеек с активно используемыми. Вот тут я не в курсе, занимаются ли этим контроллеры на современных SSD? Не нашел информации подтверждающей это, может быть плохо искал. Поэтому и рассуждаю про увеличение ресурса SSD с этой точки зрения.
                              0
                              > занимаются ли этим контроллеры на современных SSD?
                              Да, но не все.

                              Плюс, бывает логика «тасовать когда ячейка начинает уже явно подыхать», «тасовать если долго туда ничего не писали» и много других вариантов.

                              > Берём SSD (у меня сейчас на 128Гб, поэтому для примера возьмём его)
                              Я очень сильно подозреваю, что в оценке экономии бюджета упущена экономия времени ;-)

                              Да, если SSD забивать до упора, будет тормозить. Учтите еще, что сама по себе NTFS плохо работает, если свободного места меньше 10-15% (начинают фрагментироваться битмапы, индексы и т.д.)

                              Сколько вам виртуалок надо разместить? Я очень сильно подозреваю, что докупить SSD на 1 Tb будет в итоге дешевле, чем изучать и оптимизировать гибридную конфигурацию.

                              Плюс, эмм, можно же купить Seagate Momentus, который гибрид HDD+SSD, и проверить, помогает ли оно. Кстати, там тоже SSD используется для часто используемых данных, а HDD — для редко используемых. Наводит на мысли =)
                                0
                                Да, перемешиванием заниметься большая часть современных контроллеров. Те которые не занимаються — противопоказаны к покупке, потому что это это сродни еде на автомобиле у которого одно колесо наглухо заклинило, и как только резина протрется — вы ехать не сможете.

                                Почитайте: www.outsidethebox.ms/14484/

                                Есть даже исследования на тему того сколько стоит держать свободного места в запасе: мой коммент прямо над вашим.

                            Only users with full accounts can post comments. Log in, please.