• Записи 1572
  • Теги 117
  • Комментарии 3348

Лог жизни

Внеплановый переход на Mint Linux

Сегодня совершенно неожиданно для себя перешел на Mint Linux. Дело было так: смотрел вебинар по машинному обучению, наоткрывал множество вкладок в двух броузерах, и повторилась ситуация, которая случалась полтора года назад: нехватка памяти, зависание, перезагрузка, разрушенная файловая система. С той лишь разницей, что на этот раз рухнул системный раздел, а не с домашним каталогом. Попытки его починить ни к чему не привели. В итоге загрузился с флешки, но на ней у меня был не Lubuntu, а Mint Linux, который я когда-то скачивал, чтобы посмотреть и попробовать.
Я решил, что раз уж так, то его и поставлю. И, надо сказать, первые впечатления весьма положительные. Во-первых, исчезли все проблемы со вторым монитором: и панель задач отображается как надо, ничего не съезжает, и зависаний на загрузке нет, и даже Prime работает корректно. Правда, вот что странно: в броузерном тесте при рендеринге через карточку nVidia результат получается даже чуть хуже, чем через Intelовскую.
Да и на ситуацию отключения/подключения USB-наушников, которые воспринимаются как внешняя звуковая карта, тоже система реагирует нормально, тогда как в Lubuntu нужно было вручную перезапускать pulseaudio. Внешне система тоже красивее, правда, пока не могу привыкнуть к новому меню, в частности, тому, что добираться до приложений на один щелчок мышью дольше.
Единственный минус — это памяти занимает больше: 384 Мб против 240 у Lubuntu. И еще не разобрался, как включить типографскую раскладку. Впрочем, возможно, если выключу IBus, то часть памяти освободится.

4 комментария:

MadTechGuy
0

разрушенная файловая система

На какой ФС это произошло, с какими опциями она была смонтирована? Если это ext4, то это очень странно — практика показывает, что убить ext4 крайне сложно, резкие отключения питания для неё обычно обходятся без фатальных последствий.
4X_Pro
0

Файловая система — ext4, опции монтирования: errors=remount-ro,barrier=0.
Что касается отключения питания, то я регулярно отключал компьютер принудительно (у меня зависаний по памяти бывает штук 15--20 в год, да и из-за глюков с драйвером i915 и экспериментов по их решению тоже зависаний в процессе загрузки хватало), и тоже система выживала. Но вот в этот раз не повезло.
Причина, полагаю, в особенностях работы SSD. В нем стирание для перезаписи данных идет крупными блоками (чуть ли не по 512 Кб), и разрушение происходит в том случае, если в момент выключения оказывается стертым, но еще не перезаписанным блок, в который попадает суперблок и часть таблицы inodes самого верхнего уровня. Так как при выполнении e2fsck ругалась на отсутствующий суперблок, а при попытке указать резервные (8193 или 32678) начинала писать про поврежденные группы inode начиная с самой первой.

MadTechGuy
0

Насколько я понимаю, barrier=1 как раз отвечает за устойчивость к внезапным отключениям питания, но barrier=0 повышает производительность. Может всё-таки не стоит её выставлять в 0?

4X_Pro
0

Пожалуй, ты прав. Впрочем, в новой установке по умолчанию по умолчанию барьеры включены. И еще я не стал выносить /tmp и /var/log в tmpfs пока что.

Написать комментарий
Прикрепить файлы: (не более 4 файлов, не более 102400 Кб каждый, 102400 Кб всего)


Задать вопрос