Привет! Поскольку Майкрософт и Сергей Гуриев заблокировали мне Xbox, я решил играть в btrfs холодными декабрьскими вечерами.

Мне очень нравится скорость на десктопной нагрузке, компрессия и relink. И я буду признателен за мнения и отклик по нескольким открытым для меня вопросам:

1. Организация swap

Btrfs не поддерживает файл подкачки на нескольких дисках, но нафиг она нужна на одном диске — не понятно. Когда в Fedora перешли на btrfs, а затем подумали, они не нашли решения и отказались от физического swap в пользу zram.

Как пользователи btrfs организуют swap?

Для наилучшей производительности у себя c несколькими дисками я не могу придумать варианта лучше, чем отдельные разделы на каждом из дисков, подключаемые в swap с одинаковым приоритетом.

2. Шифрование

В начале года были новости о поддержке fscrypt в btrfs: Йосеф Бачик даже что-то коммитил. А дальше backlog и туман.

Слышно ли ещё что-нибудь? Есть ли инсайды и прогнозы?

3. Per subvolume raid profile

Почему до сих пор нельзя использовать разные профили raid для разных subvolume?

Каждый subvolume — отдельное b-tree, казалось бы, ничего не мешает. В устаревшем FAQ из 2015 разработчики писали, что им так сложно считать df, но они вот-вот научатся.

Вот в LVM я могу в одной VG собирать тома каких угодно профилей: raid1 для нужного, raid0 для быстрого на одних и тех же PV.

Привет! Я попробовал btrfs и сильно удивился её производительности в некоторых случаях на реальном SSD:

$ uname -rp
6.5.0-35-generic x86_64

$ sudo mkfs.btrfs /dev/system/btrfs_test

$ sudo mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/system/ext4_test

$ sudo mount -o compress=lzo /dev/system/btrfs_test /test/

$ sudo mount /dev/system/ext4_test /test/ext4

$ time tar cf /test/ext4/firefox.tar /test/ext4/firefox-127.0
tar cf /test/ext4/firefox.tar /test/ext4/firefox-127.0  3,07s user 23,91s system 40% cpu ***1:06,35*** total

$ time tar cf /test/btrfs/firefox.tar /test/btrfs/firefox-127.0
tar cf /test/btrfs/firefox.tar /test/btrfs/firefox-127.0  0,87s user 8,23s system 56% cpu ***16,166*** total

Пожалуйста, запустите этот простой тест на своей любимой файловой системе и поделитесь результатом, чтобы сравнить.

Давайте выберем наиболее быстрый способ расстаться с данными!

export TEST_DIR=<каталог любимой ФС, где 2 ГБ свободно>

uname -rp

wget https://ftp.mozilla.org/pub/firefox/releases/127.0b5/source/firefox-127.0b5.source.tar.xz -O $TEST_DIR/firefox-127.0b5.source.tar.xz

echo 3 | sudo tee /proc/sys/vm/drop_caches

time tar xf $TEST_DIR/firefox-127.0b5.source.tar.xz -C $TEST_DIR

echo 3 | sudo tee /proc/sys/vm/drop_caches

time tar cf $TEST_DIR/firefox.tar $TEST_DIR/firefox-127.0

Перемещено hobbit из general

Здравствуйте,

Я хочу поговорить о страничном кэше с занудной бухгалтерией байтиков и электричества.

У меня есть десктоп, который запускает обычные десктопьи приложения и ещё раздаёт торренты. Постоянное чтение файлов, раздаваемых через торрент, тянет их в страничный кэш /page cache/, но hit rate у этого кэша заведомо стремится к 0, а ресурсы заняты зазря.

В системе 16 ГБ оперативки, приложениями обычно занято не более 4-6 ГБ. Но с забитым под завязку кэшем система аж swap выдавливает, вот картинка за неделю.

С 12 января я попробовал запускать торрент-клиент через nocache и терапевтический эффект минимальный: на пару гигабайт свободнее. Тем не менее, раздаваемых через файлов в кэше полно:

 → find ./torrent/ -type f -exec cachestats {} \; | awk -F'[ /]' '{s+=$4} END {printf("%d pages in cache * 4K\n",s)}'

2235489 pages in cache * 4K

2235489 * 4 / 1024^2 = 8.53 ГБ оперативки под мусор.

Есть ли способ органичить страничный кэш для отдельного тома или приложения? Я только за, чтобы в кэше были нужные файлы, и не хочу крутить глобальный vfs_cache_pressure, но вот лишнее держать — сомневаюсь.

А стоит ли вообще внимания эта возня? Или всё это экономия на спичках и ядру самому виднее, что куда класть?

По следам новостей, что Chromium в Ubuntu теперь будет поставляться только в snap, я его попробовал.

Оказалось, что при запуске браузера из snap я не могу открывать ссылки 'magnet:'. По клику на такую ссылку ничего не происходит, только в логе вижу chromium_chromium.desktop[14558]: user-open error: Supplied URL scheme «magnet» is not allowed

Эти больные ублюдки захардкодили в snap доступные наружу схемы url! https://github.com/snapcore/snapd/blob/master/usersession/userd/launcher.go#L60

Как с этим предполагается жить? Я что-то делаю не так?

Привет!

Я у мамы программист и поэтому чужие люди попросили меня купить ноутбук, хоть я в этом ничего не понимаю. Обнаружилось интересное:

На «микрокомпьютере» c Pentium N5000 1.1 ГГц и sata-диском под Win10 холодный запуск Chrome происходит за ~1 секунду.

На моём десктопе с i3-7100 и raid0 из двух nvme под обычной Ubuntu 18.04 Chromium без дополнений запускается ~3 секунды. У хранилища на этом десктопе полоса больше 1500 МБ/c на случайном доступе и отклик 0,05 мс.

Почему такая разница? Это нормально? Есть ли лучшие практики, как на моём десктопе с Linux в 2019 году получить такую же отзывчивость?

Я давно привык использовать nvidia на локалхосте, но последнее время меня несколько раздражает их проприетарный блоб в системе с функционалом из прошлого и без поддержки KMS. Nouveau без OpenGL живым не выглядит.

Каким видео сегодня можно пользоваться с открытыми драйверами для композитного оконного менеджера и ускорения прокруточки в браузере?

Как дела у ATI, например?

Привет,

Чтобы продлить ресурс жёсткого диска на локалхосте я использую Bcache. С записью всё замечательно, а со случайным последовательным чтениям на торрентах всё как-то неоднозначно:

• без readahead система, будто бы, пихает в кэш всё, что прочитала и мусолит ssd почём зря;

• с малым readahed жутко насилует hdd чтением;

• с бо́льшим readahed вообще случаются гравитационные аномалии — на картинке —, которые мне сложно интерпретировать.

Вот картинка активности на реальных данных с разными параметрами readahed и sequential_cutoff_size в Bcache: https://dl.dropboxusercontent.com/u/20797837/bcachetest.svg

Можно ли добиться адекватной работы упреждающего чтения на блоках ~4Мб, чтобы убрать нелинейное чтение с HDD и что для этого покрутить?

Какой режим работы на картинке выглядит наиболее здоровым?