немного программист, немного админ
Что можно сказать про оповещения о проблемах в графане? Ну разве что то, что они есть. Не могу сказать, что они мне действительно нравились, но они были недостаточно плохими для того, чтобы заняться их кастомизацией.
Но после обновления графаны до девятой версии всё изменилось. Я обнаружил, что сообщения превратились в малочитаемые простыни (на КПДВ слева).
Решил сократить сообщения и повысить их читаемость, что у меня получилось можете увидеть на той же картинке справа.
Эта мини-статья родилась как ответ на статью Упрощаем эмуляцию X86 с помощью Live CD, в которой для запуска старых 32-битных приложений на 64-битных дистрибутивах Linux предлагалось использовать QEMU + Live CD — по моему мнению «из пушки по воробьям». Опишу своё решение на chroot + debootstrap.
На Хабре в последнее время появилась серия холиварных статей:
Семь причин, почему Линукс
Главная причина, почему не Linux (от автора предыдущей статьи)
Главная причина, почему все-таки Linux
В этих статьях и комментариях к ним много говорили о коммунизме, цельности системы, свободе, юзабилити, домохозяйках, глюках… Да о чём угодно, но самое главное для меня если и упоминалось, то только вскользь.
Так что я решил написать свою статью, она будет совсем небольшой не очень большой, не пугайтесь.
Несомненно, вопрос, вынесенный в заголовок статьи, не нов, поднимался не раз и по нему достигнут консенсус «не особо нужна, и даже может быть вредна».
Однако недавнее обсуждение в комментариях заставило меня ещё раз задуматься.
Со временем любой SSD всё равно сильно фрагментируется (внутри, в FTL)… Свежезаписанный SSD при линейном чтении даст высокую скорость, а уже поработавший — гораздо ниже, потому что линейными оно будет только для вас.
Да, обычно такое не должно происходить: или мы пишем «понемногу» в мелкие файлы/небольшие блоки метаинформации ФС (скорость линейного чтения которых нас не особо волнует), либо же мы пишем «помногу» в большие файлы и всё будет хорошо. Бывает и дозапись мелкими блоками в большие файлы — логи, например, однако они относительно короткоживущие и особой проблемы я тут не вижу.
Но легко представился вполне реальный сценарий, при котором всё-таки внутренняя фрагментация SSD может проявиться: файл базы данных, в который идёт достаточно активная случайная запись. Со временем он (оставаясь нефрагментированным на уровне операционной системы) окажется физически очень даже фрагментированным, что может существенно снизить скорость seq scan, резервного копирования и т.п.
Для проверки я написал скрипт и провёл тесты.
Спойлер: проблема присутствует (существенно влияет на производительность) только на одной из попавшихся под руки моделей (и та позиционируется производителем не как datacenter, а как десктопная/ноутбучная).
Есть торговые автоматы собственной разработки. Внутри Raspberry Pi и немного обвязки на отдельной плате. Подключены монетоприёмник, купюроприёмник, банковский терминал… Управляет всем самописная программа. Вся история работы пишется в журнал на флешке (MicroSD), который потом передаётся через интернет (с помощью USB-модема) на сервер, там складывается в БД. Информация о продажах загружается в 1с, также есть простенький веб-интерфейс для мониторинга и т.п.
То есть журнал жизненно необходим — для учёта (там выручка, продажи и т.д.), мониторинга (всевозможные сбои и другие форс-мажорные обстоятельства); это, можно сказать, вся информация, которая у нас об этом автомате.
Флешки показывают себя как очень ненадёжные устройства. Они с завидной регулярностью выходят из строя. Это приводит как к простоям автоматов, так и (если по каким-то причинам журнал не мог быть передан онлайн) к потерям данных.
Это уже не первый опыт использования флешек, до этого был другой проект с более, чем сотней устройств, где журнал хранился на USB-флешках, там тоже были проблемы с надёжностью, временами число вышедших из строя за месяц исчислялось десятками. Пробовали разные флешки, в том числе и брендовые на SLC памяти, да некоторые модели надёжнее других, но замена флешек не решила проблему кардинально.