[flood]Недостатки SSD дисков
основной минус SSD по сравнению с HDD это, всё же, сильно ограниченное кол-во перезаписей.Кстати, меня тоже интересует, где стоит хранить /var? HDD - медленные, а SSD - не терпят перезаписей.
SSD - не терпят перезаписей.Да блин последние SSD от Intel при непрерывной перезаписи могут жить 5-6 лет. Исправили они эту ситуацию, и для последних моделей уже можно говорить, что проблемы такой нет, для тех кто будет менять железо хотя-бы раз в 5-ть лет.
С рандомной записью тоже шума много, но мало кто говорит, что в сравнении с HDD они их рвут в пух и прах при одинаковых нагрузках. (я имею ввиду последние высокоскоростные SSD).
Нет уже областей где механика способна потягаться с чипами в жестких дисках. Может пока только проблема объема актуальна, и то ближайшие год-два.
Да блин последние SSD от Intel при непрерывной перезаписи могут жить 5-6 летА разве время жизни ячейки меряется годами, а не количеством циклов перезаписи?
В энтерпрайз "флэшках" имеется резерв ячеек взамен выгоревших, так чтобы гарантировать срок службы в 5-6 лет (стандартная гарантия в 3 года + расширенная чтобы самим деньги не терять на замене...
А разве время жизни ячейки меряется годами, а не количеством циклов перезаписи?
Да блин последние SSD от Intel при непрерывной перезаписи могут жить 5-6 лет
Если я буду одну и ту же ячейку постоянно перезаписывать, на максимальной скорости - думаешь, она протянет 5-6 лет?
Модель емкостью 32 Гб способна выдерживать запись до 3,7 Тб в день на протяжении трёх лет (до 4 петабайт а для 64-Гб SSD-диска этот показатель увеличивается в два раза.
при этом скорость последовательной записи до 170 Мб/с, т.е. угробить его можно сильно быстрее, чем за 3 года
Модель емкостью 32 Гб способна выдерживать запись до 3,7 Тб в день на протяжении трёх лет (до 4 петабайта у нас уже появились ФС, заточенные для ssd и минимизрующие циклы перезаписи, равномерно распределяя нагрузку по ячейкам? Для каких ОС такие системы реализованы, и насколько они жизнеспособны?
при этом скорость последовательной записи до 170 Мб/с, т.е. угробить его можно сильно быстрее, чем за 3 годаЕсли быть точным - то в четыре раза быстрее, если предположить, что там идеальный алгоритм для распределения нагрузки (или если просто последовательно забить весь диск нулями, затем забить всё единицами, затем опять нулями - за сутки выйдет 14 с лишним терабайт).
Если я буду одну и ту же ячейку постоянно перезаписывать, на максимальной скорости - думаешь, она протянет 5-6 лет?Где-то слышал мнение, что во флешках и картах памяти контроллер меняет отражение ячеек, чтобы бороться с такой проблемой. Т.е. равномерность количества записей в ячейки он сам регулирует. А то бы флешки с FAT-ом убивались бы быстро.
там рандомайзер стоит, ага
там рандомайзер стоит, агаВо-во. Поэтому в данном случае использование файловых систем, распределяющих записи не имеет смысла.
PS. Тут был вопрос про такие системы. Вообще такие есть, но они используются в "маленьких" системах, где флеш такой особенностью не обладает, но там кроме этого этот флеш доступен в "голом" виде, т.е. там так же видны и используются области этого флеша для управляющих данных. Т.е. эти файловые системы на обычных флешках работать не будут.
Где-то слышал мнение, что во флешках и картах памяти контроллер меняет отражение ячеек, чтобы бороться с такой проблемой. Т.е. равномерность количества записей в ячейки он сам регулирует. А то бы флешки с FAT-ом убивались бы быстро.Во-первых, нет и не может быть идеального алгоритма для решения этой задачи, то есть, таким способом ты не сможешь идеально ровно распределить загрузку, и не получить при этом существенное увеличение этой загрузки на изменение таблицы и перенос данных.
Во-вторых, как мы тут уже выяснили - даже если бы такой алгоритм существовал, и если использовать скорость записи на SSD на все 100% в максимально щадящем режиме - она всё равно даже года не протянет.
Во-первых, нет и не может быть идеального алгоритма для решения этой задачи, то есть, таким способом ты не сможешь идеально ровно распределить загрузку, и не получить при этом существенное увеличение этой загрузки на изменение таблицы и перенос данных.Почему это? Во-первых там наверняка есть служебная информация при каждом "секторе" данных. Во-вторых этот алгоритм в целом не обязан быть идеальным. Как пример могу привести быструю сортировку (Хоара). Она имеет сложность от O(n*log(n в лучшем случае до O(n*n) в худшем. Но на практике все ей пользуются, т.к. O(n*n) почти не встречается. Так и в случае с этим алгоритмом. Вероятность того, что в какой-то ячейке "случайно" окажется много записей может быть ничтожно мала.
Вероятность того, что в какой-то ячейке "случайно" окажется много записей может быть ничтожно мала.А в среднем - думаю, что-нибудь порядка 100% на ней в среднем будет потеряно. Само перемешивание-то тоже расходует ресурсы.
У тебя забит весь диск, кто-то пишет что-то сто раз в сектор номер 1, контроллер решает, что сектор 1 трогали слишком много раз - и меняет его местами с сектором 2, что добавляет и к первому, и ко второму ещё одну перезапись.
до тебя не дошло ещё, что сам по себе этот "сектор номер раз" суть сущность виртуальная и постоянно мигрирующая по реальным адресам на модуле памяти? и что для _каждой_ операции записи в него модифицируется таблица соответствий логических и реальных секторов?
до тебя не дошло ещё, что сам по себе этот "сектор номер раз" суть сущность виртуальнаяПредставляешь, дошло! Более того, я свой пост писал с полным осознанием этого факта и опирался на него.
постоянно мигрирующая по реальным адресам на модуле памяти?Ну-ка, расскажи нам, как она будет постоянно мигрировать, чтобы ячейки памяти не изнашивались из-за этой миграции дополнительно к обычному износу из-за перезаписи снаружи?
и что для _каждой_ операции записи в него модифицируется таблица соответствий логических и реальных секторов?хм, а что тогда делать с уже записанной инфой? копировать на новое место? Предположим мы забьём 95% SSD не изменяющимися данными. А последние 5% будем часто менять. Что нам для этого постоянно будет требоваться перебрасывать по рандому уже записанное?
Но вообще задача имеет неплохое решение. Мы можем делать, скажем, 99 записей с максимальной скоростью в случайную свободную ячейку, и 1 (фактически 3 - 2 записи и чтение) - в случайную же занятую ячейку, с перебрасыванием инфы оттуда в случайную свободную. Потери производительности будут "незаметны" на глаз, бо они в пределах погрешности измерений, зато перемешивание ячеек будет обеспечено. Конкретные числа можно менять в зависимости от фактической заполненности диска.
таки на уровне ФС было бы веселее. Например можно было бы учитывать флаг immutable при планирование распределения ячеек.
на уровне ФС нифига не веселее, потому как размер ячейки винта "несколько" меньше размера кластера ФС.
больше?
8-64кб
на уровне ФС нифига не веселее, потому как размер ячейки винта "несколько" меньше размера кластера ФС.сделать маленькие кластеры не сложно. Вон современные методы адресации позволяют гигабайты оперативки заводить с минимальным адресуемым отрезком в 1 байт
да, могут быть и больше. у "интеловского" размер страницы - 4 кб
А в среднем - думаю, что-нибудь порядка 100% на ней в среднем будет потеряно. Само перемешивание-то тоже расходует ресурсы.Не понял что ты имел в виду о том что и где будет теряться. Ну не важно.
Даже еслии будут накладные расходы в этом алгоритме и даже если он будет не идеальный — такая флешка проживёт намного дольше той, которую будут записывать постоянно в одно и то же место без перемешивания. А т.к. вероятность такой записи с FAT очень велика, да и с многими другими ФС, то от применения такого алгоритма имеем прямую пользу.
Даже еслии будут накладные расходы в этом алгоритме и даже если он будет не идеальный — такая флешка проживёт намного дольше той, которую будут записывать постоянно в одно и то же место без перемешивания. А т.к. вероятность такой записи с FAT очень велика, да и с многими другими ФС, то от применения такого алгоритма имеем прямую пользу.Да - если мы будем пытаться убить эту флэшку, то с таким алгоритмом она проживёт не один день, а полгода. А если не будем пытаться убить, а просто будем лить на неё данные с максимальной скоростью в максимально щадящем режиме - то протянет почти год.
И? Никакие пять лет она там, где её скорость использоуется по полной всё время, она не протянет.
И? Никакие пять лет она там, где её скорость использоуется по полной всё время, она не протянет.Ну там же написано в каком режиме она 5 лет протянет.
Если её умышленно писать до бесконечности с целью убить, то наверняка умрёт быстрее.
Но проще молотком по ней ёбнуть — так ещё быстрее и надёжнее.
Если её умышленно писать до бесконечности с целью убить, то наверняка умрёт быстрее.Если полностью забивать её пропускную способность (а что, вполне реальная ситуация в серверных приложениях то она не протянет дольше года вне зависимости от того, как именно ты туда пишешь.
В отдельных ситуациях (если не повезло с тем, как именно расположены данные) - время жизни может быть гораздо меньше (полгода, или три месяца но оно никогда не будет больше года.
(а что, вполне реальная ситуация в серверных приложениях)тут все еще про SSD разговор?
Разговор был о применении SSD в ынтырпрайз-системах.
пора уже сделать приписку [penartur inside] к заголовку треда!
Во-вторых - "непрерывная перезапись на протяжении 5-6 лет" - она и есть непрерывная перезапись на протяжении 5-6 лет (и обычно встречается как раз в тех самых "энтерпрайз"). Тебе помочь найти первое упоминание этих самых 3-5 лет? Или сравнить расположение в этом треде этого упоминания и первого моего поста?
иди нахуй
Ну и не пиши тогда тут хуйню.
Если полностью забивать её пропускную способность (а что, вполне реальная ситуация в серверных приложениях то она не протянет дольше года вне зависимости от того, как именно ты туда пишешь.что-то мне подсказывает что писать в серверных приложениях в среднем будешь в несколько раз меньше чем читать, а пропускная способность она одна всех.
есть правильные флеш диски - внутри везде ECC, умный контроллер который размазывает запись по разным ячейкам, сами микрухи SLC, ну и плюс ко всему внутри кэш в виде ддр2 и конденсатор-батарейка которой хватает на сброс содержимого кэша на флеш если питание пропадет ну и плюс к этому правильный интерфейс типа файбер ченел. результат - иопсов не 160 а 20000
имо, если использовать SSD для старта системы и загрузки приложений, а для временных файлов (которые только создаются и редко удаляются, потому и SSD не сожгут) и свопа - HD, никто из них не обидится и мы не потеряем почти производительности и сохраним драгоценный SSD.
есть правильные флеш диски - внутри везде ECC, умный контроллер который размазывает запись по разным ячейкам, сами микрухи SLC, ну и плюс ко всему внутри кэш в виде ддр2 и конденсатор-батарейка которой хватает на сброс содержимого кэша на флеш если питание пропадетЕсли я правильно понял, о чём ты, то это не флэш-диск, а RAM-диск с возможностью бэкапить данные на флэш.
Если я правильно понял, о чём ты, то это не флэш-диск, а RAM-диск с возможностью бэкапить данные на флэш.функции свои выполняет и заебись.
Да, только к обсуждаемой теме это отношения не имеет.
в чём принципиальное отличие от ssd?
SSD и "оперативная память, опционально - энергонезависимая за счёт бэкапа на SSD" - совершенно разные вещи.
wiki: Твердотельный накопитель (англ. SSD, Solid State Drive, Solid State Disk) — энергонезависимое, перезаписываемое компьютерное запоминающее устройство без движущихся частей. Следует различать твердотельный накопители основанные на использовании энергозависимой (RAM SSD) и энергонезависимой (NAND или Flash SSD) памяти.
Это средний вариант. Скорость и кол-во перезаписей от первого - энергонезависимость от второго.
чувак, если там флеша 146гб и 512мб ддрама - это что рам диск чтоли? да писец - тогда любой механический диск тоже рам - у них там уже по 32мб кэша
Как я уже заметил в энтерпрайз "флэшках" имеется резерв ячеек взамен выгоревших и ничто не мешает в таких случаях использовать их...
Оставить комментарий
AlexV769
а) не фактб) аргумент где-то с третьей страницы
основной минус SSD по сравнению с HDD это, всё же, сильно ограниченное кол-во перезаписей. OLTP БД на SSD хрен похранишь.