Стоит ли переносить /var на физический диск против логического?
Краткий вопрос о разметке разделов. Я использую SSD для разделов /, /boot, /usr и & home. Я бы хотел переместить / var на механический диск, чтобы минимизировать количество записей на SSD. Я в основном озабочен увеличением срока службы диска, а не увеличением производительности (хотя, очевидно, я бы не хотел наносить вред моему серверу).
Мои механические диски состоят из двух дисков, совместно использующих LVM, и третьего, используемого для ночных резервных копий rsync. У меня также есть куча старых 2,5-дюймовых жестких дисков.
Мой вопрос заключается в том, должен ли я просто создать новый том LVM '/var' в моем основном хранилище данных, или стоило бы увеличить энергопотребление (с точки зрения максимального увеличения срока службы накопителей LVMed) для установки небольшого тома 2,5 дюйма. диск использовать только для /var?
На более общем уровне мой вопрос касается компромиссов при размещении монтирования ОС на тех же физических томах, что и мои данные. Спасибо за любую помощь!
2 ответа
1,3 ГБ / день не много данных. Корпорация Intel оценивает твердотельные накопители серии Intel 320 на 20 ГБ в день при случайной записи 4 КБ в течение 5 лет ( спецификация Intel 320). Произвольная запись 4k представляет собой наихудший сценарий для циклов флэш-записи / стирания, и для стандартных рабочих нагрузок вы вряд ли будете добиваться этого постоянно, поэтому фактический срок службы будет несколько лучше.
Другие SSD здесь могут отличаться, но в целом я бы не стал беспокоиться о таком уровне записи, предполагая, что вы используете современный SSD.
Вы также можете проверить уровень износа ваших твердотельных накопителей, чтобы лучше понять, как долго он продлится. Я написал здесь о том, как проверить это с Intel SSD. Другие контроллеры будут сообщать разные атрибуты, но все современные твердотельные накопители так или иначе сообщают одни и те же данные.
Многие современные наборы микросхем контроллеров твердотельных накопителей также выполняют сжатие, что еще больше увеличивает долговечность записи, предполагая, что сжимаемые данные (большинство вещей в /var, таких как log-файлы, сжимаются достаточно хорошо)
В качестве примера, вот некоторые результаты работы 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 и вашей конкретной рабочей нагрузки, но я не вижу особой необходимости перемещать / отключать ваш SSD.
1,3 ГБ / день подойдет для любого ssd (может быть, за исключением некоторых очень, очень старых). Вот отчет из калькулятора жизни ssd: http://www.ssdready.com/measure/?value=1.3&msr=Gb&submit=Estimate%21