Назад | Перейти на главную страницу

Стоит ли переносить / var на физический диск против логического?

Краткий вопрос о расположении разделов. Я использую 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