Comments 36
Имхо, не имеет смысл устраивать эти танцы с бубном. На практике не встречал еще умерших SSD от исчерпания ресурса перезаписи, у ранних партий встречались глючные, умирающие контроллеры, а так проблем нет.
А у меня на древнем SSD из EeePC 900 скорость доступа к диску просела до десятка IOPS, работать стало почти невозможно. Хотя в новых SSD такие проблемы редко встречаются, насколько я знаю
Интересную информацию по ресурсу современных SSD встретил тут.
Оказывается, современные SSD и 500Tb записи выдерживают без проблем, что серьезно превышает гарантированный производителем ресурс.
Оказывается, современные SSD и 500Tb записи выдерживают без проблем, что серьезно превышает гарантированный производителем ресурс.
о, ценный коммент! огромное спасибо за ссылку.
на самом деле, там написано немножко странные вещи :)
на примере Samsung 840 Pro 256 Gb:
ресурс перезаписи памяти: 3000 раз, объём 256 gb, суммарное количество данных которое можно перезаписать = 750 Tb.
что в почти полтора раза больше чем проверенные ими 500 Tb.
Конечно если говорить о Evo-серии, или в целом о памяти с ресурсом 1000 циклов перезаписи — тогда это серьезные цифры,
хотя все равно надо учитывать объём накопителя, т.к. например при одном и том же ресурсе накопитель вдвое большего объёма прожует (не сдыхая) вдвое больший объём данных. Это такой неочевидный момент после HDD :)
на примере 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Кб примерно, перезаписывается блок целиком (информация из статьи).
Intel's 335 Series 240GB — Intel гарантирует ресурс записи в 20Gb в день в течение трех лет. Это 22Tb.
Полный идеальный ресурс при записи учитывать не совсем верно потому, что запись двух байт информации может привести к записи в два полных Flash блока, а они размером по 8Кб примерно, перезаписывается блок целиком (информация из статьи).
А откуда информация про 1000 на EVO? Я тогда вообще попал, т.к., см. ответ ниже про методику подсчёта, у меня тогда ресурс вообще ориентировочно падает до:
128*0,25*1000 = 32Тб
и вообще не выглядит таким впечатляющим как 750Тб…
128*0,25*1000 = 32Тб
и вообще не выглядит таким впечатляющим как 750Тб…
А как насчёт — сделать огромным по размеру системный раздел HDD, поставить на него ОС + все виртуалки и при этом использовать Intel Rapid Storage для данного раздела?
Я правильно понимаю, что речь идёт об Intel Smart Response в данном случае? Не совсем понятно как эта технология поведёт себя с виртуальными машинами, попробую протестировать.
Да, я имею ввиду именно её.
Хз как с виртуалками, но так — работает прост она ура!
Под так я понимаю быструю загрузку ОС и всех приложений, а также быстрый отклик монстров типа автокада, аркгиса и т.д.
Хз как с виртуалками, но так — работает прост она ура!
Под так я понимаю быструю загрузку ОС и всех приложений, а также быстрый отклик монстров типа автокада, аркгиса и т.д.
Учитывая, что Vista и выше, если считают, что диск HDD — группируют часто используемые фрагменты исполняемых файлов, а W8 и выше еще и дефрагментирует NTFS-структуры на лету с учетом оптимизации seek-ов, то в теории (и в принципе по моим опытам подтверждалось) имеет смысл, действительно, либо использовать ISR, либо размещать на SSD разностные диски, а базовый образ — на HDD (т.е. наоборот по сравнению с подходом, который пытался реализовать автор поста)
Я в итоге просто перешел на Intel'овские SSD и успокоился. По деньгам и времени на обслуживание выходит дешевле, чем городить гибридные системы или менять дешевые и глючные SSD-шки.
Насчет ресурса я написал ниже, дублировать коммент не буду.
Я в итоге просто перешел на Intel'овские SSD и успокоился. По деньгам и времени на обслуживание выходит дешевле, чем городить гибридные системы или менять дешевые и глючные SSD-шки.
Насчет ресурса я написал ниже, дублировать коммент не буду.
А примонтировать диск не как «D:», а как «C:\D\» и использовать относительный путь в vhd?
Но, по-моему, низкий ресурс SSD на запись, это уже urban myth.
Пару лет как полностью перешел на SSD, используются в хвост и гриву — свопы, бакапы, виртуалки без поддержки TRIM — и никаких проблем.
По SSDLife — они еще меня переживут.
Но, по-моему, низкий ресурс SSD на запись, это уже urban myth.
Пару лет как полностью перешел на SSD, используются в хвост и гриву — свопы, бакапы, виртуалки без поддержки TRIM — и никаких проблем.
По SSDLife — они еще меня переживут.
Тоже думал так сделать, проверил, не работает, видимо монтирование происходит позже при загрузке системы.
А turnpoint на уровне файловой системы?
А NTFS такое поддерживает? Поделитесь ссылкой, где почитать?
Собственно там же в вики в разделе ограничений:
Но чисто из спортивного интереса попробовал: не работает.
Junction points aren't supported by Windows boot process
Но чисто из спортивного интереса попробовал: не работает.
А вариант с использование turn-points? Что-то наподобие линков в линуксе.
Т.е. в папочке где лежит основной образ создается подпапка, которая линкуется на HDD, и путь в VHD указать в виде относительного пути subfolder\file?
Т.е. в папочке где лежит основной образ создается подпапка, которая линкуется на HDD, и путь в VHD указать в виде относительного пути subfolder\file?
С учётом того, что в VHD при записи постоянно читаются и обновляются битмапы 2Мб блока, положить VHD на HDD — не очень хорошая идея. Каждая операция чтения будет сначала делать seek на HDD, обнаруживать, что битмап пустой, и только после этого идти на HDD.
При записи же будет seek на чтение, чтение с ssd 2Мб блока, потом запись 2Мб на HDD, потом запись обновлённого bitmap.
Если данные на 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) Superfetch со временем переместит все часто используемые при загрузке и после загрузки фрагменты бинарников в contiguous регион диска, после чего
— разница между HDD-SSD сгладится
— SSD будет тупо простаивать
2) Вся файловая система и прочее тоже довольно быстро осядет на HDD, и зачем тогда было городить весь огород с SSD вообще?
3) Я угробил больше десятка SSD на виртуалках, но это ни разу не было исчерпание ресурса, всегда глюки прошивки. Даже когда на нем сидит 12 виртуалок куда непрерывно что-то пишется, и еще неиспользуемые виртуалки регулярно хибернейтятся (64 гб RAM) — за год выюзалось 16% по SMARTу, думаю, до апгрейда точно хватит
ИМХО это закат солнца вручную.
Во-первых, ресурсы современных SSD таковы, что обычными десктопными виртуалками его сложно израсходовать. Это должны быть базы данных, которые ежедневно терабайты пишут. И тут уже вопрос стоит в другой плоскости. Возможно в случае БД вы наоборот будете писать на SSD, не потому что ресурса жалко, а потому что перформанс нужен.
Во-вторых, формат VHDX поддерживает TRIM, информация о пустующих местах на диске передается из гостевой в хостовую ОС и используется в SSD, что разумеется во многих случаях будет значительно продлевать ресурс.
В третьих, большие дядьки для этого используют стороджи, в которых напихано и SSD и HDD, и сам стородж, исходя из заданой политики размещения данных, перераспределяет данные между дисками.
Во-первых, ресурсы современных 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 (хоть он и подвирает, причем в вашу пользу, завышая цифры)
А что касается этого неистребимого мифа насчет ресурса 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
см 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 при записи оперирует только свободными на данный момент ячейками (зачем и делается 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 — для редко используемых. Наводит на мысли =)
Да, но не все.
Плюс, бывает логика «тасовать когда ячейка начинает уже явно подыхать», «тасовать если долго туда ничего не писали» и много других вариантов.
> Берём SSD (у меня сейчас на 128Гб, поэтому для примера возьмём его)
Я очень сильно подозреваю, что в оценке экономии бюджета упущена экономия времени ;-)
Да, если SSD забивать до упора, будет тормозить. Учтите еще, что сама по себе NTFS плохо работает, если свободного места меньше 10-15% (начинают фрагментироваться битмапы, индексы и т.д.)
Сколько вам виртуалок надо разместить? Я очень сильно подозреваю, что докупить SSD на 1 Tb будет в итоге дешевле, чем изучать и оптимизировать гибридную конфигурацию.
Плюс, эмм, можно же купить Seagate Momentus, который гибрид HDD+SSD, и проверить, помогает ли оно. Кстати, там тоже SSD используется для часто используемых данных, а HDD — для редко используемых. Наводит на мысли =)
Да, перемешиванием заниметься большая часть современных контроллеров. Те которые не занимаються — противопоказаны к покупке, потому что это это сродни еде на автомобиле у которого одно колесо наглухо заклинило, и как только резина протрется — вы ехать не сможете.
Почитайте: www.outsidethebox.ms/14484/
Есть даже исследования на тему того сколько стоит держать свободного места в запасе: мой коммент прямо над вашим.
Почитайте: www.outsidethebox.ms/14484/
Есть даже исследования на тему того сколько стоит держать свободного места в запасе: мой коммент прямо над вашим.
Sign up to leave a comment.
SSD и native boot VHD: а счастье было так близко…