Как стать автором
Обновить

Комментарии 38

Радует развитие btrfs. И то что наконец начали смотреть в сторону производительности подсистемы ввода-вывода.
Угу, совсем недавно включили поддержку DMA по умолчанию и вот сегодня ещё и это.
Сижу на btrfs уже год. Очень доволен.
А в чем плюс для обычного пользователя? Я на ext4, снапшотов не использую.
Может для обычного и нет ;) А я вот использую снапшоты для того чтобы rsnapshot использовал встроенные снапшопты вместо обычного копирования и хардлинков. Получается и чуть быстрее и что важнее, позволяет полноценно подключать требуемый снапшот либо работать с ним напрямую как с папкой.

Обычно юзерам показывают такой кейс: делают снапшот системы перед операцией apt-get update && apt-get -y dist-upgrade и потом при перезагрузке подключают сохраненный снапшот ;) К слову, весьма удобно. Снапшот может быть read-only или read-write.

Из минусов — их необходимо изредка чистить, а то когда-то давно сохраненный файл и потом удаленный в "основной" системе так и будет занимать место.
Ну не буду слагать сказки про радужные тесты производительности. Плюсов я как бы и не вижу, но лично стал использовать btrfs по той причине что у него есть оптимизация для работы с SSD.
Даже учитывая то что сейчас SSD уже не такие убиваемые как ранние от большого количества перезаписей, все же хочется чтобы система была на подходящей файловой системе. Ext4 допустим, меня начал пугать тем что он не имеет никакой оптимизации под SSD.
Да и мне как для обычного пользователя не хочется задумываться над тем что мне после установке нужно что-то там настраивать (как приходилось ранее с Ext4) чтобы система не запорола мне SSD, просто выбрал Btrfs и всё, пользуешься.
По скорости Btrfs уже не чуть не уступает Ext4.
Вообще-то уступает. Удаление почти в 10 раз медленнее. Для файлопомойки это критично — я как-то удалял сериал на 70 гигабайт, так btrfs зависла почти на минуту. Это было последней каплей и я вернул ext4.
3.17 — 4.3

Сейчас на 4.4 для rsnapshot использую btrfs и тоже на удалении старых образов жутко мучает диск.
Понятно. Я просто удалял максимум 10гб файлы. Если бы и заметил тормоз подумал бы что виновато железо, ибо оно далеко не топ.
А можно какой-то пруф, что ext4 убивает ssd?
Да и мне как для обычного пользователя не хочется задумываться над тем что мне после установке нужно что-то там настраивать

Вот и настало время когда подобные фразы стали мелькать в среде линуксоидов :)

Онлайн дефрагментация, прозрачное сжатие. По производительности всё-таки немного быстрее ext4.
А как насчет новых ошибок в этом ядре?
Приключения в Gentoo.

4.0 Система висла на старте, не стал заморачиваться, вернулся на 3.19.3
4.1 — 4.2 — все чудесно работало. Скучно.
4.3 При завершении работы финальный ремаунт начал насмерть вешать систему.
4.4 Внезапно система стала стартовать до того, как добавлялись диски хардварного рейда (mtp2sas) — пришлось добавить sleep 10 в localmount

С нетерпением жду 4.5, чтобы ознакомиться с новыми загадочными квестами и неисправимыми улучшениями.
всё норм, даже проприетарные дровишки от nvidia встали) Linux localhost 4.5.0-gentoo #1 SMP PREEMPT Tue Mar 15 21:40:22 MSK 2016 x86_64 Intel® Core(TM) i5 CPU 750 @ 2.67GHz GenuineIntel GNU/Linux
Ага, вижу что основные в wireless девайсы были перегруппированы. Проблема с рейдом так и не решилась. В остальном все хорошо.
4.4.4+ и 4.5+ — с каждым сном и пробуждением частота ЦПУ падает в 1.25 раза (после десятка слипов можно дойти до 300МГц) — https://bugzilla.kernel.org/show_bug.cgi?id=114551

Можете протестировать, пожалуйста такой эффект у себя?
Результаты тестов
Нагрузка дается так: # perl -e 'fork; fork; fork; fork; $s++ for (1..100000000);'
Данные беру так: # grep. /sys/devices/system/cpu/cpu3/cpufreq/*
До сна, 100% нагрузки.

/sys/devices/system/cpu/cpu3/cpufreq/affected_cpus:3
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_cur_freq:3600000
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_max_freq:5700000
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_min_freq:1200000
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_transition_latency:4294967295
/sys/devices/system/cpu/cpu3/cpufreq/related_cpus:3
/sys/devices/system/cpu/cpu3/cpufreq/scaling_available_governors:performance powersave
/sys/devices/system/cpu/cpu3/cpufreq/scaling_cur_freq:3600000
/sys/devices/system/cpu/cpu3/cpufreq/scaling_driver:intel_pstate
/sys/devices/system/cpu/cpu3/cpufreq/scaling_governor:performance

Некоторое время спустя:
/sys/devices/system/cpu/cpu3/cpufreq/affected_cpus:3
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_cur_freq:1931750
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_max_freq:5700000
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_min_freq:1200000
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_transition_latency:4294967295
/sys/devices/system/cpu/cpu3/cpufreq/related_cpus:3
/sys/devices/system/cpu/cpu3/cpufreq/scaling_available_governors:performance powersave
/sys/devices/system/cpu/cpu3/cpufreq/scaling_cur_freq:1931750
/sys/devices/system/cpu/cpu3/cpufreq/scaling_driver:intel_pstate
/sys/devices/system/cpu/cpu3/cpufreq/scaling_governor:performance

Сделал два pm-suspend подряд:
/sys/devices/system/cpu/cpu3/cpufreq/affected_cpus:3
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_cur_freq:1199875 (!)
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_max_freq:5700000
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_min_freq:1200000 (!!)
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_transition_latency:4294967295
/sys/devices/system/cpu/cpu3/cpufreq/related_cpus:3
/sys/devices/system/cpu/cpu3/cpufreq/scaling_available_governors:performance powersave
/sys/devices/system/cpu/cpu3/cpufreq/scaling_cur_freq:1199875
/sys/devices/system/cpu/cpu3/cpufreq/scaling_driver:intel_pstate
/sys/devices/system/cpu/cpu3/cpufreq/scaling_governor:performance

Под 100% нагрузкой частота вернулась к максимальной:
/sys/devices/system/cpu/cpu3/cpufreq/affected_cpus:3
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_cur_freq:3600000
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_max_freq:5700000
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_min_freq:1200000
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_transition_latency:4294967295
/sys/devices/system/cpu/cpu3/cpufreq/related_cpus:3
/sys/devices/system/cpu/cpu3/cpufreq/scaling_available_governors:performance powersave
/sys/devices/system/cpu/cpu3/cpufreq/scaling_cur_freq:3600000
/sys/devices/system/cpu/cpu3/cpufreq/scaling_driver:intel_pstate
/sys/devices/system/cpu/cpu3/cpufreq/scaling_governor:performance

Спасибо! Похоже, что вас этот баг не коснулся, пока что почему-то воспроизводится только на ноутбуках Lenovo...
У меня комп с процом AMD Phenom II X6 1045T. 2.7ГГц. Ваш тест под нагрузкой показывает честные 2700000. Перезагрузок уже было много (комп не сервер). Спящий и ждущие режимы тоже бывают.

Ядро 4.4.5-040405-generic.

Выяснили, что регрессия в модуле thermal (rmmod thermal && modprobe thermal приводит к падению частоты). Вроде бы авторы патча уже изучают проблему, так что может быть скоро порешится.
Плавно прошёл все эти версии на дебияне на разных серверах и медиацентрах — никаких проблем абсолютно не заметил. У вас что-то с ОС, а не с ядром.
Поддержка устройств это хорошо.
У жены ноут Lenovo, выпущенный 2 года назад, был без операционки, ни один тестируемый дистрибутив не умеет выключать у него питание или перезагружать его, было перепробовано дофига опций ядра для управления питанием, фиг бы там.
Дружно вспоминаем надпись, «Теперь питание компьютера можно отключить», правда кнопку жать приходится 5 секунд.
Вот думаю, может ради эксперимента винду на него накатить и посмотреть как оно будет.
Будет тупо работать. Без перекомпиляций ядра и btrfs.
А что за модель и версия BIOS?
Lenovo B50-30, биос: 9CCN26WW(V2.04).
Обновить можно только из винды, ни с загрузочной флешки, ни с дискеты и внешнего флопика и это с учётом того, что ноут идёт без ОСи.
Я даже из вайна пробовал :0))
Естественно ничего не вышло.
Сейчас забекаплю хомяк, попробую винду XP поставить, посмотрю получится ли, скорее всего нет, дрова на контроллер винта подкидывать не охота, ну и семёрку попробую, один раз как-то ставил уже. Из семёрки попробую обновить биос, хуже в любом случае не будет.
На просторах интернета выгуглилось два совета для вашего ноута: раз и два

У меня в свое время была проблема с Ubuntu 12.04 и ядром 3.13.0-32. При выключении система впадала в ступор при отключении сетевых интерфейсов, в моем случае вылечилось добавлением stop on runlevel [06] в /etc/init/network-manager.conf
По варианту раз, этой опции в биосе нет, поэтому и решил попробовать обновить биос, по варианту два, перепроверял все опции GRUB_CMDLINE_LINUX_DEFAULT связанные с управлением питания. Бесполезно.
Пробовал сегодня XP для прикола воткнуть, синий экран при установке, крашится на acpi.sys.
Сейчас только что семёрка установилась, пока коммент писал, решил попробовать выключить ноут, ноут выключился секунды за 3-4.
Неприятный сюрприз от линухов. Надеялся, может с железом что, но если семёрка выключает, значит отруб питания работает.
Буду биос шить сейчас.
Обновил биос до версии 9ccn33ww (2.11).
Запускаю семёрку, которая работала на старом биосе, вылетает синий экран: Биос в этой системе не полностью совместим с ACPI, свяжитесь с разработчиком и обновите биос.
То есть новый биос работает ещё хуже 0_О
Буду пробовать Кубунту, Минт, может заработает что.
Kubuntu 14.04 LTS, выключение заработало после обновления биоса.
У меня такая же история на ноуте Asus X50N, которому уже лет 8, только проблема не с выключением, а с перезагрузкой.

Какое-то замшелое ядро тогдашних времен успешно его перегружало. А все что новее — просто вешает систему в горячем цикле. Такое ощущение, что ACPI команда проходит, но без эффекта.
Вот да, что-то похожее.
На форумах пишут, что не всегда успевают отмонтироваться разделы и из-за этого происходит висяк.
Владею сабжем (intel). Не мог перезагружаться из linux, я обновил биос и проблема ушла. Пользуюсь mint 17 xfce x86 (3.13 kernel). Проблем нет.
Еще бы проблему с «SRST failed» решили. Вообще было бы хорошо!
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.