LinuxMint.com.ru

slant писал(а): ↑

23 окт 2018, 19:48

Компрессию btrfs я бы так просто не прописывал для всего.

Нужно всё дефрагментировать, запрессовать и отдать прошивке. Она сама по полочкам разложит. Место на ССД ещё дороговато. При скоростях ССД снижения производительности в реале не заметно. А писькомерялки интересны только для общей картины. +-10 или 20 Мб - это как сейчас дурачки, или кому делать нечего, рассуждают про +-200Мб ОЗУ для ДЕ.
Пользуйтесь и всё.

Если кому интересно опции монтирования btrfs

Unborn писал(а): ↑

23 окт 2018, 21:02

При скоростях ССД снижения производительности в реале не заметно.

А ничего, что при включенной компрессии для btrfs минимально возможный блок прочитанных данных - 128кб? Т.е. чтобы прочитать 1 байт, нужно читать и распаковывать весь этот блок. А если на диске куча мелких файлов - вы этот оверхед представляете? Для записи ограничения тоже есть - минимум 4кб. Т.е. перезапись одного байта потребует от 2 до 8 блоков ssd разом, в зависимости от модели. Тоже не фонтан, если нужно кучу мелочи писать.

Лично мерял скорость "холодного" запуска броузера со сжатым и разжатым профилями. С выполенной дефрагментацией на нем. Профиль здоровый, 300 с хвостом метров - расширения, история кеш, и т.д. Так вот - до 30% разницы не в пользу сжатого.

Сжатие полезно, но применять с умом надо, а не тупо на весь диск вешать.

slant писал(а): ↑

23 окт 2018, 22:30

Лично мерял скорость "холодного" запуска броузера со сжатым и разжатым профилями. С выполенной дефрагментацией на нем. Профиль здоровый, 300 с хвостом метров - расширения, история кеш, и т.д. Так вот - до 30% разницы не в пользу сжатого.

Аж 30% намерял - это ~2 сек от силы, один раз при запуске. Пипец проблема.
Потери недешевого дискового пространства, при какой-то там потере производительности, которой никто толком то и не замечал никогда, одни разговоры.
На дестопной хомячковой машине заметно уменьшение объёма, а не производительности.
Вешайте на весь раздел компрессию и не парьте людям мозги, уменьшение занятого места заметно реально, снижение производительности - нет.
Я реального падения производительности диска с компрессией и без не заметил. А вот уменьшение занятого места - да.

Unborn писал(а): ↑

23 окт 2018, 23:44

Вешайте на весь раздел компрессию и не парьте людям мозги, уменьшение занятого места заметно реально, снижение производительности - нет.

"Есть два мнения, одно неправильное, другое мое." (с)Армейский юмор.
Если вы не видите разницы - ради бога, вешайте себе компрессию на весь диск. Только не говорите, что вот прямо всем надо это делать в обязательном порядке. Я предпочитаю рассказать что к чему, и пусть человек сам решает что ему нужно - осознанно. А от меня - максимум совет. Но не бескомпромиссное указание - делать только так.
Кстати, вы в курсе, что компрессия еще и снапшоты ломает? Точнее дедупликацию в них. Это к вопросу о экономии места.

slant писал(а): ↑

24 окт 2018, 00:01

Кстати, вы в курсе, что компрессия еще и снапшоты ломает? Точнее дедупликацию в них. Это к вопросу о экономии места.

Что там у тебя ломает я х.з. У меня нормально восстанавливает. И сделал снапшот 98,3 Кб. Что и делает обычный юзер с помощью дефолтной Timeshift сейчас. Где что не эконимится? Может надцать лет назад что-то там не работало?
Улыбнуло - https://forum.ubuntu.ru/index.php?topic=301531.0

Вы понаблюдайте за занятым местом потом, после того как изменятся данные. В случае включенной компрессии, механизм COW в подобном случае (наличие снапшота) перезаписывает не только изменившиеся блоки, а изменившиеся файлы. Т.е. там где без компрессии разница со снапшотом была бы всего один блок (остальные останутся общими), с включенной комрессией будут перезаписаны (т.е. станут раздельными) все блоки относящиеся к файлу.

Кстати, вот еще одна тонкость: если вы включаете компрессию на весь диск в fstab, вы теряете возможность назначить разные алгоритмы для разных каталогов. А подтома с разными алгоритмами монтировать через опции fstab тоже нельзя (будет использован первый указанный алгоритм и для последующих подтомов).
Но вот если выставлять компрессию индивидуально через атрибуты - это возможно. Так что, даже если вы хотите сжать весь диск, лучше все-таки сделать это через установку атрибута и метода на / во время установки (либо сжать после установки и пройтись дефрагом), а не в fstab. Так можно будет назначать каталогам lzo или zlib по мере надобности - где нужно лучше сжимать, а где быстрее работать. Ну или даже вообще отдельный каталог вывести из компрессии и отключить на нем cow, если там будут образы виртуалок или база данных.

slant писал(а): ↑

24 окт 2018, 19:23

Так что, даже если вы хотите сжать весь диск, лучше все-таки сделать это через установку атрибута и метода на / во время установки (либо сжать после установки и пройтись дефрагом), а не в fstab.

Так и делается. Простой юзеровский вариант без заморочек, чисто для системы. Данные на xfs. Установка. У меня не один дистр - с другого - балансировка, дефрагментация, упаковка, добавление параметров в fstab.
ROSA я так с полгода периодически мучал. Софта как у дурака фантиков напихал, но за 10Гб не вышла.
Но, имхо, лучше всех из коробки реализовано в опенсусе всё-таки. А в Шляпе boot отдельно с ext4

Возвращаясь к началу темы: "Какой фирмы SSD вы выбрали и почему, что повлияло на ваше решение?"
Единственной причиной перехода на SSD для меня было повышение быстродействия компьютера.
Первый SSD выбрал для ноутбука Asus примерно 4 года назад: Kingston, кажется 240 Гб. Тогда вообще ничего не понимал в них, немного почитал в Гугле и выбрал его. Результат очень впечатлил, имею ввиду скорость. Второй SSD поставил на ноутбук жены: Samsung 860, 256 Гб. Этот выбор был более осознанный после чтения в Интернете. После моего первого опыта с SSD её ноутбук (тогда ещё с Windows) уже выводил меня из себя. Удивлялся терпению жены. После замены получил благодарность от довольного "командования".
Третий SSD, Samsung 960 Pro 256 Гб, поставил пару месяцев назад на новый гарантийный настольный ПК Asus.
У каждого есть свои соображения целесообразности (или её отсутствия) перехода с HDD на SSD. Для меня главное - заметное повышение быстродействия. Какие-то технические несовершенства твердотелов или их непропорционально высокая цена для меня глубоко вторичны.

Оптимизацию всех SSD делал по принципу "не перегибать палку", то есть лишь самое необходимое. Мне понравился этот источник: https://sites.google.com/site/easylinuxtipsproject/ssd

Лень читать чужие варианты, поэтому могу повториться:
Брал ssd специально под систему, а системные файлы как известно любят бэкап, а бэкап "искаропки" у нас предоставляет btrfs с помощью своих снапшотов(снимков),
снапшоты эти разделяются подтомами и даже если внутри одного подтома будет другой, при создании снапшота они друг друга не затронут
Это я веду к необходимости правильного разделения подтомов, так вот, самые прошаренные в этом деле люди сейчас в opensuse, так что посмотрим что они сделали в opensuse leap 15 -
они выделили в отдельные подтома:
/opt
/srv
/tmp
/usr/local
/root
/var с отключенным CoW, т.к. он будет мешать базам данных, виртуалкам, логам и прочим постоянно меняющимся файлам
Отключить CoW
chattr +C /var - для отключения CoW у новых файлов/директорий
как отключить для всех файлов - читать вики по ссылке выше

теперь немного про mount
для btrfs рекомендуют параметры noatime, ssd и не рекомендуют discard

Fobos писал(а): ↑

06 фев 2019, 21:14

и не рекомендуют discard

Это не рекомендуют разработчики систем шифрования. Их недоделка. А так discard - это нормальный штатный параметр монтирования для ФС, поддерживающих TRIM.
А вот запускать fstrim вручную или по расписанию, - это нужно понимать, что это такое, что делается. Это админское решение проводить ТО в какой-то выбранный день, час. А не то, что кто-то где-то там рекомендует или не рекомендует.

Unborn писал(а): ↑

07 фев 2019, 10:03

Это админское решение проводить ТО в какой-то выбранный день, час. А не то, что кто-то где-то там рекомендует или не рекомендует.

Мой косяк, согласен, надо было рассказать про trim, про то как его проверить, про то почему рекомендуют делать очистку вручную при шифровании, про то что при параметре discard когда-то умирали ssd на контроллере SandForce и как говорят(не утверждаю) они все еще работают медленнее с этой опцией, и еще

In Linux Mint 19 automatic TRIM is enabled by default, when you install Linux Mint 19 on an SSD. Namely by a weekly "cron job".

Также хотелось бы уточнить что параметр noatime, который я указал выше для btrfs, несет в себе не только пользу, но и вред, тем кто не хочет вникать в вопрос - его лучше не включать.