https://www.opennet.me/openforum/vsluhforumID3/137212.html Очередная дискуссия между Линусом Торвальсом и Кентом Оверстритом (Kent Overstreet), автором Bcachefs, завершилась тем, что Линус выразил готовность исключить код Bcachefs из ядра Linux 6.17. При этом Линус принял в состав ядра 6.16 изменения в Bcachefs, ставшие предметом очередного недовольства действиями Кента. Линус написал:...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=63489<br> https://www.opennet.me/openforum/vsluhforumID3/137212.html#456 Thu, 14 Aug 2025 13:38:01 GMT &gt;Bcachefs задумывалась как аналог zfs, но в ядре. Не будет в ядре &#8211; зачем тогда оно? Есть протестированный и годами отлаженный zfs. А Bcachefs никто без ядра тыкать не будет.<br><br>Насколько я понимаю, против ZFS в Linux работают два фактора, и нетехнический из них только второй.<br><br>1. ZFS спроектирована для работы в составе ядра Solaris в качестве ФС по умолчанию. В частности, в Linux она использует свой собственный кэш вместо общеядерного, а также активно использует vmalloc, который в Linux не так эффективен (вместо него в нативных драйверах стараются использовать kmalloc, но прямая замена не возможна, так как для kmalloc нужен блок физической памяти, идущий подряд).<br><br>2. Лицензия ZFS создаёт дистрибутивам юридические проблемы при распространении бинарных пакетов с ней. Да, это решаемо, но не все хотят связываться. Если вместо бинарников распространять dkms-пакет, то лицензионныен проблемы исчезают, зато появляется необходимость держать на сервере компилятор, что не всех устраивает.<br> https://www.opennet.me/openforum/vsluhforumID3/137212.html#455 Tue, 08 Jul 2025 17:52:00 GMT &gt;Bcachefs задумывалась как аналог zfs, но в ядре<br><br>Там есть фичи, отсутствующие в zfs.<br> https://www.opennet.me/openforum/vsluhforumID3/137212.html#454 Mon, 07 Jul 2025 06:34:21 GMT Джва раза ловил истощение айнодов... :-(<br> https://www.opennet.me/openforum/vsluhforumID3/137212.html#453 Sat, 05 Jul 2025 15:14:15 GMT О какой ФС из 70 речь?<br><br><br>Есть proofs на тему "silent corruption"?<br><br><br>И скакой версии о них известно - что то новое? если да то может и исправят всё же.<br><br><br>Это только в FreeBSD или и прочих *BSD?<br><br><br>&gt; У файловых систем дизайна 70х годов - проблемы примерно одинаковые, что тут, что там.<br><br>Врядли же в FreeBSD - и в FAT "silent corruption".<br><br><br>&gt; поскольку zfs лежащая в contrib как-то довольно условно теперь "с ядром")<br><br>А, что за история - тоже глюки или просто лишней оказалась<br> https://www.opennet.me/openforum/vsluhforumID3/137212.html#452 Sat, 05 Jul 2025 14:53:16 GMT Индксирование, по поределению - например, не может:<br>* ускорить считывание файлов <br>* или сравнение каталогов (т.к.тут утилитой чтение всёравно линейное же);<br>* и т.б.по содержимому;<br>* как и ускорить Поиск файла даже по имени - вне встроенных в ОС файловых утилит, как умеющеми пользоваться индексом для Поиска. А, все прочие, сторонние, утиличты так не умеющих или не имеющих достаточно прав - как понимаю: проходят мимо. <br> https://www.opennet.me/openforum/vsluhforumID3/137212.html#451 Sat, 05 Jul 2025 14:29:49 GMT &gt; виндовс 10 слизал эту функцию,теперь индексация совместно с фс работает.<br><br>Индесация куда раньше у MS была, вроде с вин2000, в XP точно есть. <br><br>А, вот в вин-11 - туда срёт гигантскими кирпичами уже и ИИ встроенный в ОС (и вероятно даже если его выключить - то и встроенный в браузеры) <br>- даже официаьно на сайте МС правда мелкими буовками - не на видном месте а, если поискать: храня там свои дополнительные индексирования, всяких релевантнотей в т.ч.тех же файлов и их содержимого. <br>Ну и в памяти тоже значит.<br><br>Т.о.ускорение если и есть, не на словах, от индексации - то весьма дорогой ценой и до w11-ой а, тут - так вообще... Просто покупай топовый новый комп чтобы было где шпионскому софту вмещать всё что ему надо.<br><br> https://www.opennet.me/openforum/vsluhforumID3/137212.html#450 Sat, 05 Jul 2025 14:14:01 GMT Хорошая производительность зато. И только при панике или полном фризе, который киллер не достанет. Если это происходит регулярно, у тебя есть куда большие проблемы, помимо сохранности данных. С большой вероятностью ничего плохо не будет, но кэши браузера и иногда дополнения могут сломаться. Только барьеры не отключай, рассыпется. У меня происходит только благодаря vkd3d-proton, не проблема. И да, libeatmydata очень ощутимо ускоряет многие процессы. Хотя есть ещё обесточивание, но тут нештатно сложно получить.<br> https://www.opennet.me/openforum/vsluhforumID3/137212.html#449 Sat, 05 Jul 2025 14:13:03 GMT &gt;&gt; Подробней можно?<br>&gt; В реестре отключается пространство имён Posix, тоже ускоряет чуть работу при большом количестве файлов в каталоге.<br><br>Prof'ов конечно же не будет?...<br><br><br>&gt; Сейчас на скорую руку не скажу ключ в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem<br><br>Я так подзреваю там речь про API. <br>Т.б.потому что, вот уже вы - не поверите но, внутренность виндов давно работает через POSIX именования путей. Т.о.даже если допустить что, этот ключ запрещает делать это же пользователю - внутри ядра виндов всёравно иначе не может быть.<br><br><br>&gt;С какой стати это<br>&gt; У тебя полмиллиона файлов в каталоге - с юникод именами, сказать количество комбинации для файла с 12 символами ?? А драйверу нужно все эти комбинации перебирать.<br><br>А, чего сразу - не миллиардов?... У меня самый дико забитый мелкими файлами диск это 200GB раздел с ~200 тыс мелкиз файлов в стиле картинки и книги, причм всёравно очень разных размеров впоть до сотен мегабайт - и после нескольких лет попыток отсортировать это дело и удалить https://www.opennet.me/openforum/vsluhforumID3/137212.html#448 Sat, 05 Jul 2025 13:52:32 GMT &gt; превращается в боль и страдание (и все внутри ядра в системном контексте), вместо просто сравнения байтовых последовательностей - косвенный поиск по таблице<br><br>Я когда то на ПК в сотню Мгц мерял только перекючение контеста - получил десятки тысяч тактов, и это в вин9x с ядром на ассемблере, а ведь на нынешних компа да и ОС на Сях в лючшем случае - получается на с 50 раз больше частотой надо умножить ещё в 50 раз <br>- т.о.только на этом фоне: обращени к таблице, да хоть храни они её для примера в бинарном дереве инедксно - это вообще ничто. А, дисковые же операции и того больше жрут.<br>