При SSD оно разве надо? Может noop? Я в цифрах разницу не видел, на глаз не замечал.
вообще надо бы проверить, бест практис - как я написал, но с SSD многие парадигмы сдвигаются
LinuxForum.Fans
kvm and SSD
Автор: semperN
30 сообщений
7851 просмотров
Имею отвратительный опыт с выставлением noop для системного SSD: при ощутимых объёмах записи/чтения вся система просто повисала до конца i/o. CFQ и deadline как-то сглаживают массивный i/o, система не виснет, хотя и подёргивается.
И когда уже Линукс научится разносить i/o и всё остальное так, чтобы они друг на друга не влияли? Неужели это так сложно?
Имею отвратительный опыт с выставлением noop для системного SSD: при ощутимых объёмах записи/чтения вся система просто повисала до конца i/o. CFQ и deadline как-то сглаживают массивный i/o, система не виснет, хотя и подёргивается.
И когда уже Линукс научится разносить i/o и всё остальное так, чтобы они друг на друга не влияли? Неужели это так сложно?
Чувствую себя полным дилетантом :) никогда не пробовал играться такими параметрами, и даже не знаю что они означают.
Может просто прокинуть ssd в виртуальную машину windows server 2008r2 и пускай она нативно с ней работает? как такой вариант? Ведь kvm такой умеет?
ещё поменяйте noatime,nodiratime на relatimedefaults,noatime,nodiratime,discard, создаю там RAW диск куда скидываю базу 1С и этого достаточно?
да, defaults не нужно.
++А вторая - от RedHat'а. Не следует SSD ставить в RAID. Аргументация такая - SSD для обеспечения высокой производительности надо иметь, минимум, 25% свободного объема. А RAID своими служебными данными очень много блоков и производительность диска - деградирует.
raid не для надежности?
нет. Ну не в том смысле "для надёжности", как вы понимаете "надёжность".
TRIM вообще отсутствует в OS. Это команда SATA. По идее, гостья должна послать TRIM в виртуальный SATA, а этот виртуальный SATA должегн его транслировать в реальный. На практике, я больше чем уверен, что такого не будет. Да и файл там один в хосте, потому смысла в TRIM нет никакого.TRIM нужен и там и там. Вот только я очень сомневаюсь, что TRIM в госте чем-то поможет.
вот тут не соглашусь. зачем двум разным ОС бороться за TRIM на одном и том же месте? это как с шедулером - в госте всегда ставится noop чтоб cfq или deadline на хосте могли нормально работать
Да, TRIM это команда сигнализирующая об УДАЛЕНИИ файла. Какие файлы вы удалять собрались?
кто вам мешает дублировать, если вы не осилили более удобные способы повышения надёжности? (лигбез здесь: http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%B4_%D0%A0%D0%B8%D0%B4%D0%B0_%E2%80%94_%D0%A1%D0%BE%D0%BB%D0%BE%D0%BC%D0%BE%D0%BD%D0%B0 )да, в F16 стоит SSD смешного размера за 50 килобаксов, думаю в нем вся память как минимум продублирована - за такие-то деньги. Сейчас фотоаппараты подороже и те рассчитаны на две или больше SD и пишет фотоаппарат сразу во все, на всякий случай, для надежности.
нет. Ну не в том смысле "для надёжности", как вы понимаете "надёжность".
ударяемся в семантику?
TRIM вообще отсутствует в OS. Это команда SATA. По идее, гостья должна послать TRIM в виртуальный SATA, а этот виртуальный SATA должегн его транслировать в реальный. На практике, я больше чем уверен, что такого не будет. Да и файл там один в хосте, потому смысла в TRIM нет никакого.
давно во все это вчитывался, и да, это команда которую должна слать ВМ, и она должна быть на всех уровнях. Только файлы тут имеют отношение только на уровне ФС, а дальше это транслируется в набор блоков которые можно сбросить, так что на хосте лучше использовать LVM или отдать весь диск целиком в KVM.
Если использовать LVM то
lvm.conf:
text
...
devices {
...
issue_discards = 1
...
}
кто вам мешает дублировать, если вы не осилили более удобные способы повышения надёжности?
Вариации на тему ECC? Вы серьезно считаете что на это можно полностью полагаться?
нет. Просто ИМХО вы слишком однобоко понимаете слово "надёжность".ударяемся в семантику?
вот именно с уровня ФС на уровень девайса и передаётся команда TRIM. Которая и говорит девайсу, что "блок пуст". AFAIK, TRIM даже прямо на железе НЕ умеет стирать поблочно, а не пофайлово. Т.е. даже если и есть везде поддержка TRIM, то она сквозь виртуалку работать НЕ будет. Ибо файл один.Только файлы тут имеют отношение только на уровне ФС, а дальше это транслируется в набор блоков которые можно сбросить
Если использовать LVM то
...всё усложняется. Но качественно всё тоже самое.
при чём тут ECC? Это ECC является "вариацией", причём такой, на которую мы НЕ можем влиять. Если в девайсе есть ECC, то оно есть(наверное). Всё.Вариации на тему ECC? Вы серьезно считаете что на это можно полностью полагаться?
На самом деле, код Рида-Соломона можно применять на любом уровне, не только на железном.
Что касается "доверия", то вы "доверяете" формуле 2*2==4 ? Вот код Рида-Соломона -- та же формула, только чуть длиннее. В ней нет никакой магии.
Если на пальцах, то дублирование -- очень неэкономичный подход. Предположим, что вероятность ошибки 1%. Если мы применим дублирование, это НЕ снизит вероятность ошибки, а наоборот, ПОВЫСИТ. Возможно 4 случая:
1. ошибок не было
2,3 была ошибка в одном из дублей. Вероятность этого 2%. Мы эту ошибку найдём, но исправить НЕ сможем(т.к. не знаем, в каком именно дубле была ошибка)
4. С вероятность 0.01% возможна ошибка в обоих дублях, в одном месте. Такую ошибку мы не просто не исправим, но даже не заметим.
++[/quote][quote="Cruiser78"]производительность диска - деградирует.
Плюсы плюсами, а вот уровень доступности данных - страдает.
А именно, мой опыт говорит, что традиционные HDD далеко не сразу отказывают. Не становятся колом, а долго и упорно накапливают бэды. Если за этим процессом следить, получать каждый день на почту репорты от smartctl, то негативную тенденцию можно выявить очень заблаговременно. И когда количество бэдов подберется к критической отметке, то изъять диск из сервера (а там RAID-1, серверу пофих на это дело, он продолжит работать с оставшимся диском), потихоньку его обменять по гарантиии (или купить новый), ну а затем - вставить новый диск в систему. Процедура опробована не один раз, работает безотказно.
А вот с SSD такой финт, как говорит гугль, не пройдет. Не копятся на нём бэды. И если SSD отказывает, то отказывает внезапно и тотально. Бэкапы-бэкапами, но получить такую плюшку в конце рабочего дня - приятного мало.
Так что если нужно хранение данных с высокой степенью доступности, то зеркалирование дисков - наше всё. Пусть даже оно несколько помедленнее работать будет, чем одиночный диск... Всё равно зеркало на SSD будет много быстрее HDD.
Такое мое имхо.
Это проблема новых не обкатанных технологий. Контроллеры только-только появились, и их ещё не довели до ума. Микропрограммы полны глупых ошибок, ибо пишутся СРОЧНО.А вот с SSD такой финт, как говорит гугль, не пройдет. Не копятся на нём бэды. И если SSD отказывает, то отказывает внезапно и тотально.
NAND появилась очень давно, но вот дешёвые и быстрые контроллеры к ней -- совсем недавно. Вот и сыплются. Ничего не поделать.
Так что если нужно хранение данных с высокой степенью доступности, то зеркалирование дисков - наше всё. Пусть даже оно несколько помедленнее работать будет, чем одиночный диск... Всё равно зеркало на SSD будет много быстрее HDD.
вы точно не путаете надёжность/доступность/скорость? Не? Это ТРИ РАЗНЫХ сущности.
да и вот, кто-то писал жеж...
А вторая - от RedHat'а. Не следует SSD ставить в RAID. Аргументация такая - SSD для обеспечения высокой производительности надо иметь, минимум, 25% свободного объема. А RAID съедает своими служебными данными очень много блоков и производительность диска - деградирует. Источник: https://access.redhat.com/site/document … uning.html
+ semperN
Войдите или зарегистрируйтесь, чтобы ответить.
