Правильно ли монтировать /var на HDD вместо SSD чтобы он прослужил больше?
При установке Linux, рациональным ли является указать точку монтирования для раздела /var на HDD (при его наличии), вместо монтирования на SSD с целью не писать логи на SSD и тем самым увеличить срок его жизни? Возможно есть и другие разделы, которые стоит монтировать на HDD?
Мне кажется, вопрос актуален не только для Linux, но и для Винды, и не только по соображениям продления ресурса. Лично я уже давно так делаю - переправляю на D:\ все пользовательские и некоторые системные папки, а на C:\ оставляю по возможности одну только ОС.
Eugene Z, в меню пользовательских папок (Мои документы, Загрузки и т.п.) есть пункт Расположение - вот там ввожу новое (затем следует вопрос "Перенести содержимое?" - отвечаю "Да"). А для многих системных есть специальные настроечные опции - скажем, папку Temp можно перенаправить, изменив системные переменные temp и tmp. Папку Temporary internet Files - через Свойства браузера в Настройках. Ну и т.д.
Разумеется, предварительно создаю эти папки на этом новом месте, хотя, возможно, это необязательно (не проверял).
Нет, все эти советы по поводу "сбережения ресурса SSD" относятся к самым ранним поколениям накопителей. Современные накопители морально устареют гораздо раньше того момента, когда их ресурс на запись будет исчерпан.
Eugene Z, ищите у себя проблему в железе. Потому что даже консьюмерские SSD, через которые прокачивают терабайты в неделю уже второй год прекрасно живут на тестовом стенде.
Eugene Z, у меня два бомжовых SmartBuy:
Revival 1 (128) - четыре года работает.
Revival 2 (128) - три года работает.
И два Samsung:
850 evo (250) - два года.
970 evo plus (500) - в феврале год будет
Никаких проблем. Каждый из них могу рекомендовать к покупке.
John Smith, Разница между обычным и серверным лишь в том что под большой нагрузкой пользовательский быстро даст просадку по скорости. Они не держат нагрузку. А серверный будет держать ровный график вне зависимости от нагрузки.
АртемЪ, небольший объем и контроллеры без алгоритмов автоматической балансировки износа в сумме давали следующее - изнашивалась какая-то небольшая группа ячеек, а выбрасывать приходилось весь накопитель.
небольший объем и контроллеры без алгоритмов автоматической балансировки износа
Это про флешки - там нет контроллера. Соответственно куда сказала ФС, туда и пишем.
А вот в случае SSD - на всех есть контроллер обеспечивающий трансляцию адресов, сборку мусора, и выравнивание износа. Там в любом случае все ячейки имеют одинаковое количество записей - разброс не более 1%.
Практически всегда - это экономия на спичках. Кроме, разумеется, случаев, когда у вас действительно здоровый поток логов - но тогда их обычно и хранят не локально, а централизованно.
Если вас волнует оптимизация и не волнуют логи, то /tmp и /var/log прекрасно монтируются в память (tmpfs). Минус - посмотреть, что было в логах до перезагрузки, не получится. Плюс - затраты резко устремятся к нулю (монтируя /var на HDD, вы таки заметно затормозите обращение к нему на запись).
Eugene Z, я имел в виду, что в логах ПОСЛЕ перезагрузки вы не увидите того, что в них было ДО.
Например, если вам понадобится выяснить причину той самой перезагрузки.
Во первых - непонятно при чем тут срок службы? Он то каким боком?
Во вторых - если решили разнести разделы по разным дискам, то принцип простой - все данные с которыми часто работают - на SSD, с которыми редко на HDD. Поскольку /var это часто изменяемые данные - его без вариантов на SSD.
Срок службы при том, что SSD имеют ограниченное количество циклов записи.
Исходя из первого имеет смысл писать на HDD то, редко читается, в моём случае это и есть логи.
Но судя по другим ответам мои познания в SSD немного устарели.
Срок службы при том, что SSD имеют ограниченное количество циклов записи
Разумеется, все диски имеют ограниченный ресурс, что HDD, что SSD.
Исходя из первого имеет смысл писать на HDD то, редко читается, в моём случае это и есть логи.
Странный вывод - исходя из того, что SSD быстрее чем HDD особенно в мелкоблочных операциях чтения и записи, то писать логи надо на него. Каким боком тут ограниченный ресурс и срок службы? Да, нагрузка повышается, диск быстрее изнашивается, что HDD, что SSD.
НЕТ это уже не актуально
технология трим уже есть на всех дисках, их износ не меньше чем у жестких а порой и того и больше.
Детские болячки ссд уже прошил
Т.е. при покупке нужно обязательно смотреть чтобы была трим технология и можно игнорировать тип (QLC, TLC, MLC? SLC)? А что она делает и начиная с какого года вошла в массовое производство?
Виктор Таран, а каким боком тут технология TRIM?
Вообще уже лет десять невозможно найти диск не поддерживающий TRIM.
Но эта команда практически не влияет на износ диска! Она влияет на скорость.
Простой пользовательский диск без TRIM будет работать медленно, только и всего.
На серверных TRIM используется, но там он не так актуален, и во многих случаях обходятся без него.
Eugene Z, Смотреть нет смысла, она есть на всех дисках.
QLC, TLC, MLC? SLC - тоже особого значения не имеет, если рассматривать в отрыве от задачи.
На сервер конечно желательно не использовать QLC, TLC - ибо диски медленные, и обеспечивают приличные скоростные характеристики исключительно за счет кэша, который под непрерывной нагрузкой моментально забъется.
В домашних условиях - без разницы.
АртемЪ, Вообще то вы не внимательно читали что он делает, так же он следит за количеством использований одной ячейки и перемещяет данные по ним. в результате вы получите 30000 чтений сектора равномерно по всему диску.
То есть да он вйдет из строя когда уже все сектора приблизятся к этой цифре а не первый попавшийся как без TRIM.
То есть эта нехитрая технология позволяет "утрированно дефрагментировать диск, и перемещять из активно использующихся секторов данные на менее используемые" тем самым многократно увеличив ресурс диска, не говоря уже что первые болячки первых ссд давно уже пройдены и он теперь не так восприимчев к чтению запись, мало того сейчас диски могут нарабатывать 40 лет на отказ, что делает практически их вечными ибо за это время вы просто выкинете сервер на свалку
я уже не говорю о таких вещях как
Выводит "подозрительные" сектора за разделы диска ( поскольку он не физически вращающийся на шпинделе" то деградация соседних кластеров не происходит.) Просто диск со временем становится незначительно меньше но тут свои тонкости.
То есть да он вйдет из строя когда уже все сектора приблизятся к этой цифре а не первый попавшийся как без TRIM
Вы что-то все в кучу свалили.
TRIM - команда операционной системы, с помощью которой она сообщает об удаленных файлах.
Если есть TRIM - диск заблаговременно узнает о удаленных файлах, и очистит ячейки которые занимают эти данные.
Если нет TRIM - диск узнает об удаленных файлах только тогда, когда попытается записать в эту ячейку, и поскольку ее заблаговременно не очистили, перед записью ему придется ее очистить. А это долгий процесс.
В результате скорость записи будет очень низкой.
Больше эта команда ни на что не влияет. Без нее данные не удаляются заблаговременно, и приходится тратить время на их очистку тогда, когда пользователю срочно нужно записать данные. Команда TRIM только уведомляет диск об удаленных файлах - она ни в коем случае ничего никуда не перемещает.
При поступлении от файловой системы команды TRIM с информацией об удаленных файлах эта информация передается сборщику мусора. Сборщик мусора работает во время бездействия пользователя и очищает информацию.
По поводу выравнивания записи - просто при записи приоритет имеют блоки с наименьшим количеством циклов записей. Чем меньше циклов, тем больше приоритет. Вот и все выравнивание.
Эти схемы работают без исключения на всех SSD выпущенных за последние 10лет.
О каких "болячках" SSD вы говорите я не понимаю.
мало того сейчас диски могут нарабатывать 40 лет на отказ,
А каким боком к обсуждаемому предмету относится наработка на отказ? Это для датацентров она интересна. А когда у вас один диск - она не имеет смысла.
Надеюсь вы знаете разницу между сроком службы и наработкой на отказ? Диск с максимальным сроком службы 3года, может иметь наработку на отказ 150лет.
Все зависит от нагрузок
Допустим для ТЯЖЕЛОГО сервера БД
Я бы сделал следующее
RAID 1 - OS
RAID 10 - database data
RAID 10 - database logs
Сервер приложений (все в одном)
RAID 1 - OS
RAID 10 - database + logs + data
Сервер приложений (веб морда)
RAID 1 - OS - data
Отдельный вопрос это ssd акселераторы и nvme cache
Посмотрите все это присутствует и позволяет сохранить бюджет в разумных пределах.
В конце концов куча IOPS и случайное чтение нужно не всегда.
В общем составьте план потребления ресурсов, и выбирайте все по этому плану.