Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Повышение производительности Btrfs в ядре Linux 6.17"	+/–
Сообщение от opennews (??), 26-Июл-25, 10:17
Для включения в будущее ядро 6.17 предложены оптимизации и новые возможности,  повышающие производительность Btrfs:... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63630
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Повышение производительности Btrfs в ядре Linux 6.17"	–1 +/–
Сообщение от Аноним (1), 26-Июл-25, 10:17
Хорошая ФС
Ответить | Правка | Наверх | Cообщить модератору

	55. Скрыто модератором	+/–
	Сообщение от Аноним (-), 26-Июл-25, 15:27
	Хорош пока не потерял данные.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (80), 26-Июл-25, 18:07
	До первого отключения света
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

4. "Повышение производительности Btrfs в ядре Linux 6.17"	+3 +/–
Сообщение от Шарп (ok), 26-Июл-25, 10:38
Лучшая ФС. Использую дома с 2016 года.
Ответить | Правка | Наверх | Cообщить модератору

	9. "Повышение производительности Btrfs в ядре Linux 6.17"	–3 +/–
	Сообщение от Аноним (9), 26-Июл-25, 11:01
	сочувствую.  btrfs тупо жрёт место непонятно куда
	Ответить | Правка | Наверх | Cообщить модератору

	11. "Повышение производительности Btrfs в ядре Linux 6.17"	+1 +/–
	Сообщение от Аноним (11), 26-Июл-25, 11:11
	Примерно 5% под метаданные, какой ужас
	Ответить | Правка | Наверх | Cообщить модератору

	13. "Повышение производительности Btrfs в ядре Linux 6.17"	–1 +/–
	Сообщение от Аноним (13), 26-Июл-25, 11:19
	А какие накладные расходы у ext4 или XFS? Или, прости Господи, у NTFS?
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Повышение производительности Btrfs в ядре Linux 6.17"	+1 +/–
	Сообщение от Аноним (-), 26-Июл-25, 14:08
	>  А какие накладные расходы у ext4 или XFS? Или, прости Господи, у NTFS? Это все на самом деле очень зависит от характера использования ФС. Но в среднем по больнице разница обычно минимальна. Это не значит что так же будет в всяких эзотеритических случаях, разумеется.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 26-Июл-25, 17:22
	Прощаю. У NTFS грубо гигабайт MFT для каждого миллиона файлов или папок, плюс хвосты/слэк конечно же. USN журнал - по вкусу, кому как, за умолчания не в курсе. При компрессии write amplification жестокий, что для ФС 80-х годов прошлого столетия как бы ожидаемо.
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	17. "Повышение производительности Btrfs в ядре Linux 6.17"	+2 +/–
	Сообщение от Fracta1L (ok), 26-Июл-25, 11:51
	Не 5%, меньше: # btrfs filesystem df / Data, single: total=39.01GiB, used=32.09GiB System, DUP: total=8.00MiB, used=16.00KiB Metadata, DUP: total=2.00GiB, used=1.02GiB GlobalReserve, single: total=68.52MiB, used=0.00B
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	19. "Повышение производительности Btrfs в ядре Linux 6.17"	–2 +/–
	Сообщение от rm_ (ok), 26-Июл-25, 12:09
	Если у вас торренты или виртуалки (короче, файлы с перезаписью частей файла), то есть такой момент, там понятно куда, но пока не исправлено.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	29. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (29), 26-Июл-25, 13:24
	Что пока не исправлено? Ваше знание обсуждаемого предмета?
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 26-Июл-25, 14:13
	> Если у вас торренты или виртуалки (короче, файлы с перезаписью частей файла), > то есть такой момент, там понятно куда, но пока не исправлено. О чем вы там? В более-менее свежих ядрах там все известные случаи - устранены. И в целом оно - just works. Единственное что юзать это лучше с новыми ядрами, хотя-бы 6.x. Оно почти никогда не регрессует ибо девы трезво оценивают что делают - а вот известные проблемы и "особенности" чинят довольно активно.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	35. "Повышение производительности Btrfs в ядре Linux 6.17"	+2 +/–
	Сообщение от Аноним (-), 26-Июл-25, 14:06
	> сочувствую.  btrfs тупо жрёт место непонятно куда Понаделал снапшотов и забыл стереть? У н00бов с виртуалками тоже такое бывает :)
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	6. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (6), 26-Июл-25, 10:57
	Просто придут те кто потерял данные из-за сбоев btrfs и тебе наваляют.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	12. "Повышение производительности Btrfs в ядре Linux 6.17"	+8 +/–
	Сообщение от Аноним (1), 26-Июл-25, 11:14
	>"и тебе наваляют. " А зачем вы свои комплексы на всех проецируете?
	Ответить | Правка | Наверх | Cообщить модератору

	21. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (21), 26-Июл-25, 12:39
	>проецируете таки напихают под хвост
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Повышение производительности Btrfs в ядре Linux 6.17"	+1 +/–
	Сообщение от Аноним (23), 26-Июл-25, 12:50
	>А зачем вы свои комплексы на всех проецируете? Чтов эти "Все" не теряли свои данные из за твоих росказней про надежность бэтера.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	38. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 26-Июл-25, 14:15
	> Чтов эти "Все" не теряли свои данные из за твоих росказней про > надежность бэтера. Я вот юзаю btrfs уже дофига, в куче конфиг - и ничего не потерял. А сказочники мне - надоели. Модеры, нельзя ли их отсюда - убрать? Пусть где-нибудь еще упражняются в свеой культуре уровня гопника.
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Повышение производительности Btrfs в ядре Linux 6.17"	–3 +/–
	Сообщение от Anonimm (?), 26-Июл-25, 14:51
	Ошибка выжившего. Здесь все - 4% истинных линуксоидов - говорят, что ext4 сверхнадежна и "уронить" её очень сложно. А у меня при копировании с NAS на диск с "неубиваемой" ext4 появилась "ошибка копирования" и диск перестал определяться. После всех проверок в Linux выяснилось, что суперблок затерт, резервные блоки не существуют, но теперь уже с ntfs этот диск работает и ошибок нет. Так что там с надёжностью?
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (21), 26-Июл-25, 15:04
	Ntfs может долго на посыпавшемся диске работать. Не очень хорошо, правда. Btrfs в случаях неисправного оборудования статистически лучше.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Anonimm (?), 26-Июл-25, 15:51
	> Ntfs может долго на посыпавшемся диске работать Только при каждом подключении выдаёт сообщение, что диск надо бы и проверить..
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 26-Июл-25, 16:13
	> Только при каждом подключении выдаёт сообщение, что диск надо бы и проверить.. При том если на это еще и удумать согласиться - то это как раз его порой и добивает окончательно в вон том случае.
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 26-Июл-25, 16:12
	> Ntfs может долго на посыпавшемся диске работать. Не очень хорошо, правда. Ну да, только он постепенно деградирует а в какой-то момент - хлобысь - не монтируется - и внутри уже везде труха! И даже если что и удастся оттуда отковырять - то основательно попорченое к этому моменту. Ибо в таком режиме оно могло делать хзчто довольно долго. > Btrfs в случаях неисправного оборудования статистически лучше. Он по крайней мере орать начинает на csum error и проблему можно заметить на подлете. А не когда том уже загажен в вермишель и там живого места нет.
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	57. "Повышение производительности Btrfs в ядре Linux 6.17"	–1 +/–
	Сообщение от Аноним (-), 26-Июл-25, 15:40
	> Ошибка выжившего. И у всего миллиарда юзерей FB - тоже? И у кастомеров оракла который эту штуку в Unbreakable сватает? Да черт, даже редхат опять стал заигрывать с оным, в федору не только напихали но и дефолтом по моему уже сделали. Правда поздняк, от редхата все адекватные спецы блочно-файлушного уровня с их XFS франкенштейном - свинтили. И теперь вокруг btrfs отвисают чего-то. Даже бывший майнтайнер XFS, задолбаный ботами гугла с CVE в коде "от дидов" (XFSv4) :D. Вообще, я лучше буду - выжившим. А тот дымящийся скелет потрогавший провод - экспериенс, таки, не накопил - по техническим причинам. Выжившим быть - прикольнее. > Здесь все - 4% истинных линуксоидов - говорят, что ext4 сверхнадежна > и "уронить" её очень сложно. Совсем ее разломать, до уровня когда и fsck обделается и правда - требует неких усилий. Но ничто не есть мировая константа. И это знание тоже. Сторажи стали - быстрее, емче, дешевле, и... гораздо хлипче! Потоки данных увеличились. Соотношения - изменились. То что было надежным вчера - сегодня реплэит на протертом SSD журнал с трухой, а fsck получив ЭТО - завершает cccombo-breaker, делая тому окончательное фаталити. Так что оно потом не монтируется, не чинится, и даже датарек с ЭТИМ - конкретно задолбается. Автыры EXT4 чешут репу, пилят CRC журналу. Даже если это и сажает скорость - вермишель вместо фс еще хуже. Чуть позже оказывается что и вермишель выданная SSD как метаданные - ведет к тому же результату. Автыри чешут репу еще раз. И начинают пилить чексуммы и для метаданных. И вот ... простая, быстрая ФС. Или таки - уже нет? И XFS следовало примерно тем же маршрутом. Они правда сову на глобус чуть лучше смогли и там чексумы вроде - даже и данным перепали таки. И даже рефлинки каким-то чудом. Но снапшоты в норм виде, нормальный менеджмент девайсов, пространства, схем RAID и проч от этого же не появится. Так что получилось - ни два ни полтора какое-то. Сложность уже почти как у btrfs, а фич почти как у EXT4. Зачем такое надо только RH и знает. > А у меня при копировании с NAS на диск с "неубиваемой" ext4 появилась "ошибка > копирования" и диск перестал определяться. Если диск перестал определяться - больше всего ЭТО похоже на проблему или кончину, пардон, накопителя. По линии фирмвары или его общего физического состояния. От этого никакая фс вообще не помогает, внезапно! Ну нет, если там RAID - как в btrfs/zfs/etc - тогда накопитель заменить - и порядочек. > После всех проверок в Linux выяснилось, что суперблок затерт, резервные > блоки не существуют, Сие как-то достаточно необычно. И похоже на сбой железа. > но теперь уже с ntfs этот диск работает и ошибок нет. Но я так то видел и битые NTFSы. Самые разные. Например немоунтабельный экспонат выносящий в BSOD все от винтукея до десятки. Наимный юзер принес его на соседний комп - а тот тоже в бсод хрясь. Юзер в панике - а как данные то вынуть? NTFS3G таки - прожевал более-менее (а если б он и брякнулся, оно в usermode ж было).
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	59. Скрыто модератором	+/–
	Сообщение от Аноним (23), 26-Июл-25, 15:49
	Не  знаю, где ты ее "Дофига" используешь, но  я два раза для теста пробовал ее под фс для портеджей. Оба раза заметное на глаз проседание по скорти относиттельно ext4 и отсутствие возможности смонтировать череез 3 месяца. Ядра естественнно последние. С ext4 проблем не было ни когда. По этому, я в целом за то, чтоб вы тестировали бэтера, даже в продакене. Но не надо заливать шлак в неокрепшие  умы.
	Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

	61. Скрыто модератором	–2 +/–
	Сообщение от Аноним (-), 26-Июл-25, 16:04
	> Не  знаю, где ты ее "Дофига" используешь, Много где. В разнообразных сценариях. От флешек до серверов. Ничего, живое. > но  я два раза для теста пробовал ее под фс для портеджей. Оба раза > заметное на глаз проседание по скорти относиттельно ext4 и отсутствие возможности > смонтировать череез 3 месяца. Ядра естественнно последние. А вот уверенности в стабильности работы системы - ноль. Может у вас там ядра глючные и рушат все? Я на btrfs билды кернелей гоняю. Чартерными рейсами. И на этом вашем ext4 cp --reflink для иерархии чтобы сделать "дифференциальный" ребилд с минимальным твиком параметров под соседний выводок - не того! Рефлинк сильно быстрей полной копии, а загаживать билды для одних систем чтобы отребилдить для других мне не с руки. Рефлинки делаются быстро, места жрет только на дельту, ну а на EXT4 такое конечно невозможно. > С ext4 проблем не было ни когда. Без сообщений об ошибках и конкретных сведений мы говорим ни о чем. В принципе для разовых биддов EXT4 немного пошустрее. Но весьма зависит от того что и где на самом деле. Например если в 1 дире дофига файлов - EXT4 весьма отстоен бывает. Btrfs'у же 300К файлов в 1 дире в разумных пределах похрен. > По этому, я в целом за то, чтоб вы тестировали бэтера, даже > в продакене. Его уже в целом миллиард хом фэйсбука оттестил так что многим и не снилось. > Но не надо заливать шлак в неокрепшие  умы.   Вот и не заливайте. Особенно касается всяких гентушников - которые часто пытаются косплеить системщиков, не умея это делать. За что потом и страдают, да еще делая глобальные выводы из своей кривизны рук. За это же гентушников не любят и в багтреках программ - вечно лезут ко всем с уникальными невоспроизводимыми багами.
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Повышение производительности Btrfs в ядре Linux 6.17"	–4 +/–
	Сообщение от Аноним (29), 26-Июл-25, 13:25
	Вас, уважаемый, мамка не доносила?
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	50. Скрыто модератором	+/–
	Сообщение от Аноним (6), 26-Июл-25, 15:07
	Тебя мамка походу она ещё и сразу после рождения голосов об бетонный пол стукнула.
	Ответить | Правка | Наверх | Cообщить модератору

	14. "Повышение производительности Btrfs в ядре Linux 6.17"	–2 +/–
	Сообщение от Анониссимус (?), 26-Июл-25, 11:22
	Лучшая из имеющегося.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	51. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (6), 26-Июл-25, 15:08
	Хуже придумать трудно.
	Ответить | Правка | Наверх | Cообщить модератору

	56. Скрыто модератором	+/–
	Сообщение от Аноним (-), 26-Июл-25, 15:28
	>Лучшая ФС. Использую дома с 2016 года. С 2016 года сколько ты данных понерял? Только честно.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

10. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
Сообщение от Аноним (11), 26-Июл-25, 11:09
Чем фолианты от hugepages отличаются?
Ответить | Правка | Наверх | Cообщить модератору

	18. "Повышение производительности Btrfs в ядре Linux 6.17"	–1 +/–
	Сообщение от ананим.orig (?), 26-Июл-25, 12:03
	https://lwn.net/Articles/937239/
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Повышение производительности Btrfs в ядре Linux 6.17"	+2 +/–
	Сообщение от Аноним (-), 26-Июл-25, 14:22
	> Чем фолианты от hugepages отличаются? Вообще совсем другая ипостась. Hugepage - страница памяти более чем традиционные 4кб. Теоретически, снижает нагрузку на трансляцию адресов и paging (TLB и проч). Практически - это не халявный маневр. Ибо если используется не весь объем такой страницы - окей, RAM теряется вникуда, потери RAM от фрагментации возникают. Folio - совсем другая ипостась. Традиционно ФС ковыряли данные блоком по 4 кило - одна страница. Это же причина любить по дефолту 4 кило блоки в фс. Это все неплохо работало, и весь обвес апей и проч был построен вокруг этого. Но с пришествием сверхскоростного IO вдруг оказалось что ковырять потоки в многие гигабайты в секунду по 4 кило за присест вызывает дофига оверхеда. Поэтому ряд API были отрефакторены, чтобы работать сразу с "подшивкой" страниц, когда вместо 1 страницы вон те апя ворочают сразу "folio" из эн страниц. С пропорциональным снижением оверхеда на это все - ибо за присест ворочается не кусочек 4 кило а более солидный кус, так что в целом меньше распасов и оверхеда.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

15. "Повышение производительности Btrfs в ядре Linux 6.17"	+3 +/–
Сообщение от Аноним (15), 26-Июл-25, 11:33
Почти совсем готова к использованию. Уже 8 лет.
Ответить | Правка | Наверх | Cообщить модератору

	54. "Повышение производительности Btrfs в ядре Linux 6.17"	–1 +/–
	Сообщение от Уникум (?), 26-Июл-25, 15:24
	Дай угадаю: ты фанат иксов?
	Ответить | Правка | Наверх | Cообщить модератору

20. "Повышение производительности Btrfs в ядре Linux 6.17"	–1 +/–
Сообщение от Anonimm (?), 26-Июл-25, 12:38
> Экспериментальная > Ожидается А когда данные исчезнут или файлы станут "битыми" (привет, ext4), разработчики разведут руками (как всегда) и заявят, что "в наших тестах все было нормально"..
Ответить | Правка | Наверх | Cообщить модератору

	22. "Повышение производительности Btrfs в ядре Linux 6.17"	+2 +/–
	Сообщение от Аноним (15), 26-Июл-25, 12:48
	В ext4 никогда такого не бывает.
	Ответить | Правка | Наверх | Cообщить модератору

	40. Скрыто модератором	+/–
	Сообщение от Аноним (-), 26-Июл-25, 14:25
	> В ext4 никогда такого не бывает. Именно поэтому они CRC к журналу экстренно привинтили - а то на кривом железе оно могло вообще все развермишелить оказывается. А теперь - и к метаданным чего-то чексуммы привинчивать начала. И чего это они вдруг?... А, ну да, наверное потому что ничего не теряло. А каску одевают - для красоты. И бронежилет - для антуражу. А миноискатель - чтобы шикануть. И страховку - по приколу цепляют. Ведь что может пойти не так?
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Anonimm (?), 26-Июл-25, 14:54
	Серьёзно? https://www.linux.org.ru/news/linux-general/17448413
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	26. "Повышение производительности Btrfs в ядре Linux 6.17"	+1 +/–
	Сообщение от Аноним (21), 26-Июл-25, 13:08
	Ты перепутал с xfs (у неё тихие повреждения файлов на диске), ext4 очень надёжна. Если, конечно, не включать data=writeback -- тогда 1/1000 шанс, что открытый на запись файл будет замещён мусором.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	41. "Повышение производительности Btrfs в ядре Linux 6.17"	–1 +/–
	Сообщение от Аноним (-), 26-Июл-25, 14:27
	> Ты перепутал с xfs (у неё тихие повреждения файлов на диске), ext4 > очень надёжна. Если, конечно, не включать data=writeback -- тогда 1/1000 шанс, > что открытый на запись файл будет замещён мусором. У ext4 без полного журнала - файло при обрубившейся на середине записи модет влет остаться наполовину новым и наполовину старым. И конечно в большей части слуаев он вообще читаться не будет потом программами. ФС при этом конечно логически-консистентна по части трекинга аллокации места. Регионы под файлом корректно же трекаются. Так что fsck гонять не надо. А труха в файле - мало ли чего.
	Ответить | Правка | Наверх | Cообщить модератору

25. "Повышение производительности Btrfs в ядре Linux 6.17"	+2 +/–
Сообщение от Аноним (25), 26-Июл-25, 12:56
Уже два раза ломалась на рабочей станции, первый раз после обновления ядра, второй после отключения света, да починилось быстро по гайдам из интернета, но с нтфс и виндой такого не бывало, уже страшно за свои данные, планирую переезжать на что нибудь журналируемое типа ext4 или xfs, смысл от снапшотов для починки системы на том же диске, если вся фс сломалась и не может быть примонтирована.
Ответить | Правка | Наверх | Cообщить модератору

	27. Скрыто модератором	+/–
	Сообщение от Аноним (21), 26-Июл-25, 13:12
	Ntfs не менее успешно корёжит и теряет файлы, но главное фрагментация ни в какие ворота.
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Fenix (??), 26-Июл-25, 13:19
	Лет 8 на этой фс все устройства. Сломалось ровно один раз,  когда из raid 1 диск наживую вытащили. Вырубил машину, воткнул обратно диск,  включил, пошуршало 15 минут и всё на своих местах, всё работает.
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	32. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (21), 26-Июл-25, 13:46
	Смотря как часто из розетки дёргать. И никаких ntfs3g или более старых версий венды. Ну и повреждения будут тихими, она ничего не сообщает. А в целом, у нтфс очень низкая производительность при работе с кучей файлов, не просто так ресурсы бандлят.
	Ответить | Правка | Наверх | Cообщить модератору

	52. Скрыто модератором	+/–
	Сообщение от Аноним (6), 26-Июл-25, 15:10
	Ты тролль и сидишь на Винде, нет у тебя никакого btrfs.
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	75. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (75), 26-Июл-25, 17:12
	Постоянные отключения света были полгода, ни одного падения фс. Знаете что я дела не так? Я сижу на Debian stable с LTS ядром и не парюсь что у меня "устаревшее" (новое я в chroot|flatpak|distrobox поставлю).
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	82. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Anonimm (?), 26-Июл-25, 19:10
	Вот тут https://www.linux.org.ru/news/linux-general/17448413 как раз о "сверхнадежной" ext4 в Debian Stable.. 😆
	Ответить | Правка | Наверх | Cообщить модератору

31. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
Сообщение от Аноним (31), 26-Июл-25, 13:28
Никакие улушения не помогут когда ФС изначально ущербна архитектурно. В Линуксе вообще нет нормальных ФС.
Ответить | Правка | Наверх | Cообщить модератору

	34. "Повышение производительности Btrfs в ядре Linux 6.17"	+2 +/–
	Сообщение от Аноним (34), 26-Июл-25, 13:58
	Шишкин, когда твой reiser5 будет готов?
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Повышение производительности Btrfs в ядре Linux 6.17"	+1 +/–
	Сообщение от Аноним (-), 26-Июл-25, 16:24
	> Шишкин, когда твой reiser5 будет готов? Ему в пору свои ФС переименовать - в VaporWareFS. Будет лучше суть проекта отражать.
	Ответить | Правка | Наверх | Cообщить модератору

	69. Скрыто модератором	+/–
	Сообщение от Аноним (31), 26-Июл-25, 16:25
	Никогда. Шишкину ваш ляликс в пень не упёрся.
	Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

	42. "Повышение производительности Btrfs в ядре Linux 6.17"	–1 +/–
	Сообщение от Аноним (-), 26-Июл-25, 14:29
	> Никакие улушения не помогут когда ФС изначально ущербна архитектурно. В Линуксе вообще > нет нормальных ФС. Как говорится, btrfs преотстойнейшая ФС. Просто все остальные оказывались - еще хуже :)
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	74. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Grand (?), 26-Июл-25, 17:03
	Использую Refs с драйвером Parangon и горя не знаю.
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

33. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
Сообщение от Аноним (33), 26-Июл-25, 13:50
Как там bcache? Еще не выкинули?
Ответить | Правка | Наверх | Cообщить модератору

	43. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 26-Июл-25, 14:30
	> Как там bcache? Еще не выкинули? Пока еще - на месте. А что будет в 6.17 - пока интрига. Что называется, следите за новостями.
	Ответить | Правка | Наверх | Cообщить модератору

44. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
Сообщение от Аноним (44), 26-Июл-25, 14:35
Btrfs дефолтная ФС у Федоры, с версии 33. А это значит, что Btrfs станет дефолтной и в RHEL.
Ответить | Правка | Наверх | Cообщить модератору

	48. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (33), 26-Июл-25, 15:00
	В шапке btrfs уже была в preview, но убрали в пользу XFS. Видимо, они что-то знали.
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (44), 26-Июл-25, 15:43
	Была, 10 лет назад. Сейчас многое поменялось.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Повышение производительности Btrfs в ядре Linux 6.17"	–1 +/–
	Сообщение от Аноним (-), 26-Июл-25, 16:18
	> В шапке btrfs уже была в preview, но убрали в пользу XFS. А заодно убрали у себя и всех блочно-файлушников - все известные имена из RHBM таки свалили. И скучковались - вот - вокруг btrfs'а почему-то. Видимо непотребства с сратисом и попытка гальванизации древнего дизайна с потугами сделать из пенсионера чемпиона-олимпийца им как-то не того. Чексумы и рефлинки даже кой-как прикрутили, вроде бы, но я так и не понял - можно ли это уже юзать, или оно как всегда wip и экспериментальное у них. Но даже нубоватый майнтайнер с горящими глазами - в процессе успел задолбаться с легасипроблем этого антика в край - и сбежал, тоже к btrfs'никам вроде. > Видимо, они что-то знали. Ага, как что-нибудь еще профачить. Например блочно-файлушное направление у себя. У IBM славные традиции факапов и пролетов, еще с полуоси аж :)
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	53. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (6), 26-Июл-25, 15:12
	Проверяют на сколько хомики согласны кушать отбросы. Скорее всего не готовы.
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	73. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 26-Июл-25, 16:44
	> Проверяют на сколько хомики согласны кушать отбросы. Скорее всего не готовы. Остальные вообще предложили на выбор покушать песок, гравий и пенопласт.
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от ptr (ok), 26-Июл-25, 18:27
	Судя по текущим бенчмаркам, это вряд ли https://www.phoronix.com/review/linux-611-filesystems/3 Пока что XFS для типичной серверной нагрузки (СУБД) выглядит предпочтительней.
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

45. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
Сообщение от Аноним (45), 26-Июл-25, 14:45
Btrfs -- это ZFS лайт!
Ответить | Правка | Наверх | Cообщить модератору

	67. Скрыто модератором	+/–
	Сообщение от Аноним (31), 26-Июл-25, 16:22
	Аксиома Эскобара (с).
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Повышение производительности Btrfs в ядре Linux 6.17"	–1 +/–
	Сообщение от Аноним (44), 26-Июл-25, 17:16
	>Btrfs -- это ZFS Next! Пофиксил. Не благодари.
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

62. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
Сообщение от Oldi (?), 26-Июл-25, 16:05
Быстрый и мертвый (с)
Ответить | Правка | Наверх | Cообщить модератору

	66. Скрыто модератором	+/–
	Сообщение от Аноним (-), 26-Июл-25, 16:20
	> Быстрый и мертвый (с) "Слухи о моей смерти были сильно преувеличены" (c) Марк Твен.
	Ответить | Правка | Наверх | Cообщить модератору

70. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
Сообщение от Аноним (70), 26-Июл-25, 16:26
Забавно, когда промышленную ФС для серверов используют хомячки.
Ответить | Правка | Наверх | Cообщить модератору

	71. "Повышение производительности Btrfs в ядре Linux 6.17"	–1 +/–
	Сообщение от Аноним (31), 26-Июл-25, 16:38
	Ты про НТФС?
	Ответить | Правка | Наверх | Cообщить модератору

	78. Скрыто модератором	+/–
	Сообщение от Аноним (-), 26-Июл-25, 17:20
	Хорошая шутка, мне понравилось.
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Повышение производительности Btrfs в ядре Linux 6.17"	–1 +/–
	Сообщение от Аноним (-), 26-Июл-25, 16:41
	> Забавно, когда промышленную ФС для серверов используют хомячки. Она в отличие от монстров типа ZFS - универсальная. Ресурсов много не жрет, даже роутер с 64 мег оперативы диск с ней на раз цепляет. А на десктопной системе снапшотик перед крупным апгрейтом сделать, на случай если что пойдет не так - как раз очень удобно.
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема