https://slinkov.ru/openforum/vsluhforumID3/131562.html В состав ветки linux-next, в которой тестируются возможности для будущих выпусков ядра Linux, принят код файловой системы Bcachefs. Ранее, Кент Оверстрит (Kent Overstreet), автор Bcachefs и входящей в состав ядра Linux системы кэширования блочных устройств на SSD-накопителях BCache, отправил Линусу Торвальдсу poll-запрос на включение кода Bcachefs в основной состав ядра Linux, но Линус отклонил их и рекомендовал вначале оценить пригодность предложенных патчей в экспериментальной ветке Linux-next. В случае успешного рецензирования ФС Bcachefs может быть включена в состав ядра 6.7, выпуск которого ожидается в декабре...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=59785<br> https://slinkov.ru/openforum/vsluhforumID3/131562.html#298 Thu, 26 Oct 2023 20:33:29 GMT &gt;&gt; И ext4 хватает за глаза <br>&gt; Зато если под системной либой случайный бэд образуется - глаза получаются довольно <br>&gt; большие. Когда система резко, внезапно и без предупреждения в тыкву превращается. <br>&gt; При том сразу наповал. Без шансов что-то с этим сделать вообще. <br>&gt; Еще интереснее когда железо немного подглюкивает. Там что угодно может быть. Например <br>&gt; все как живое - но в 1 не очень прекрасный момент <br>&gt; все почему-то дохнет. И не факт что чинится fsck. И конечно <br>&gt; в лучших традициях RAS (а точнее его отсутствия) это выносит систему <br>&gt; резко, внезапно и без намека на предупреждение о грядущих проблемах.<br><br>ext4 нормально фурычил на хреновых hdd бэд переводил в read-only режим, отмонтируешь fsck и всё работает, а вот проблему btrfs что в fs хранится файлов на 10гб, а места занято на 500гб, из-за одного файла и глючного скрипта забыть не могу, и это штатное поведение.<br> https://slinkov.ru/openforum/vsluhforumID3/131562.html#297 Wed, 27 Sep 2023 13:35:03 GMT &gt; На механике фрагментация это фу. На SSD - сильно меньше фу, можно <br>&gt; не очень париться. А большой непрерывный экстент всяко эффетивнее кучи мелочи. <br>&gt; Вопрос в масштабе эффекта и стоит ли оно заморочек в конкретном <br>&gt; случае.<br><br>Меньше, конечно, но не настолько уж и сильно меньше фу. Мелкоблочное чтение даже на быстрых NVME НАМНОГО медленнее линейного и большого прогресса тут не видно (как минимум пока не откажутся от трансляции, что опять же потребует новых ФС и механизмов выравнивания). А распространение безбуферных дисков эту проблемку еще и усиливает - невозможность разместить всю таблицу трансляции в набортном RAM осложняет скачкообразное чтение по всему диску. В том же Линуксе безбуферники берут от системной памяти 128 (хотя кое где говорят что 256) мегабайт, а обычное соотношение RAM к NAND - 1 мегабайт на 1 гигабайт, т.е. 1 гигабайт буфера под 1 терабайт диска. Жить можно, но становится понятно почему вендоры так любят выпячивать именно линейную скорость.<br> https://slinkov.ru/openforum/vsluhforumID3/131562.html#296 Wed, 27 Sep 2023 13:14:02 GMT &gt;&gt; Теоретически модный bcache при записи должен пихнуть рип на SSD <br>&gt; ага. Напоминаю - откуда он взялся-то? Правильна - либо с флэшки, либо <br>&gt; с интернета, и скорость поступления этих данных не то что для <br>&gt; ssd, а для mfm hdd вполне посильна.<br>&gt; Поэтому мы просто даром тратим ресурс.<br><br>Ну так для тех же быстрых NVME даже в тестах данные льются чтобы скорость проверить - с другого такого же NVME, иначе откуда еще? Самый быстрый SATA SSD не загрузит на полную даже PCI-E 3 диск стоящий во втором слоте с двумя линиями PCI-E.<br><br>С другой стороны там только в кэше такая скорсоть, так что...<br> https://slinkov.ru/openforum/vsluhforumID3/131562.html#295 Wed, 27 Sep 2023 09:26:41 GMT ФС может хранить данные вообще как угодно, и решение таки принимает юзер - сжатие можно как не включать вовсе, так и отключить на отдельном subvolume. Если нравятся костыли по типу zcat и zgrep, то никто вас не отговаривает от такой ручной работы, но это лишняя сущность. Захотел ты по man'ам поискать что-то - grep с флагом -R уже не сделаешь, а в zgrep флага -R нет. И может я не хотел бы, чтобы man'ы были пожаты в .gz, или хотел бы, но чтобы в .zst.<br> https://slinkov.ru/openforum/vsluhforumID3/131562.html#294 Wed, 27 Sep 2023 08:05:11 GMT Ну, это уже прямое нарушение OSI. ФС вообще сжатием заниматься не должна. Решение о сжатии должен софт принимать или юзер.<br> https://slinkov.ru/openforum/vsluhforumID3/131562.html#293 Wed, 27 Sep 2023 07:40:07 GMT &gt; We managed<br>&gt; We are proud<br><br>I'm lovin' it )<br> https://slinkov.ru/openforum/vsluhforumID3/131562.html#292 Tue, 26 Sep 2023 20:29:55 GMT то, как в первых имплементациях было реализовано, было напрямую взято из bcache, но позже всё переделали для именно файловой системы<br> https://slinkov.ru/openforum/vsluhforumID3/131562.html#291 Tue, 26 Sep 2023 16:48:48 GMT &gt; Мне лично задержки не критичны и большая часть пользовательских данных мне видится <br>&gt; похожей на man'ы, которые в .gz и в основном пылятся.<br><br>Ну как, в случае быстрой SSD'хи на умеренном проце скорость записи zstd может заметно обвалить. А там еще чексумы считать надо, том тоже на скорость. В этом месте LZ4 и LZO деланные под "реалтаймное сжатие" получают пойнт.<br><br>&gt; А LZ-алгоритмы это для чего-то типа zswap, траффика и динамичных игр,<br><br>Ну вообще я zram и с LZ4 или ща LZO+RLE модно у них стало. Довольно хорошее, кстати, комбо. RLE уменьшает тупняки на сжатие избыточных последовательностей коих в раме есть, в паре с LZO довольно хорошо жмет, там вопрос в том что либо сожмется минимум в 2 раза, и тогда профит, или нет - тогда зря сожрали ресурсы: там округление до страницы ради скорости. Можно 2 в 1 паковать. Или опциональный 3 в 1 (если данные позволили, конечно). Там рыхлость LZ4 икается больше: если 2x сжатие не вышло, проц тратили вообще зря.<br><br>...и в результате OOM с таким "свопом" без выгрузки в файл https://slinkov.ru/openforum/vsluhforumID3/131562.html#290 Tue, 26 Sep 2023 12:25:38 GMT &gt; Еще один "свидетель RUSTовый". Нах..на вы лезете туда, разбираться в чем не <br>&gt; хотите? Дискредитируя всю отрасль в целом своими поделками на местах?<br><br>ИМХО, дискредитируют - напыщенные бакланы, которые свое мнение обосновать не способны, зато горазды пальцы загибать. Тоже мне эксперты, выучили пару заклинаний и давай корчить из себя умников и пуп земли на этом основании. А потом оказывается что можно в 20 раз проще, лучше и без этой камасутры. И всех этих ветеран-тормозов вместе с левыми ритуалами и уходят пачками.<br><br>&gt; Ничего сложного в IPSec нет.<br><br>Все познается в сравнении. Вайргад по сравнению с этим мусором - просто образец логики и лаконичности. С нормальным крипто, приличным перфомансом, в дохрена раз меньше кода и это при простой настройке. За что и заслуженный титул - "compared to openvpn and ipsec ... work of art" (c) Linus Torvalds.<br><br>И да, владелец адекватной точки зрения ее обосновать может. Не киванием на авторитет и загибанием пальцев а логически и технически. Но тебе и всяким похам это все