Bcachefs показала неожиданную производительность

Мдааа, что-то совсем грустно на графиках.

Есть шансы, что это неоптимальный алгоритм драйвера, который допилят?

Кент уже не кент.

Я знал, что btrfs медленнее, но чтобы на столько. Жесть. Лучше бы не смотрел.

А bcachefs вообще похоронили.

Мда…

У БишкекФС еще есть шанс, т.к. ее жизнь и тестирование только начались.

Очень жаль, что Майкл не тестирует так же zfs, вангую, что многие жопы были бы отправлены на Марс :) Правда не ясно с какой стороны.

Да, было бы интересно.

Кстати, появлись некоторые вопросики к t184256. Он-то бил себя пяткой в грудь, что использует БишкекФС уже 10000 лет. И что, за все это время у него не появилось желание протестировать производительность и узнать страшную правду?

Вот так и доверяй лоровским специалистам. Они тебе будут рассказывать байки, основываясь только на своих маняфантазиях.

Какой-то уж слишком большой провал, вангую неоптимальные настройки, реквестирую тестирование на лорчике)

Почитал ссылку, фигня какая-то, у bcachefs и btrfs куча фич типа шифрования и снапшотов, но в тестах не указано, с какими фичами тестировалось. Автор просто тестировал дефолт? Поцоны не ходите по ссылке, там только куча повторяющихся графиков, а текст только о том, что он собрал из гита bcachefs-tools, а они выдали ошибку на одном из его ssd)

В общем, в комментах он написал, что zfs еще не собрали для 6.7 ведра:

OpenZFS doesn’t build against Linux 6.7 git yet.

Типичный набор рандомных тестов от мороникса, которые неизвестно что тестируют.
Интересно, а почему отсутствует традиционный «Geometric Mean Of All Test Results»?
Потому что там замшелый ext4 быстрее всех?

Там разве не XFS традиционно побеждает?

Может и она, но уж точно не новомодные средства для потери данных.

Я знал, что btrfs медленнее, но чтобы на столько.

Что-то там не так. Я тоже тестировал btrfs для себя, было где-то на 20% медленнее, но не в несколько раз как на форониксе.

Flexible IO Tester Rand Write - IO_uring - Yes - Yes - 4KB - Default Test Directory (IOPS ↑ ) 143750

У фороникса: 77760

Причём у меня по спекам SSD в два раза медленнее по IOPS, чем у фороникса.

Причем тут вообще это, на похорониксе тесты выбираются от балды, без какого либо объяснения, почему они были выбраны и что их результаты означают.

Вот я тебе и предлагаю сделать свои правильные тесты или хотя бы описать какими они должны быть.

Может в 6.7 что-то сломали?

Так сделай, я не против.

Ясно.

Очень интересно было бы посмотреть на флеймграфы. Хз, мб на неделе попробую.

С другой стороны, у него в тестах есть явный нюанс: fio пишет/читает с O_DIRECT. Большой вопрос в том оптимизировали ли под такое bcachefs.

Собственно, вот его direct write:

ssize_t bch2_direct_write(struct kiocb *req, struct iov_iter *iter)
{
	struct file *file = req->ki_filp;
	struct address_space *mapping = file->f_mapping;
	struct bch_inode_info *inode = file_bch_inode(file);
	struct bch_fs *c = inode->v.i_sb->s_fs_info;
	struct dio_write *dio;
	struct bio *bio;
	bool locked = true, extending;
	ssize_t ret;

	prefetch(&c->opts);
	prefetch((void *) &c->opts + 64);
	prefetch(&inode->ei_inode);
	prefetch((void *) &inode->ei_inode + 64);

	inode_lock(&inode->v);

	ret = generic_write_checks(req, iter);
	if (unlikely(ret <= 0))
		goto err;
[...]

Здесь inode_lock() это семафор. То есть fio с O_DIRECT как минимум натыкается на семафор (который в отличии от спинлока может спать) в параллельных запросах в один файл. Хз насколько сильно это влияет в данном случае (я мало что смыслю в fs/), но это может добавлять проблем.

Ничего тебе не ясно.
Ты дурачок, целевая аудитория алкаша Михаэля, который во время запоев публикует вот такие вот, ничего не значащие тесты.
Впрочем, это не умоляет его заслуг, хорошего он тоже много чего сделал, в отличии от тебя.

PS
Для нейроразнообразных, это все написано just4lolz

Эмм… там btrfs сосёт не меньше.

Особенно вот на этой странице: https://www.phoronix.com/review/bcachefs-linux-67/3

Но да, забавно вышло.

Использую. Производительность ни разу не измерял. Как часто измерял производительность своей FS ты и, если хоть раз измерял, не потерянный ли ты брат Майкла?

Michael «Похороникс» Larabel сделал первые попытки протестировать производительность свежеиспеченной файловой системы bcachefs.

первые

ни за что не поверю

Kent Overstreet

I suspect a lot of this might be from having CONFIG_BCACHEFS_DEBUG_TRANSACTIONS on by default.

Штош, будем надеяться, что причина в этом, ждем новых тестов.

Этому миру нужен новый Интернет. Уже и Похороникс не открывается, через клятый Клаудфлёр.

https://www.patreon.com/posts/note-on-phoronix-92281382

• удивительные цифры всирания btrfs, самой медленной из известных ФС, пока не воспроизводятся
• был найден баг, состоящий в том, что CONFIG_BCACHEFS_DEBUG_TRANSACTIONS включен по дефолту, возможно, часть проблемы в этом

удивительные цифры всирания btrfs, самой медленной из известных ФС, пока не воспроизводятся

У нас нет side-by-side конфигов fio чтобы сравнивать.

Ну там #bcache уже пару дней непрерывно все бенчит в поисках ответов :)

Ну там #bcache уже пару дней непрерывно все бенчит в поисках ответов :)

Ахахахаха. А где он, на oftc?

Tl;dr: в основном сосет.

Датышто.

А что там новой ядерной нтфс, как с производительностью? Можно уже забыть про остальной зоопарк?

Это ж фороникс... Они даже FreeBSD принципиально на стоковом ядре тестируют.

принципиально на стоковом ядре тестируют.

А надо как? Смысл теста в том, чтобы показать производительность, которую получает пользователь, а не специалист по ядру, фс, богзнаетчегоеще после пердоллинга. Если разработчики и мейнтейнеры не додумались до нормальных дефолтов, то значит оно вот такое вот.

Эээ... У linux есть ванильные ядра, а есть редхат.

У linux есть ванильные ядра, а есть редхат.

В чем разница? Что за Редхат, во-первых, если RHEL, я так понимаю они бэкпортируют фиксы и фичи в старые ядра. Но при чем тут это.

*bsd с «ванильным» при установке.

Там приземлили новую версию с отключённым по умолчанию дебаг-режимом, пару фич и исправления.

А с чего там приросту быть то? Уже вылизали теорию всю в ФС, как кот яйца. Принципиально новые алгоритмы могут только для ускоренной индексации всякими балу быть использованы, за счёт снижения каких-то других метрик. А всё остальное будет только резать скорость. Так что либо приросты по 3% за счёт того что какой-то код переписали лучше/баги пофиксили или новый алгоритм разработали который на 1% быстрее по дереву ходит в каких-то специфических случаях, например, если оно очень большое.

Ничего страшного, скоро там заглушка будет от РКН.

А с чего там приросту быть то?

ОТКЛЮЧИЛИ СЛИПЫ!

https://www.phoronix.com/news/Bcachefs-Updated-Linux-6.7

Хорошо показала себя в Application startup time

Я посмотрел те тесты. И там как заметили комментаторы, в очередной раз автор обосрался. На мнение этого эксперда уже не раз тут ссылались. В прошлый раз он так все намерял, что и скорость чтения/записи btrfs была в разы ниже. В это раз у него вышло, что btrfs пишет/читает медленее на 10% - ВЕРЮ. А вот запуск приложений в 3 раза дольше???? Это как при скорости чтения незначительно меньше? ТУТ НЕ ВЕРЮ. И… стоит только включить сжатие, и тогда тесты будут показывать небывалое преимущество в чтении-записи той же btrfs над ext4 (при сжатии zstd:3 3-4x в среднем, циферки будут ого-го), что как бы читерство и не объективно, но это как пример сомнительности этих тестов. Bcachefs я не пробовал, но на примере с btrfs у меня уже сомнения насчет того дело в самой файловой системе или в том, кто их проводит.