Как стать автором
Обновить

Комментарии 36

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

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

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

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

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

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

128*0,25*1000 = 32Тб

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

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

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

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

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

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

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


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

А при разбивке GPT — томам назначаются статичные GUID, но в данной ситуации это не помогает, не воспринимает бутлоадер такой путь и всё.
Собственно, в лоадере сильно урезанный драйвер, по сравнению с полномасштабным который доступен после загрузки.
А вариант с использование turn-points? Что-то наподобие линков в линуксе.
Т.е. в папочке где лежит основной образ создается подпапка, которая линкуется на HDD, и путь в VHD указать в виде относительного пути subfolder\file?
НЛО прилетело и опубликовало эту надпись здесь
С учётом того, что в VHD при записи постоянно читаются и обновляются битмапы 2Мб блока, положить VHD на HDD — не очень хорошая идея. Каждая операция чтения будет сначала делать seek на HDD, обнаруживать, что битмап пустой, и только после этого идти на HDD.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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