Краткий вопрос о расположении разделов. Я использую SSD для разделов /, / boot, / usr и / home. Я хотел бы переместить / var на механический диск, чтобы минимизировать запись на SSD. Меня больше беспокоит продление срока службы накопителя, а не максимальная производительность (хотя я, очевидно, не хотел бы наносить вред своему серверу).
Мои механические диски состоят из двух дисков с общим LVM, а третий используется для ночного резервного копирования rsync. Еще у меня валяется куча старых 2,5-дюймовых жестких дисков.
Мой вопрос: следует ли мне просто создать новый том LVM '/ var' в моем основном хранилище данных, или стоит ли увеличивать потребление энергии (с точки зрения максимального увеличения срока службы дисков LVMed) для установки малого тома 2,5 дюйма диск использовать только для / var?
На более общем уровне мой вопрос касается компромиссов при размещении монтирования ОС на тех же физических томах, что и мои данные. Спасибо за любую помощь!
1,3 ГБ / день не так много данных. Intel оценивает серию твердотельных накопителей Intel 320 за 20 ГБ / день случайной записи 4 КБ в течение 5 лет (Intel 320 Spec). Случайные записи 4k представляют собой наихудший сценарий для циклов записи / стирания флеш-памяти, и для стандартных рабочих нагрузок вы вряд ли будете выполнять это постоянно, поэтому ваш фактический срок службы будет несколько лучше.
Другие SSD здесь могут отличаться, но в целом я бы не стал беспокоиться о таком уровне записи, если вы используете современный SSD.
Вы также можете проверить отчетный уровень износа своих твердотельных накопителей, чтобы лучше понять, как долго он прослужит. Я отправил Вот о том, как проверить это с твердотельными накопителями Intel. Другие контроллеры будут сообщать о разных атрибутах, но все современные твердотельные накопители тем или иным образом сообщают одни и те же данные.
Многие современные наборы микросхем контроллеров твердотельных накопителей также выполняют сжатие, что еще больше увеличит продолжительность записи, предполагая сжимаемые данные (большинство вещей в / var, таких как файлы журналов, сжимаются достаточно хорошо)
В качестве примера, вот некоторые из результатов запуска smartctl на OCZ Vertex 2 на базе Sandforce:
9 Power_On_Hours_and_Msec 0x0032 100 100 000 Old_age Always - 8298h+23m+00.940s
231 SSD_Life_Left 0x0013 087 087 010 Pre-fail Always - 0
233 SandForce_Internal 0x0000 000 000 000 Old_age Offline - 30272
234 SandForce_Internal 0x0032 000 000 000 Old_age Always - 124672
241 Lifetime_Writes_GiB 0x0032 000 000 000 Old_age Always - 124672
242 Lifetime_Reads_GiB 0x0032 000 000 000 Old_age Always - 3136
Я поставил его в эту машину чуть меньше года назад, что соответствует значению времени работы в часах (345 дней). Этот диск израсходовал 124672 ГБ за 345 дней, или около 361 ГБ в день. Счетчики внутреннего износа твердотельного накопителя составляют 87%, поэтому после почти одного года эксплуатации он изношен примерно на 13%.
Вероятно, это очень сжимаемо (данные RRD, начиная с пустых наборов данных, поэтому много сильно сжимаемых RRD). Насколько я понимаю, атрибут 233 - это объем «фактических» данных, записанных на SSD, а 234/241 - «несжатые». Это будет означать, что на самом деле было выполнено 30272 ГиБ записи, что составляет около 87 ГиБ / день.
(Кстати, обе эти цифры кажутся мне немного завышенными, но мой мониторинг на уровне ОС сообщает о постоянной записи на эти диски 4,5 МБ / с, что довольно близко к 360 ГБ / день, так что в сумме получается нормально. маловероятно, что ядро linux и контроллер диска ошибаются одинаково)
Это будет немного зависеть от вашего SSD и вашей конкретной рабочей нагрузки, но я не вижу особой необходимости переносить / var с вашего SSD.
1,3 ГБ / день подойдет для любого SSD (может быть, кроме очень-очень старых). Вот отчет с ssd-калькулятора жизни: http://www.ssdready.com/measure/?value=1.3&msr=Gb&submit=Estimate%21