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

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

Сообщения

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

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

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

	140. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Фофан (?), 27-Июл-25, 11:21
	Дважды терял данные на btrfs. Второй раз, правда, из-за убитого модуля оперативки, однако, обидно что повреждённый были файлы, к которым и не обращался даже никто, они просто лежали на дисках. Ещё очень долго машина стартует когда диски в btrfs собраны - до двух минут, при этом, минуты полторы ожидания пока btrfs примонтируется. Перешёл в итоге на lvm - старт машины секунд 30 вместе с дисками.
	Ответить | Правка | Наверх | Cообщить модератору

	141. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (141), 27-Июл-25, 11:41
	Так lvm вроде бы не файловая система!??
	Ответить | Правка | Наверх | Cообщить модератору

	143. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Фофан (?), 27-Июл-25, 11:55
	Ну для уточнения lvm + ext4. Средствами btrfs из нескольких дисков собирались тома часть с избыточностью часть просто - jbod
	Ответить | Правка | Наверх | Cообщить модератору

	169. "Повышение производительности Btrfs в ядре Linux 6.17"	–1 +/–
	Сообщение от Аноним (-), 27-Июл-25, 16:03
	> Ну для уточнения lvm + ext4. Средствами btrfs из нескольких дисков собирались > тома часть с избыточностью часть просто - jbod У этой шляпы управление просто на голову хуже чем у сабжа. И не надо про потери файлов тут, если вы jbod делаете - вам точно похрен на ваши данные.
	Ответить | Правка | Наверх | Cообщить модератору

	185. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Фофан (?), 27-Июл-25, 18:31
	Ну как это не надо про потери? Потеря файлов есть - это факт. Даже если мне трижды похрен на мои файлы факта потери это не отменяет. Ну и в том же предложении я написал, что часть томов были с избыточностью (не помню, признаться на каких томах были потери). Так что следуюя Вашей логике (выдернуть из предложения удобный кусок и его опровергнуть) - мне совсем не похрен на данные так как я raid делаю. По поводу удобства - согласен с Вами - удобнее. Это главное свойство ФС? Ну или хотя-бы более важное чем сохранность данных на ней?
	Ответить | Правка | Наверх | Cообщить модератору

	172. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 27-Июл-25, 16:32
	> стартует когда диски в btrfs собраны - до двух минут, при > этом, минуты полторы ожидания пока btrfs примонтируется. С ядра 6.1 его _радикально_ разогнали по скорости монтирования на больших ФС на медленных накопителях. mkfs.btrfs ... -O block-group-tree ... Сие требует ядро 6.1 или новее. Просто новое дерево индекса, для СИЛЬНОГО ускорение монтирования больших ФС. Можно существующую ФС апгрейднуть, в размонтированном виде поюзать на ней btrfstune --convert-to-block-group-tree (требуются btrfs-utils не менее свежие чем ядро 6.1, в дебиане например они в бэкпортах есть). Можно и обратно расконвертить для маунта более старыми ядрами, если надо. Технически это достаточно безопасная операция - создание нового дерева с индексом block groups, чтоб не сканить их при маунте (что и тормозило монтирование на медленных накопителях).
	Ответить | Правка | К родителю #140 | Наверх | Cообщить модератору

	186. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Фофан (?), 27-Июл-25, 18:37
	Спасибо за информацию! Буду иметь ввиду. Если вдруг ещё решусь с ней связаться.
	Ответить | Правка | Наверх | Cообщить модератору

	187. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Минона (ok), 27-Июл-25, 18:38
	О йо! А я то думаю какого х… ext4 на 20 тб монтируется мгновенно, а эта хрень тупит на 4 тб.
	Ответить | Правка | К родителю #172 | Наверх | Cообщить модератору

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

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

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

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

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

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

	133. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (133), 27-Июл-25, 09:22
	Нет, нужно молотком поработать по диску. Если после этого не сломается fs то тогда хорошая. А так ховно
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

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

	111. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 26-Июл-25, 23:46
	> Отключение света не страшно btrfs, если ты сам не отключишь cow, тогда > да могут быть последствия, но тут уж ты ссзб. Тут еще от гунявости накопителя зависит. Совсем похабные SSD с горбатым FTL - могут грубо пролюбить огроменную чушку - мега на 32 - при слете питания. Это в общем то запроектная авария для любой ФС - и там что угодно в принципе бывает. При том с любыми ФС. Если в каком NTFS у вас 32 мега под MFT профакается - вам тоже мало не покажется.
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от penetrator (?), 27-Июл-25, 00:23
	ну про 32 мега ты загнул, обычно пролюбливается 1 блок чтобы столько пролюбить это надо рейд без батарейки, было у меня такое, кеш не зафлашился, побились корни - не спас BTRFS а второй раз глюканула из-за кривых DKMS модулей, намертво завис - только power off, zero log пришлось запустить, все хорошо пашет до сих пор в общем падает она от питания, очень редко, но падает, с другими фс такое не особо замечал, реже, сильно реже NTFS тоже умирал при аппаратных глюках, из-за разогнанного кирпича в частности, но никогда из-за питания
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 27-Июл-25, 01:39
	> ну про 32 мега ты загнул, обычно пролюбливается 1 блок Это размер одного Erase Group. В SSD прицеплено N * чипов NAND, для скорости операций контроллер с ними параллельно работает. Ну а NAND стереть можно - только здоровенным Erase Block по нескольку мегов. Erase Group = N * EraseBlock, и стирание происходит такими юнитами. Оно же и юнит кантования по крупному всяких дел FTL-а. И оно какого-то вот такого размера и может пролюбиться при worst case, если фирмвара накопителя потерю питания нормально не обыгрывает. И да, так в труху может уделаться - что угодно в принципе. > чтобы столько пролюбить это надо рейд без батарейки, было у меня такое, > кеш не зафлашился, побились корни - не спас BTRFS Это всего лишь - обычный SSDшник так может приколоться. Точнее - поганенький, где FTL достаточно индусский. С другой стороны а откуда вы то знаете насколько он похабный у вашего SSD? Косяки даже у жирных энтерпрайз моделей к тому же бывают. > а второй раз глюканула из-за кривых DKMS модулей, намертво завис - Ну вот там мог и RAM побиться. Нвидия таким манерам разнесла юзерам немало файлух. Юзеры EXT4 и XFS сперва вообще не догоняли - почему на них "рояль с неба внезапно упал". > в общем падает она от питания, очень редко, но падает, с другими > фс такое не особо замечал, реже, сильно реже Что-то таков возможно только с очень кривыми накомителями, делающими то что вон там выше. Но на них и другие ФС таки - выносит. Ибо пролюбить чушку в 32 метра или сколько там у кого, под служебными структурами - весьма такое себе. > NTFS тоже умирал при аппаратных глюках, из-за разогнанного кирпича в частности, но > никогда из-за питания Я выуживал данные из нескольких трупиков оного по линии кривой RAM. Подстава в том что "вчера все збс было - а сегодня в бсод комп уносит". Да, и соседний комп с виндой - тоже. У майкрософт такой качественный драйвер что некоторые крахи от кривых метаданных в нем с винтукея до десятки живут ажно.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

	86. "Повышение производительности Btrfs в ядре Linux 6.17"	+1 +/–
	Сообщение от Аноним (-), 26-Июл-25, 19:52
	> Прощаю. У NTFS грубо гигабайт MFT для каждого миллиона файлов или папок, Миллион файлов. Хы-хы. Этот антиквариат от 300К файлов в 1 дире - становится неюзабельным нахрен. А теперь берем сабжа, кладем 300К файлов в диру там. Ну и вот сравниваем side by side у кого там какой перфоманс операций, и вообще.
	Ответить | Правка | Наверх | Cообщить модератору

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

	97. "Повышение производительности Btrfs в ядре Linux 6.17"	–1 +/–
	Сообщение от Аноним (-), 26-Июл-25, 21:45
	https://www.opennet.me/openforum/vsluhforumID3/137435.html#94 Есть такая информвция с Windows, достоверность не проверял: "Для NTFS без включённого сжатия в реальных сценариях получается примерно так: • При последовательной (большой) записи: – Фактически записывается на 10…20 % больше, чем вы отдаёте «на выход» (коэффициент ~1,1–1,2). • При случайной записи мелкими блоками (несколько КБ и меньше): – Дополнительные операции с MFT, журналом, bitmap’ами и т. д. могут дать усиление до 1,5–2,0. Итоговые «усреднённые» цифры для NTFS без сжатия: • Большие файлы (последовательные потоки) → write amplification ≈1,1–1,2 • Мелкие файлы или случайный I/O → write amplification ≈1,3–1,7 • В пиковых, крайне фрагментированных сценариях или при очень мелком I/O рост может достигать ≈2,0"
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	99. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 26-Июл-25, 22:29
	"В NTFS сжатие касается только потока данных самого файла (Data-составляющей). Вся служебная «обвязка» — MFT-записи, журнал транзакций (USN-журнал), битмапы свободных кластеров, индексы каталогов и пр. — остаётся несжатой" C включённым в BTRFS сжатием "по умолчанию в Btrfs поведение очень похоже. • «compress=…» (lzo/zstd/zlib) на монтировании влияет только на данные (Data-chunk-­и). • Метаданные (B-деревья, extent-записи, bitmaps и т. п.) по умолчанию не сжимаются и пишутся «как есть». Если вы пропишете в /etc/fstab или в команде mount опцию compress=zstd:1 — это затронет только потоки пользовательских данных. Метаданные будут занимать столько же места, сколько и без сжатия. Важно: в ядре есть экспериментальная опция compress-metadata, которая пытается сжимать часть метаданных, но она считается нестабильной и в большинстве дистрибутивов по умолчанию не включена. На практике:     Подавляющее большинство «обычных» метаданных Btrfs не сжимается.     Сжатие «Data» уменьшит лишь объём пользовательских данных, но не снимет оверхед на COW-алокацию метаданных и чанков"
	Ответить | Правка | Наверх | Cообщить модератору

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

	145. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 27-Июл-25, 12:17
	> https://www.opennet.me/openforum/vsluhforumID3/137435.html#94 > Есть такая информвция с Windows, достоверность не проверял: > "Для NTFS без включённого сжатия в реальных сценариях получается примерно так: Ну вот и гуляй отсюда с своим спамом тогда. Развел стен текста - с бесполезняком непроверенным, фиг знает зачем. Спамер долбаный. Не разбираешься в топике - иди своей дорогой лучше, в топик в котором разбираешься.
	Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

	17. "Повышение производительности Btrfs в ядре Linux 6.17"	+3 +/–
	Сообщение от 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ообщить модератору

	106. "Повышение производительности Btrfs в ядре Linux 6.17"	+1 +/–
	Сообщение от НяшМяш (ok), 26-Июл-25, 23:21
	Какой маленький раздел, милота =) ❯ btrfs filesystem df /               Data, single: total=469.01GiB, used=413.49GiB System, DUP: total=64.00MiB, used=80.00KiB Metadata, DUP: total=7.00GiB, used=4.14GiB GlobalReserve, single: total=512.00MiB, used=0.00B ❯ btrfs filesystem df /media/shmurdyak Data, single: total=1.63TiB, used=1.35TiB System, DUP: total=64.00MiB, used=272.00KiB Metadata, DUP: total=5.00GiB, used=2.25GiB GlobalReserve, single: total=512.00MiB, used=0.00B Короче, понты оно жрёт на самом деле.
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Fracta1L (ok), 27-Июл-25, 08:41
	Я прост не вижу смысла использовать Btrfs для файлопомоек. Сжатие там почти бесполезно, снапшоты данных мне не нужны, RAID я тоже не использую. Поэтому там традиционные ext4 и XFS, а Btrfs у меня для системы :) Судя по всему, у меня очень большой размер метаданных - видимо, из-за огромного количества мелких файлов.
	Ответить | Правка | Наверх | Cообщить модератору

	171. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 27-Июл-25, 16:22
	> Я прост не вижу смысла использовать Btrfs для файлопомоек. Btrfs device add же, чтоб расширять эту файлопомойку без лишних движений. В отличие от вон того. Где это сложно, криво, канительно и мучительно. А при желании и урезать можно. И девайс заменить. Без долботни - и с кантовкой только реально используемых блоков. > Судя по всему, у меня очень большой размер метаданных - видимо, из-за > огромного количества мелких файлов. По дефолту чанки того или иного типа аллоцируются кусками в гиг. Видимо в какой-то момент у тебя стало более гига метаданных - и отрос второй чанк метаданных на гиг. Если эти крохи тебе принципиальны, размер чанков настраивается. Так что реально у тебя может быть и меньше метаданных. Кентовская штука вообще - относительно мелкими buckets в этом месте орудует, на эн мегов. Лучше ли это? А кто его знает - если возьмут его штуку в оборот и потестят более-менее серьезно - станет понятнее, лучше ли оно вот так было, или "хотели как лучше".
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 26-Июл-25, 21:28
	https://www.opennet.me/openforum/vsluhforumID3/137411.html#264 Включение сжатия в BTRFS уменьшает размер записываемых данных, насколько я не знаю.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	103. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 26-Июл-25, 22:58
	> https://www.opennet.me/openforum/vsluhforumID3/137411.html#264 Включение сжатия > в BTRFS уменьшает размер записываемых данных, насколько я не знаю. Насколько сожмутся - настолько и уменьшает, от данных и алго сжатия зависит. Это ессно похуже чем архиватором - блоки мельче для рандомного доступа, что несколько ухучшает сжатие. Зато распаковка - на лету, прозрачно, незаметно.
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 27-Июл-25, 00:34
	"Нет, к сожалению, дело не в том, что включив сжатие, вы «срежете» весь 3–4 MiB оверхед в 2–4 раза. Сжатие влияет только на объём данных, которые вы помещаете в блоки «Data», но:     Метаданные (B-деревья, extent-записи и т. п.) по-прежнему пишутся целиком в своём размере     Минимальные аллокации пулов (chunk-групп) тоже не «не сожмётся» — они резервируют своё место заранее     DUP-дублирование метаданных остаётся в силе Итого: – Пользовательские 4 KiB при CR=4× превратятся в ~1 KiB «Data», т.е. пишем на диск в 4 раза меньше пользовательских данных – Но сверху «накладные» метаданные и аллокации (скажем, 50–100 KiB при COW-операции + ещё дублирование) никуда не денутся Пример грубых чисел для одной маленькой операции: • Без сжатия: – пользовательских 4 KiB → пишем 4 KiB Data – метаданных COW, B-деревьев и т. д. → ~60 KiB → ~64 KiB реальных записей • С компрессией CR=4×: – пользовательских 4 KiB → пишем ~1 KiB Data – метаданных всё те же ~60 KiB → ~61 KiB реальных записей Получается, что общий write-amplification упал не в 4 раза, а лишь на долю, соответствующую тому, как сильно вы сжали сами данные. При большом CR (текст, логи) экономия на «Data» будет существеннее, но «метаданные + аллокации» всегда будут давать заметный базовый оверхед. Вывод: – Сжатие в Btrfs позволит вам уменьшить объём записываемых пользовательских данных в CR раз, но write-amplification совсем не «умножится» на обратный коэффициент сжатия. – Наоборот, доля неизбежных метаданных при маленьких операциях делает эффект сжатия на общую запись довольно скромным."
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 27-Июл-25, 00:52
	Проверяйте кому надо, я сам не проверял. 3–4 MiB взято отсюда: "Вот почему при записи нескольких KiB вы можете увидеть на диске «отдачу» в мегабайты:     Copy-on-Write.     – Любое изменение (новый файл или модификация уже существующего) требует аллокации новых блоков и записи обновлённых метаданных (B-деревьев, битмапов, extent-записей).     – Даже если вы пишете 4 KiB, под «новые» метаданные выделится целая страница B-дерева (обычно 16–64 KiB), плюс придётся перекопировать (и записать заново) узлы дерева вверх до корня.     Групповая аллокация (block-groups).     – Btrfs резервирует «пулы» под данные и под метаданные: по умолчанию для метаданных это группы по 32 MiB, для данных — по 1 GiB.     – При первом COW-запросе в новом пуле он «открывается», выравнивается по 1–2 MiB и помечается как «занятый», даже если вы в итоге записали только 4 KiB.     Дублирование метаданных (DUP).     – Системные и метаданные (B-деревья) по умолчанию хранятся в режиме DUP, то есть каждый блок пишется дважды в пределах одного устройства для повышения надёжности.     – Это ещё +100% к тому, что уже написано. Суммарно получается: • Metadata CoW (несколько десятков KiB) • Аллокация блока на 1–2 MiB (минимальный «шаг» пулов) • Дублирование (×2) → «Вытекает» примерно 3–4 MiB реальных операций записи на диск даже при чистых 4–8 KiB пользовательских данных"
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 27-Июл-25, 01:54
	> Вывод: > – Сжатие в Btrfs позволит вам уменьшить объём записываемых пользовательских данных > в CR раз, но write-amplification совсем не «умножится» на обратный коэффициент > сжатия. > – Наоборот, доля неизбежных метаданных при маленьких операциях делает эффект сжатия > на общую запись довольно скромным." Я не знаю что это за вода - но реально... 1) Мелкие файлы вообще могут уйти - в metadata. Сразу инлайном. Это быстрее и компактнее. 2) Сжатие кроме всего прочего повышает вероятность что файло уместится in-place. 3) Write amplification - очень зависит от сценария, и в многих сценариях btrfs мало чем хуже остальных, и параметры таковы что паритсья об этом просто незачем. Это может волновать всяких нагруженных БД пишущих кучу мелких блоков, с синхронизацией, но на таком cow делать - вообще "не очень" на уровне идеи. А если у меня прогноз протирания SSD - через 150 лет - да мне и его протирание через 75, в принципе, один хрен, по большому то счету. 4) В зависимости от накопителя скорость чтения может и улучшится - на тормозных накопителях. 5) А места займет - таки меньше. Удобно каким LZO или ZSTD допустим систему компресануть. Бинари раза в 2-3 жмутся, меньше места жрет, в том числе и как снапшоты и проч.
	Ответить | Правка | К родителю #117 | Наверх | Cообщить модератору

	180. Скрыто модератором	+/–
	Сообщение от Аноним (-), 27-Июл-25, 18:03
	Текст прочёл? Прочёл. Свои выводы сделал? Сделал. И я так же.
	Ответить | Правка | Наверх | Cообщить модератору

	181. Скрыто модератором	+/–
	Сообщение от Аноним (-), 27-Июл-25, 18:04
	_ Текст прочёл? Прочёл. Свои выводы сделал? Сделал. И я так же. _
	Ответить | Правка | К родителю #124 | Наверх | Cообщить модератору

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

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

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

	84. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от rm_ (ok), 26-Июл-25, 19:14
	>> Если у вас торренты или виртуалки (короче, файлы с перезаписью частей файла), >> то есть такой момент, там понятно куда, но пока не исправлено. > О чем вы там? В более-менее свежих ядрах там все известные случаи > - устранены. И в целом оно - just works. > Единственное что юзать это лучше с новыми ядрами, хотя-бы 6.x. Оно почти > никогда не регрессует ибо девы трезво оценивают что делают - а > вот известные проблемы и "особенности" чинят довольно активно. Свободное место может утекать при перезаписи частей файла. Долго объяснять, сделай файл размером в 1000 МБ, в середину запиши 100 мег, общее место используемое им с большой вероятностью окажется 1100, или точно больше 1000. Причём увидишь это только по уменьшению свободного на разделе, а никак не по самому файлу.
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 26-Июл-25, 19:59
	> Свободное место может утекать при перезаписи частей файла. Долго объяснять, Нет уж, вот извольте. > сделай файл размером в 1000 МБ, в середину запиши 100 мег, общее место используемое им > с большой вероятностью окажется 1100, С хрена ли? То-есть, если посмотреть вот прям сей момент - может быть и так. Ибо CoW запишет 100 мегов в сторонку (кроме случая когда файл помечен как nocow), а деаллокация случится - не сразу.  Но. Есть такая штука - GC. Он подгребает неиспользуемые блоки. Либо в фоне, либо "когда приперло". И через некоторое время он на отличненько почистит те 100 мегов в середине как свободные. И они будут доступны для использования чем-то еще. > или точно больше 1000. Причём увидишь это только по уменьшению свободного > на разделе, а никак не по самому файлу. В силу логики работы CoW и аллокации в btrfs цифря свободного места - на самом деле достаточно приблизительная. Свободное место на фс вообще - довольно абстрактное понятие. Представляете, можно выжрать все место в файловой системе (почти любой, кроме самых ограниченных) - забив ее файлами нулевого размера. Суммарный размер файлов будет - ноль! Но место куда-то денется. В этом месте мы узнаем о метаданных и что они тоже - место занимают, оказывается.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

	109. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (23), 26-Июл-25, 23:33
	>Много где. В разнообразных сценариях. От флешек до серверов. Ничего, живое. Оно ЖИВОЕ!!! Ж8[ х ] >А вот уверенности в стабильности работы системы - ноль. Может у вас там ядра глючные и рушат все? Я очень понимаю отсутствие у вас уверенности. Уверенность появляется когда сам собираешь ядра под все своё оборудование втч сетевое, серверное и портативное. А когда за тебя ядра убунта собирает, уверенности взяться неоткуда, а это да. Но ты же типа "Я на btrfs билды кернелей гоняю", может намекнёшь, по доброте душевной, как бы так собрать ядро с О2, чтоб оно именно глючило, а не неработало или работало? >Например если в 1 дире дофига файлов - EXT4 весьма отстоен бывает. Btrfs'у же 300К файлов >в 1 дире в разумных пределах похрен. Бэтер в принципе медленнее ext4,  и деградирует по скорости со временем жизни ФС. Я врать не буду, по 300к файлов в один каталог не складываю(голова же не только чтоб в неё есть) по этому могу поверить, что если в каталог ext4 без ума валить файлы, то ext4 по скорости начнёт деградировать до бэтера :) >Его уже в целом миллиард хом фэйсбука оттестил так что многим и не снилось. Хорошо хоть мордакнига тебе докладывает о своих проблемах. :) >За это же гентушников не любят и в багтреках программ - вечно лезут ко всем с уникальными невоспроизводимыми багами. Ты всерьёз полагаешь, что пользователь Генту будет задавать вопросы таким как ты?! Не льсти себе! С уровня Генту, с таким же успехом можно обратиться к гадалке. >Без сообщений об ошибках и конкретных сведений мы говорим ни о чем. С чего ты взял, что я с тобой на эту тему консультируюсь? Конкретно та проблема исправлена примерно в ядре 6.6, но осадочек остался. Я знакомлю людей только со своим опытом, и в отличии от тебя не пытаюсь агитировать, подписывая под себя весь мир. Уверен, что грамотные люди сделают выводы, остальные обречены на повторение ошибок.
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 27-Июл-25, 00:23
	> Оно ЖИВОЕ!!! Ж8[ х ] Дохлые накопители и ФС гораздо хуже как по мне :P > Я очень понимаю отсутствие у вас уверенности. Уверенность появляется когда > сам собираешь ядра под все своё оборудование втч сетевое, серверное и портативное. Внезапно, я именно это и делаю. А еще я знаю что лишь процентов 20 из тех кто ЭТО делает - реально понимают что и нафига они делают. И в ядре есть ряд опций - и взаимодействий - с которыми можно и откушать. Или которые просто плохо протестированы. > А когда за тебя ядра убунта собирает, уверенности взяться неоткуда, Самое плохое что в делах системных есть - это САМОуверенность. И да, через примерно 10 годиков - убунта наконец стала ставить NoHz+Full Dynticks+1000Hz так же как это делал я. Правда у меня нормальный десктопный экспериенс был на 10 лет раньше них, во. Самое стебное что изначальный конфиг базирован на них. > Но ты же типа "Я на btrfs билды кернелей гоняю", может намекнёшь, > по доброте душевной, как бы так собрать ядро с О2, чтоб > оно именно глючило, а не неработало или работало? Я даже могу намекнуть что огребал в сабже баги. На ваше счастье - в RC. И поэтому вы на своем окороке их - не получите. Refactor иногда бывает refucktor'ом. А еще в ядре много опций. Не все комбо и взаимодействия хорошо протестированы. И на этом поле можно обломаться. Я проверял. Чем конфиг дальше от майнстримового, тем вероятнее. > Бэтер в принципе медленнее ext4, А вы создайте 300К файлов в дире EXT4 и мы поговорим об этом еще раз. Особенно если вас такое угораздит на механике. Чтоб еще веселее - оно деаллокацию ЭТОГО не умеет. И даже если вы сотрете это - размер диры будет как с 300К файлами. И тупить будет - пока не сотрешь. Я так по приколу сравнивал side by side, btrfs лучше с 300К в дире в целом. >  и деградирует по скорости со временем жизни ФС. EXT4 вообще-то тоже. Диры, вот, могут - раздуваться, не сдуваться, и тормозить потом. И дефрагер у ext4 не особо эффективный. > Я врать не буду, по 300к файлов в один каталог не складываю А вот попробуй - и расскажи как тебе ЭТО. По моему - "не очень". > (голова же не только чтоб в неё есть) 1) Если ФС будет диктовать структуру данных ограничениями - это плохая ФС. 2) Эту структуру придумал - не я. Я ее лишь менял и перепаковывал. И там было вот так. Заодно стресстестик прикольный. > по этому могу поверить, что если в каталог ext4 без ума валить > файлы, то ext4 по скорости начнёт деградировать до бэтера :) Оно намного хуже бтра при этом себя ведет. > Хорошо хоть мордакнига тебе докладывает о своих проблемах. :) Разработчики btrfs у меня на виду и более-менее честно коммуницируют что и как в их творении, в отличие от фанов [чего угодно]. Честное понимание свойств дизайна - мое все. > Ты всерьёз полагаешь, что пользователь Генту будет задавать вопросы таким как ты?! Я всерьез считаю что у многих гентушников ЧСВ превышает квалификацию и понимание процессов. И просто для понимания - я автор этой новости. > Не льсти себе! С уровня Генту, с таким же успехом можно > обратиться к гадалке. Это вы так свой уровень чтоли описали? Прикольное описание. >>Без сообщений об ошибках и конкретных сведений мы говорим ни о чем. > С чего ты взял, что я с тобой на эту тему консультируюсь? > Конкретно та проблема исправлена примерно в ядре 6.6, но осадочек остался. А та - это какая? Нельзя ли поконкретнее? Я вот прям реально жирных багов - в ядрах 6.x вроде вообще особо не припоминаю. Интересно же что я пропустил. Конечно в сабже тоже чинят странные баги. И даже в EXT4. Но это обычно весьма экзотичные вещи которые при обычной эксплуатации увидеть - малореально. > Я знакомлю людей только со своим опытом, и в отличии от тебя > не пытаюсь агитировать, подписывая под себя весь мир. И при этом даже сообщение об ошибке в качестве пруфа что это не агитация привести не можете? > Уверен, что грамотные люди сделают выводы, остальные обречены на повторение ошибок. Теодор Тсо считается за достаточно грамотного? А то он вообще свой дизайн как-то уже не особо рекомендует - и тоже норовит с авторами сабжа поотвисать. И категорически отвергает идеи типа EXT5, ибо - нахрен надо. Это отработанный материал - а не дизайн фс. Теодор в отличие от фанатов марки - в курсе и честен с нами. А кто такой Тсо - фанаты EXT4 должны бы знать.
	Ответить | Правка | Наверх | Cообщить модератору

	184. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (23), 27-Июл-25, 18:19
	>Дохлые накопители и ФС гораздо хуже как по мне :P Я тоже за все хорошее, и против всего плохого. >А еще я знаю что лишь процентов 20 из тех кто ЭТО делает - реально понимают что и нафига они делают. И в ядре есть ряд опций - и взаимодействий - с которыми можно и откушать. Или которые просто плохо протестированы. Вот, что меня реально вымораживает, так это пропаганда невежества. Как тут, замаскированная в пугалки, что это непостижимые тайные знания, доступные лишь немногим, а в убунте ядра собирают иллюминаты с IQ1000+. От себя скажу: 1)Надо понимать, что не существует живых людей хорошо разбирающихся во ВСЕХ аспектах и драйверах ядра втч этого конечно же нет у Линуса и даже, ОМГ, у человека которому я отвечаю, и у меня тоже. :) Не думаю, что есть люди знакомые и с 50%. Так происходит, по тому, что это ни кому не нужно ибо это не Коран, чтоб учить его наизусть. Ваша задача состоит в постепенном увеличении своего кругозора за счёт драйверов, которые необходимы вашему железу. Для старта вам достаточно скачать архив с исходниками ядра, прочитать про команду make и представлять, как происходит загрузка uefi (надо положить один файлик и правильно его назвать) Все. С большой долей вероятности у вас заработает ядро, собранное в конфигурации "по умолчанию) т.е можно попробовать вообще ничего не знать про железо. Дальше только направленные изменения. Через неделю у вас будет своё ядро для вашего ноутбука. Через год вы будете смеяться в глаза тем, кто говорит вам, что кроме него ещё только процентов 20 понимают, что делают :) >Если ФС будет диктовать структуру данных ограничениями - это плохая ФС. Ну уважаемый Просветлённый ведь поделится с нами не далёкими списком ФС у которых отсутствуют ограничения :) >И при этом даже сообщение об ошибке в качестве пруфа, что это не агитация, привести не можете?   Вот я теперь понимаю, откуда у вас берутся на форумах воображаемые гентушники, якобы флудящие вас странными вопросами. На самом деле, это были не вопросы, а ответы, которые вы пытаетесь провоцировать :) Я вам еще раз говорю -- мне не нужна помощь для анализа ситуации.   ФС с портеджами дала дуба из за комбинации косяка с отыкливанием БЭТЕРА в ситуации включенного сжатия, и недостатка места, а так же постепенного распухания ФС из за которого неспеша, но неуклонно пропадало свободное место. Первый баг вроде поправили.    В прошлый раз я затеял тестирование, когда очередной умник сказал, что ФС готова к продакшену. Ну конечно я не тестил её в продакшене :). Вот если бы я тупанул так, чтоб послушать умника, то я наверное запомнил бы с какими ошибками перестала монтироваться btrfs :) И узнал много нового про структуры ее данных. Но я просто форматнул все в ext4 и занялся более интересными делами, чего и желаю всем собравшимся. >Теодор Тсо считается за достаточно грамотного? Вы уж простите меня, но иконостаса с Теодором, Линусом, и даже, о господи, Вами, у меня нет, лучше учиться, а не молиться. >Я всерьез считаю что у многих гентушников ЧСВ превышает квалификацию и понимание процессов. И просто для понимания - я автор этой новости. А в этой вашей цитате прекрасно всё, ни какие комментарии веселее не будут :)
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

	127. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (127), 27-Июл-25, 03:02
	> CRC к журналу экстренно привинтили Это для journal_async_commit, если не путаю. В остальных случаях она не обязательна. Вот с block_validity непонятно... видимо какой-то скрытый баг ищут до сих пор ;)
	Ответить | Правка | Наверх | Cообщить модератору

	148. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 27-Июл-25, 12:32
	>> CRC к журналу экстренно привинтили > Это для journal_async_commit, если не путаю. В остальных случаях она не обязательна. Много чего не обязательное, но...  народ как-то случайно заметил, по мере роста емкостей и хлипкостей, что SSDшник выгрузивший труху под журнал ведет к полному дестрою фс при попытке реплея журнала. А fsck, если такое удумать, доломает вермишель окончательно. И получается фс которую ни ядро смонтировать не может, ни fsck починить. И на этой почве такая фича как-то довольно экстренно понадобилась. А тут еще нвидия - RAM рушила юзерам. С примрено тем же результирующим механихмом выноса ФС, хоть и по другому поводу. > Вот с block_validity непонятно... видимо какой-то скрытый баг ищут до сих пор ;) Они еще и чексумы метаданных IIRC уже сделали. А этот баг называется - сыпучие сторажи, ибо емкостей и скоростей прибавилось - и все это ценой хлипкости, блин, этого стоража. И если раньше труха в прочитаном была экзотикой - то сейчас это куда меньшая экзотика. Видимо, при конечном BER и его ухучшении, плюс жаба на месот под FEC - иногда, таки, за него пробивает и вылазит наружу.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	119. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 27-Июл-25, 01:11
	> Новость 2023 года? А сейчас какой, не подскажешь? "Существует вероятность повреждения"? > Видимо, эта вероятность была пренебрежимо мала, раз за 2 года не > слышно было громких историй реальных повреждений данных из-за той проблемы. Я вот лично видел юзера с внезапно сдохшим EXT4. И XFS. Такой падеж ФС был загадкой - но потом какой-то btrfs'ник спалил контору: он заметил что ор про checksum error начинается после установки нвидийского драйвера. Так ALL и узнал что подарок от нвидии - выносит RAM нахрен. Это довольно часто ведет к записи трухи в метаданные ФС. С понятным результатом. Вот только с EXT4 юзер будет ничего не подозревать до упора - чексум же нет. А когда оно заметит - fsck том как раз и доломает нахрен, ибо с таким ФС не живут.
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Anonimm (?), 27-Июл-25, 05:49
	Не слышал чтобы ntfs в винде разваливалась сама по себе, унося данные..
	Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

	149. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 27-Июл-25, 12:34
	> Не слышал чтобы ntfs в винде разваливалась сама по себе, унося данные.. Я пару таких откачивал. В смысле - данные вынимал конечно, ибо на ФС при этом живого места уже не было. Всего лишь битый RAM. Проблема в том что оно сидит тихо, юзер не замечает подстав, а потом, внезапно, ХЛОБЫСЬ! "Но ведь еще вчера все работало?!"
	Ответить | Правка | Наверх | Cообщить модератору

	154. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Anonimm (?), 27-Июл-25, 13:20
	> оно сидит тихо, юзер не замечает подстав, а потом, внезапно, ХЛОБЫСЬ! Но винда "почему-то" при каждом подключении сбойного диска предлагает его проверить и исправить - при наличии - ошибки.. Если это для тебя "сидит тихо"..
	Ответить | Правка | Наверх | Cообщить модератору

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

	162. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Anonimm (?), 27-Июл-25, 15:49
	Да, пользователь настолько неумный, чтобы регулярно отклонять проверку диска, а потом удивляться, что файлы не читаются.. 😆 Чего только не придумают в стане 4%..
	Ответить | Правка | Наверх | Cообщить модератору

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

	173. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 27-Июл-25, 16:50
	>> оно сидит тихо, юзер не замечает подстав, а потом, внезапно, ХЛОБЫСЬ! > Но винда "почему-то" при каждом подключении сбойного диска предлагает его проверить Винда - понятия не имеет что в RAM с кешом данные загадились до записи - и ничего ессно не предлагает. И в логах тихо. В чем подстава и состоит. Оно довольно долго может пахать без видимых приколов. Постепенно загаживаясь. Пока одним не очень прекрасным днем - "но ведь вчера отлично все работало?!". А сегодня - например BSOD при попытке маунта, во! И на соседнем компе - тоже :D. Потому что ряд багов ntfs.sys прожили минимум от винтукея до десятки. Может и больше, я не проверял. И тут юзер начинает паниковать - как данные то получить с "проклятого" девайса? :D > и исправить - при наличии - ошибки.. К моменту когда это замечают - там уже может быть труха, и попытка сделать ЭТО может сделать только хуже. ФС в целом не расчитаны на такие подарки - и попытка это "починить" может усугубить ситуацию. > Если это для тебя "сидит тихо".. Реальные кейсы - вытаскивал пару раз хомам с таких чудесатых накопителей их добро. NTFS в FUSE к счастью в бсод улететь чисто технически не способен (юзермод же) да и код там явно качественнее - таки, не крешится на кривых метаданных.
	Ответить | Правка | К родителю #154 | Наверх | Cообщить модератору

	182. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Anonimm (?), 27-Июл-25, 18:05
	> Потому что ряд багов ntfs.sys прожили минимум от винтукея до десятки. Форматировал диск в Linux Mint с ядром 6.1.x, затем подключил его к Ubuntu 20.04.6, в которой ядро версии 5.15.xx. Так вот - убунта не смогла его даже смонтировать, пришлось заново форматировать, но уже в поделии космонавта. Это и есть та самая надёжность ext4, о которой тут все поют? То есть финский автор с товарищами от версии к версии вносят изменения, после которых система элементарно не работает с другими ядрами, но заметили вы это только в отношении Microsoft? Кстати, они (насколько я помню) если и вносили изменения в файловую систему, то она работает от XP до 11..
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Anonimm (?), 27-Июл-25, 09:29
	А тебе по 1 каналу должны были об этом сказать? Реддит пестрит сообщениями, что в ядре 6.1.xx ext4 разваливается сама по себе, унося данные. Баг исправили, но факт остаётся фактом.. Кстати, там же написано, что принятый в ядро драйвер ntfs3 так же поступает с ntfs, но "это другое", верно?
	Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

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

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

	126. "Повышение производительности Btrfs в ядре Linux 6.17"	+1 +/–
	Сообщение от Аноним (127), 27-Июл-25, 02:40
	Это не проблема ФС. Это отсутствие fsync в приложениях. У sqlite/mysql/postgres часто базы в нечитабельном состоянии остаются? Без аппаратных ошибок в дисках такое прям редкость. Сами всё штатно находят, откатывают и т.д. и даже в режиме data=writeback. data=journal автоматически тоже не поможет держать файл всегда в адекватном состоянии: в процессе твоих изменений бахнул глобальный sync по таймеру и файло оказалось ни туда ни сюда (допустим, заголовок TLV вначале файла ты поправил, а данные в файл ещё не записал, или записал не все). ФС тут ни при чём на самом деле.
	Ответить | Правка | Наверх | Cообщить модератору

	150. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 27-Июл-25, 12:55
	> Это не проблема ФС. Да неужели? > Это отсутствие fsync в приложениях. Вообще-то классика без журналинга данных - не может в транзакционную семантику полноценно, ибо не имеет данных для отката или завершения незавершенной транзакции. Поэтому если запись срубилась на середине - никакой fsync точно не поможет. У EXT4 нет инфо для undo - в том смысле что он нигде не сохранял старые данные. Можно включить полный журнал, и тогда запланированная запись уйдет сперва в журнал, а при успехе этого в основную область. Но если это сделать - мы тогда встретимся еще раз и поговорим, у кого там перфоманс, а кто улитка. Ибо это ДВУКРАТНАЯ запись. Сперва в журнал, потом в основной регион. От этого помогает лишь 1) Фортели с переименованием файлов и временными файлами если они мелкие. 2) Своя подсистема журналирования (!!!) если это не оно, как у БД. CoW в этом смысле - нахальный чит. Он избегает ДВЕ записи, потому что с логической точки зрения вся область ФС это один большой журнал. Это немного неточное описание, у идеи есть субдиалекты, наиболее лобовые реализации даже называют log-structured. И это ключаевая причина по которым CoW считают next gen. Семантика полного журнала - без двойной записи. Вот только это не халявный маневр. Как вы уже заметили, если вся ФС журнал - окей, но место постепенно закончится?! В этом месте возникает нужда в GC, который будет подгребать неактуальные записи и все такое. Это довольно сложная логика с своими закидонами. И все же избежание двойной записи при свойствах сравнимых с полным журналом - повод с этим возиться. > У sqlite/mysql/postgres часто базы в нечитабельном состоянии остаются? Они все просто заимплементили свой журналинг. По вон тем причинам. Это довольно сложное и грабельное начинание, если вы не знали. Но для большей части апликух это слишком сложно и можно на раз получить файло в интересном состоянии когда половина новая а половина старая. Как вы думаете, откроется PNG если голова новая, а хвост старый? Ну вот срубилась запись на середине. Правильно - будет decompression error и отобразится только половину картинки или нифига. Аналогично - почти все остальное. > Без аппаратных ошибок в дисках такое прям редкость. Вы имхо не видели 1) Какие костыли для этого в софт вообще вбивают. 2) Просто не знали что искать. А теперь если вдруг попадется полуотображающаяся картинка или странный документ который как живой, но не открывается - будете знать 1 из механизмов этого. > Сами всё штатно находят, откатывают и т.д. и даже в режиме data=writeback. При журнале только метаданных - оно только изменения аллокации может откатить. Но старые данные нигде не сохраняются - данных для отката просто нет. Можно включить полное журналирвоание, тогда перезапись станет атомарной - сначала в журнал, потом на диск, только если прокатило - и тогда если запись срубилась на середине, окей, в журнале была полная копия намерений чтобы попытаться еще раз и довести запись до конца. Вот только это ДВЕ записи. И вам не понравится как это у EXT4 работает. Потому что с полным журналом EXT4 довольно печален. А без - он никак не защищает от срубания записи на середине и нечитаемости файла в результате. > data=journal автоматически тоже не поможет держать файл всегда в адекватном состоянии: > в процессе твоих изменений бахнул глобальный sync по таймеру и файло > оказалось ни туда ни сюда (допустим, заголовок TLV вначале файла ты > поправил, а данные в файл ещё не записал, или записал не > все). ФС тут ни при чём на самом деле. Тупняк апликушников - это сильно отдельный вопрос. Но вон то - актуально даже если апликушник все делает правильно. Т.е. мы задумали нечто типа write(100500) -> picture.png fsync() Но реально записалось лишь 50 000 от write и случился крах. И теперь на диске picture.png где первые 50 000 это новые данные, остальное - старые, а при потуге чтения - decode error на 50 000. Журнал метаданных - обеспечит корректный трек аллокации файла, но ничего не говорит о состоянии данных при крахе. Сюрприз! И чтобы что-то с этим сделать - надо эвон какую логику развести - либо с своей подсистемой журналинга (!!) либо с хитрым трюком с записью нового файла в сторону, unlink старого и rename нового в старый. Т.е. этакий косплей идей cow в каком-то роде. Вот только при этом половину логики журнала ФС ворочает - приложуха. Большей части авторов оных такое счсастье понятно насколько надо.
	Ответить | Правка | Наверх | Cообщить модератору

	191. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (191), 27-Июл-25, 19:02
	Ну всё верно, только offtopic получается ;) > Вообще-то классика без журналинга данных - не может в транзакционную семантику полноценно, ибо не имеет данных для отката или завершения незавершенной транзакции. Да, api для работы с ФС он такой. Было бы красиво startTransaction/commit/rollback на уровне ФС, но можно в скорости сильно потерять - получить ФС со скоростью СУБД. Что уже ненужно. Хотел другое подчеркнуть - то что называют "багами ФС" багами-то и не являются чаще всего! По субъективному ощущёнию (можешь сместить проценты, но у меня примерно такой опыт) всё что называют багами ФС надо делить примерно так: - 50% - это отсутствие вообще sync/fsync. И как бы какие тут претензии к ФС, если не сказали "помести данные на диск, они важные, я подожду"? - 20% - это отсутствие правильной последовательности open/write/fsync/rename/unlink и т.д. Это в основном проблемы приложений, или немного не поняли друг друга разработчики ФС и приложений (разные гарантии предоставили, или на разные гарантии полагались). Это обычно тоже не баги в ФС, а баги в приложениях (может быть из-за кривоватого описания ФС/опций ФС). - 20% - это баги именно в реализации ФС. Вот мы как бы про эти случаи... - 10% - это баги в подсистеме ввода/вывода (записи/чтения секторов) и аппаратные проблемы (или особенности работы) в дисках/RAID-массивых и т.д. Вот последняя часть тоже интересная. Типа жесткий диск/SSD/RAID-массив без каких-то дополнительных аккумуляторов/ионисторов/конденсаторов физически не успеет записать данные корректно при потере питания. Или со временем возникнет ошибка чтения. И вот как с этим жить? Ну как бы тоже не проблема в реализации ФС, а скорее оценка устойчивости ФС в целом к неустранимым внешним ошибкам в важных служебных областях. Соберётся ФС сама после такого, или уже не спасти? Не очень много ФС вообще какие-то гарантии дают в таких случаях. А может быть гарантии и не нужны, просто бекапиться надо почаще ;)
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	136. "Повышение производительности Btrfs в ядре Linux 6.17"	+1 +/–
	Сообщение от Anonimm (?), 27-Июл-25, 09:31
	А где-то почитать можно как ntfs "сыпется" сама по себе?
	Ответить | Правка | Наверх | Cообщить модератору

	138. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (49), 27-Июл-25, 09:57
	Полуркай описания хотфиксов и там по номерам поищи, была небольшая драма каждый раз. Начиная с восьмёрки штук 10 только я видел, несколько раз лично столкнулся. Всё, что было до, можно не рассматривать. По моему, у них традиция пару раз в год исправлять баги, разваливающие нтфс. Явно сыпется она когда венда попытается восстановить повреждения, а так может оставаться незамеченным. И там не что-то сложное или редкое. Например, несколько лет назад было, что, если включено сжатие и кончилось место -- то давай, до свидания MFT.
	Ответить | Правка | Наверх | Cообщить модератору

	155. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Anonimm (?), 27-Июл-25, 13:24
	> Полуркай Так и запишем - доказательств словам нет..
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (49), 27-Июл-25, 13:37
	Я привёл 1 нашумевший случай из относительно недавних, мне это не интересно. Это общеизвестная информация, для всех, кто хотя бы краем касался этого вопроса.
	Ответить | Правка | Наверх | Cообщить модератору

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

	170. Скрыто модератором	+/–
	Сообщение от Аноним (49), 27-Июл-25, 16:20
	Не верь, только твоя проблема. Мой опыт говорит мне, что тут всегда просто, всё, что ты слышишь об ужасах венды в интернетах, всегда правда. Нет исключений. Если ты достаточно усидчивый, в лучшем случае, ты найдёшь упоминания и, возможно, даже ссылки на хотфиксы. Се ля ви, такова природа проприетарных систем. Но это тут момент, ты начнёшь это искать, только чтобы убедиться, что святую венду оболгали напрасно, а значит, уже будешь неправильно мотивирован. Вот описания хотфиксов читай почаще, хотя в них часто лгут и не упоминают весь размах исправлений.
	Ответить | Правка | Наверх | Cообщить модератору

	151. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 27-Июл-25, 13:09
	> А где-то почитать можно как ntfs "сыпется" сама по себе? Например: в свое время у MS был чудный KB на тему хотфикса с полным разрушением фс вообще. Unrecoverable - в том смысле что до монтируемого состояния оно уже не чинится. Когда диски стали более 2 терабайт - майкрософта посетил враппинг. И когда начиналась запись за 2 терабайта - она просто врапалась в начало диска. А там всякие ништяки типа MFT. Вы наверное понимаете насколько круто чинить NTFS у которого MFT отпправился в страну вечной охоты :)) Сначала энтерпрайзнички кряхтели-скрипели что у них что-то файлухи иногда аннигилируют, но никто не знал что за фигня. А потом - когда диски более 2Тб пошли в массы - тут уже понятене стало и чудный баг наконец починили.
	Ответить | Правка | К родителю #136 | Наверх | Cообщить модератору

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

	174. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 27-Июл-25, 17:05
	> И ссылка на этот баг есть или как всегда на этом форуме - "ищи сам"? Таки да. Вперлось мне древние MS KB трекать. Я виндами уже лет 10 как не занимаюсь. Но могу пообещать что если вы вобьете в поискарь что-то типа NTFS Filesystem corruption - найдете и много новых интересных вещей, о части которых я даже не знал. Например - какой-то карапт данных Win2016 если на нем дедупликацию данных удумать. Хи-хи, повторили подвиг RHBM на XFS походу. Представляете, в винде тоже бывают баги и вулны. Что бы там майкрософтский маркетинг не вещал.
	Ответить | Правка | Наверх | Cообщить модератору

	183. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Anonimm (?), 27-Июл-25, 18:07
	Ещё один сказочник.. 😆 Не удивлён..
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

	164. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Anonimm (?), 27-Июл-25, 15:54
	Да хоть 2123 года. Файловая система разваливалась сама по себе, без участия пользователя и отключения электропитания, юзеры остались без данных и только здесь - "а чё таково?"..
	Ответить | Правка | Наверх | Cообщить модератору

	179. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (112), 27-Июл-25, 17:57
	В новости нет ничего про "разваливание файловой системы". Там лишь про "вероятность повреждения". Насколько большая вероятность, насколько сильного повреждения? Об этом информации нет. А это как раз и важно. Так-то всегда есть ненулевая "вероятность повреждения" по причине железных проблем. Но если эта вероятность пренебрежимо мала - на возможную проблему просто забивают. Так и здесь.
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от НяшМяш (ok), 26-Июл-25, 23:24
	> Уже два раза ломалась на рабочей станции, первый раз после обновления ядра, второй после отключения света И ведь до сих пор попадаются люди, которые для !рабочей станции! не могут даже бесперебойник купить.
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	114. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (112), 27-Июл-25, 00:13
	А можешь посоветовать хороший бесперебойник? Чтобы работал хорошо, и не сильно дорогой. Я вот недавно пробовал купить. И судя по отзывам, они все проблемные. В числе проблем, на которые жалуются люди: - ИБП просто не выполняет свою функцию, то есть сразу же отключается сам, когда отключается свет. И это модели за 80 евро. - При длительном отключении света и полной разрядке батареи - не включается сам, когда свет таки подают вновь. - Сильно воняет, при чём долго, не только первую неделю. - Мощные модели шумят и греются, даже если есть свет. Маломощных моделей не хватает на современный ПК + монитор. - Неприятно пикает раз в несколько минут, при работающей розетке, и это невозможно отключить. - Если ночью отключается свет - орёт так, что будит всех домочадцев, даже если ПК, подключенный через ИБП, выключен. - Даже у дорогих моделей за 200 евро через 2 года сдыхает батарея.
	Ответить | Правка | Наверх | 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"	+/–
	Сообщение от Аноним (-), 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"	+2 +/–
	Сообщение от Аноним (-), 26-Июл-25, 16:44
	> Проверяют на сколько хомики согласны кушать отбросы. Скорее всего не готовы. Остальные вообще предложили на выбор покушать песок, гравий и пенопласт.
	Ответить | Правка | Наверх | Cообщить модератору

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

	120. "Повышение производительности Btrfs в ядре Linux 6.17"	–2 +/–
	Сообщение от Аноним (-), 27-Июл-25, 01:15
	> Надо было использовать ext4. Да сами свой пенопласт не умеющий в деаллокацию дир и педальный как черти что жрите. В btrfs можно - подоткнуть энный диск -> btrfs device add -> +N места. С EXT4 так расширить себе место для хранения? Ну не то что совсем невозможно - но вы врядли захотите связываться с этим. А уж чтобы снапшот ос до апгрейда забахать на случай если результат не понравится - опять же, аналогично. Только еще поганее.
	Ответить | Правка | Наверх | Cообщить модератору

	142. "Повышение производительности Btrfs в ядре Linux 6.17"	–1 +/–
	Сообщение от Аноним (49), 27-Июл-25, 11:42
	Да ну, ерунда. Лет 20 никто голую ext4 не использует и поверх lvm перечисленное не проблема.
	Ответить | Правка | Наверх | Cообщить модератору

	152. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 27-Июл-25, 13:12
	> Да ну, ерунда. Лет 20 никто голую ext4 не использует и поверх > lvm перечисленное не проблема. Еще не хватало мне с этой фанерной этажеркой отношаться, вместо btrfs device add.
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (49), 27-Июл-25, 13:34
	> Еще не хватало мне с этой фанерной этажеркой отношаться, вместо btrfs device > add. А что оно делает под капотом? Потому что с lvm ты управляешь происходящим и тут не особо. Буквально пара команд, чтобы добавить диск в том, и 1 ресайзнуть фс. Так сложно.
	Ответить | Правка | Наверх | Cообщить модератору

	175. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 27-Июл-25, 17:13
	> А что оно делает под капотом? Просто добавляет девайс который этой ФС можно юзать, и аллоцировать на нем место в пул известных. По мере желания файлуха начнет аллоцировать там место. Это желание можно простимулировать, пнув rebalance для балансировки нагрузки по накопителям, добавление нового - типовой повод ребаланс сделать (остальные поводы для ребаланса в общем то или экзотика, или конверсия профайла данных/метаданных/etc в другую схему избыточности и проч). > Потому что с lvm ты управляешь происходящим и тут не особо. В случае lvm это довольно сыкотная этажерка. Где возможна потеря ошибок или неадекватная реакция на отклонения от идеала при взаимодействиями между уровнями. Допустим на RAID1 у меня 2 копии. При чтении - csum error. Что btrfs делает? Суется на другой девайс, берет исправную копию. И чинит битую. Сам. А у той сыкотной этажерки вообще так сразу нет сведений - какая копия из RAID правильная. Собрать такое комбо из LVM... ну... можете попытаться, конечно. Если не спятите раньше. А там - пара команд буквально и дальше оно само. > Буквально пара команд, чтобы добавить диск в том, и 1 ресайзнуть фс. Так сложно. В btrfs это проще, быстрее и намного логичнее. И - при отклонениях от идеала оно по крайней мере знает где факап. Это не прячется между наслоениями уровней абстракций глотающих ошибки. Так что EXT4 вообще в душе не ... какая из копий RAID верная. И остальные - тоже. А btrfs мало того что в курсе какая копия корректна так еще и сам починит факап.
	Ответить | Правка | Наверх | Cообщить модератору

	178. Скрыто модератором	+/–
	Сообщение от Аноним (49), 27-Июл-25, 17:39
	А потому что софтрейд совершенно не модно. Кому оно надо? А без него всё замечательно, это просто не заботы ext4.
	Ответить | Правка | Наверх | Cообщить модератору

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

	122. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 27-Июл-25, 01:19
	> Судя по текущим бенчмаркам, это вряд ли > https://www.phoronix.com/review/linux-611-filesystems/3 > Пока что XFS для типичной серверной нагрузки (СУБД) выглядит предпочтительней. Ну вот под именно нагруженные базы данных CoW (по крайней мере без nocow) может и правда быть не лучшим выбором. Но это лишь 1 из кейсов, довольно нишевой.
	Ответить | Правка | Наверх | Cообщить модератору

	134. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от ptr (ok), 27-Июл-25, 09:28
	Интересно, а какую серверную нагрузку Вы считаете не нишевой? Я тут наоборот, у клиентов вижу среди серверов только один на десяток не сервер баз данных. Но на таких серверах, обычно, и нагрузка на файловую систему околонулевая.
	Ответить | Правка | Наверх | Cообщить модератору

	153. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 27-Июл-25, 13:20
	> Интересно, а какую серверную нагрузку Вы считаете не нишевой? Вебсервак, сервак с файлами/даунлоадами, аппсервак. Совершенно не обязан быть сильно прогруженым именно по базе и фс. > Я тут наоборот, у клиентов вижу среди серверов только один на десяток не сервер > баз данных. Это вероятно сильно зависит от клиентуры, и вообще. Вон та ремарка была про именно случай когда БД чуть не центр вселенной и - нагруженная. Тогда cow лучше на этом не делать. Ибо куча выносков cow ака фрагментов и ср@ч метаданными - такое себе. Большая часть БД делано под семантику in-place апдейта файла в ФС. У btrfs на этот случай флаг nocow есть. Плюшки, конечно, отваливаются - зато БД получает семантику которую хотела и подразумевала. > Но на таких серверах, обычно, и нагрузка на файловую систему околонулевая. Если околонулевая то можно и CoW с некоторыми оговорками. Но лучше понимать вон тот момент.
	Ответить | Правка | Наверх | Cообщить модератору

	160. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от ptr (ok), 27-Июл-25, 15:22
	>> Интересно, а какую серверную нагрузку Вы считаете не нишевой? > Вебсервак Вообще-то nginx и серверу приложений файловая система вообще безразлична, а про СУБД я уже указал выше. Или Вы о чем? > сервак с файлами/даунлоадами У S3 профиль нагрузки на файловую систему такой же, как у СУБД > аппсервак Добававьте оперативки и к диску он почти перестанет обращаться. > Совершенно не обязан быть сильно прогруженым именно по базе и фс. При низкой нагрузке на диск вид файловой системы становится безразличен. А про высокую мы уже договорились. > Это вероятно сильно зависит от клиентуры, и вообще. Ради интереса пересмотрел спискок серверов своих проектов у Россетей, Еврохим, СУЭК, РАО ЕС Восток, МОЭК, НТК - везде одна и та же картина. Или это сервер СУБД (Kafka подобна СУБД по профилю нагрузки на диск), или нагрузка на диск околонулевая, как, например, на хостах k8s. О какой клиентуре Вы речь ведете? О pet-проектах, доходы с которых у Red Hat занимают меньше 1%? > Это вероятно сильно зависит от клиентуры, и вообще. Вон та ремарка была > про именно случай когда БД чуть не центр вселенной и - > нагруженная. Серверные приложения без СУБД, которые при этом предъявляют какие-то специфичные требования к файловой системе - большая редкость. >> Но на таких серверах, обычно, и нагрузка на файловую систему околонулевая. > Если околонулевая то можно и CoW с некоторыми оговорками. Но лучше понимать > вон тот момент. Зачем? Чтобы админам было чем заняться, если профиль нагрузки на файловую систему изменится? ))) Я могу еще понять, зачем btrfs на сервере при прототипировании. Но на продуктивном сервере потребность в нем вижу только в очень редких случаях.
	Ответить | Правка | Наверх | Cообщить модератору

	176. Скрыто модератором	+/–
	Сообщение от Аноним (-), 27-Июл-25, 17:28
	> Вообще-то nginx и серверу приложений файловая система вообще безразлична, Ну как безразлична. Ее перфоманс таки влияет. И удобство администрирования - тоже. Скажем добавить девайсов на ходу и расширить место нонстоп - достаточно прикольно бывает. > а про СУБД я уже указал выше. Или Вы о чем? Ну вот о том. Если субд нагруженный и центр вселенной - на сабж его разве что с nocow атрибутами класть. Но тогда СУБД и плюшек cow, чексум и проч - не получит. Подразумевается что она тогда - сама это все, раз уж она фс косплеить хочет. >> сервак с файлами/даунлоадами > У S3 профиль нагрузки на файловую систему такой же, как у СУБД А зачем S3 для какого-нибудь CDN-like применения грубо говоря? >> аппсервак > Добававьте оперативки и к диску он почти перестанет обращаться. Это все 1) не бесплатно и 2) очень зависит от. >> Совершенно не обязан быть сильно прогруженым именно по базе и фс. > При низкой нагрузке на диск вид файловой системы становится безразличен. Кроме того момента что менеджмент btrfs при случае - сильно удобнее вон тех уродцев. Что не безразлично - уже админам :) > А про высокую мы уже договорились. У всех технологий свои особенности есть. Режим nocow в btrfs для файлов - так то - оракл попросил. Понятно для чего. > Ради интереса пересмотрел спискок серверов своих проектов у Россетей, Еврохим, СУЭК, РАО > ЕС Восток, МОЭК, НТК - везде одна и та же картина. > Или это сервер СУБД (Kafka подобна СУБД по профилю нагрузки на > диск), или нагрузка на диск околонулевая, как, например, на хостах k8s. Ну я и не настаиваю что btrfs стоит напихать в каждую дырку. Но. Например чексумы позволят заметить начинающий сбоить хост еще на подлете. И это end to end проверка корректности работы железа как таковая. Для сбоя чексум не важно - проблема чтения накопителя, дурной контроллер, кривой проц или сбоящий RAM. Отлично орет в логи во всех случаях про csum error. > О какой клиентуре Вы речь ведете? > О pet-проектах, доходы с которых у Red Hat занимают меньше 1%? Я без понятия что там у редхата. А вот оракл например btrfs сватает. А фэйсбук на него весьма плотно подсел. И им нравится например early warning по csum по части сбоящих серваков. Так что они и наняли себе кучу народа вокруг. Зюзя опять же. > Серверные приложения без СУБД, которые при этом предъявляют какие-то специфичные требования > к файловой системе - большая редкость. Да обычный кеш статики, господи. Для дурных ФС его приходится костылить в многоуровневое иерархическое нечто, чтоб оно не загибалось совсем. > Зачем? Чтобы админам было чем заняться, если профиль нагрузки на файловую систему изменится? ))) Чтоб этим всем проще рулить было и диагностируемость была. По ору csum error сразу видно что что-то идет не так. > Я могу еще понять, зачем btrfs на сервере при прототипировании. Но на > продуктивном сервере потребность в нем вижу только в очень редких случаях. Ну это вы. А вон те - видят. И в целом - снапшоты удобно, можно всякие вещи типа дифференциальных бэкапов делать send, место добавить - или убавить - легко. И новые девайсы. Ор про сбои в логи опять же за счет чексум. Но конечно прикольнее узнать это когда что-то серьезно факапнется. Если у вас что-то типа google big table оно пофигу, конечно, оно тоже - в self repair умеет. А если нет - упс! В более классических архитектурах - факап сервера отливается.
	Ответить | Правка | Наверх | Cообщить модератору

	189. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Минона (ok), 27-Июл-25, 18:54
	Этот "капитан звездолета" диванный теоретик насмотревшийся конференций типа хайлоад.
	Ответить | Правка | К родителю #160 | Наверх | Cообщить модератору

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

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

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

89. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
Сообщение от Минона (ok), 26-Июл-25, 20:52
RAID 6 починили?
Ответить | Правка | Наверх | Cообщить модератору

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

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

	130. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от 0xdeadbee (-), 27-Июл-25, 08:29
	RAID5 не модно (для дисков более 1 TB). pikabu ru/story/khabr_probivaet_donya_ili_budte_ostorozhnyi_v_koproblogakh__03_12412837
	Ответить | Правка | Наверх | Cообщить модератору

	139. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (49), 27-Июл-25, 11:17
	Это, конечно, чушь, но чем аргументируют выбор raid5 вместо raid6?
	Ответить | Правка | Наверх | Cообщить модератору

	177. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 27-Июл-25, 17:33
	> Это, конечно, чушь, но чем аргументируют выбор raid5 вместо raid6? Вероятно, жабой :). Для RAID6 в 2 раза больше уходит на "бесполезный" parity не добавляющий цифрю в буклет.
	Ответить | Правка | Наверх | Cообщить модератору

	190. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Минона (ok), 27-Июл-25, 18:55
	Оно не умеет ни в какой рейд кроме 0 и 1
	Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

96. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
Сообщение от Аноним (96), 26-Июл-25, 21:44
Кто шарит, какие преимущества? Всю жизнь на ext4, но с этими бтрфс/бкачфс все так носятся, а в чем реальные преимущества то? Или это не для десктопа штуки, а для каких нибудь серверов?
Ответить | Правка | Наверх | Cообщить модератору

	98. "Повышение производительности Btrfs в ядре Linux 6.17"	+1 +/–
	Сообщение от чатжпт (?), 26-Июл-25, 22:17
	В btrfs - подтома, снэпшоты, cow, сжатие. Пользуюсь именно на десктопе, удобно
	Ответить | Правка | Наверх | Cообщить модератору

	108. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от НяшМяш (ok), 26-Июл-25, 23:28
	Поддерживаю эту нейросеть. Тоже всегда сидел на ext4, но потом попробовал btrfs и протащился именно со снапшотов - пару раз спасали (не от помирания системы, а от удаления файлов). Потом уже сильно позже включил сжатие, на 5950Х даже если захотеть не заметишь, зато побольше можно в один диск упихать.
	Ответить | Правка | Наверх | Cообщить модератору

	131. "Повышение производительности Btrfs в ядре Linux 6.17"	–2 +/–
	Сообщение от 0xdeadbee (-), 27-Июл-25, 08:36
	> пару раз спасали (не от помирания системы, а от удаления файлов). не удаляйте файлы - и спасать не придатся. я правильно понял что btrfs в ваших сценариях - аналог "корзины" (recycle.bin) на винде ? > Потом уже сильно позже включил сжатие удаляйте мусор вовремя - и сжатие включать не придется. хехе. кстати, если много (миллионами) создавать мусора и потом много удалять - у людей btrfs пухла и дохла.
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 27-Июл-25, 15:54
	> не удаляйте файлы - и спасать не придатся. Совет вида "не болейте - и не придется пить антибилтики". Не пейте антибиотики. Только не жалуйтесь, померев в свои 35 или сколько там от тривиальной инфекции. > я правильно понял что btrfs в ваших сценариях - аналог "корзины" (recycle.bin) > на винде ? 1) Он намного больше чем это. Еще там например снапшоты системы и проч. В винде есть какой-то эрзац этого, но оно сделано крайне мутно и работает просто капец как тормозно по сравнению с сабжем. Так что использование этой фичи больше напоминает мазохизм. 2) Корзина работает только при явной поддержке ее программами. А если программа просто сотрет файл, через апи - УПС. Никаких корзин в этом случае оказывается нет. А так - и кляча с деревянной телегой, и порш - средства передвижения. Но есть нюансы. >> Потом уже сильно позже включил сжатие > удаляйте мусор вовремя - и сжатие включать не придется. хехе. Белое не одевать, обтягивающее не носить, ... я придумал идею лучше! Не пейте антибиотики лучше при случае, во. Так намного интереснее. > кстати, если много (миллионами) создавать мусора и потом много удалять - у > людей btrfs пухла и дохла. Кстати вы вообще btrfs не пользуетесь чтобы иметь моральное право рассказывать тем кто им пользуется - а как оно. А то что в винде с ФС - это капец и 90 годы прошлого века. И по перфомансу и по фичам. Есть некий ReFS но индусики как-то стушевались сделать аналог ZFS/Btrfs нормально. Даже у Кента более внятно получается (да, я нагло троллю майкрософт).
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Повышение производительности Btrfs в ядре Linux 6.17"	–3 +/–
	Сообщение от th3m3 (ok), 26-Июл-25, 22:35
	Тоже давно на ext4. Считаю так - работает, устраивает? Не трогай!)
	Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

	121. "Повышение производительности Btrfs в ядре Linux 6.17"	+1 +/–
	Сообщение от Аноним (-), 27-Июл-25, 01:17
	> Тоже давно на ext4. Считаю так - работает, устраивает? Не трогай!) В принципе лошади - работали же. И пахать, и почту доставлять, и в другой город съездить... зачем что-то менять, да? :)
	Ответить | Правка | Наверх | Cообщить модератору

	128. "Повышение производительности Btrfs в ядре Linux 6.17"	–1 +/–
	Сообщение от Фрол (?), 27-Июл-25, 03:04
	некоторые и огород лопатой копают. вот дяревня, нет чтоб шагающий экскаватор подогнать и быренько все вскопать.
	Ответить | Правка | Наверх | Cообщить модератору

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

137. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
Сообщение от Аноним (137), 27-Июл-25, 09:51
Лет 5 использую дома самодельный NAS на основе alpine+zfs. Раздаю фс/тома через ksmbd/nvme over tcp. Если добавлю пару дисков и сделаю на них зеркало через btrfs, то что меня должно будет удивить в использовании этой ФС по сравнению с ZFS ?
Ответить | Правка | Наверх | Cообщить модератору

	193. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Минона (ok), 27-Июл-25, 19:31
	> Лет 5 использую дома самодельный NAS на основе alpine+zfs. > Раздаю фс/тома через ksmbd/nvme over tcp. > Если добавлю пару дисков и сделаю на них зеркало через btrfs, > то что меня должно будет удивить в использовании этой ФС > по сравнению с ZFS ? Сравни man btrfs с zpool и zfs.
	Ответить | Правка | Наверх | Cообщить модератору

144. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
Сообщение от Аноним (144), 27-Июл-25, 12:11
Какую ФС лучше использовать для хранения большого числа файлов? например 50 млн, 100 млн? И желательно чтобы при этом сильно не проседала производительность чтения-записи.
Ответить | Правка | Наверх | Cообщить модератору

	147. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (49), 27-Июл-25, 12:29
	> Какую ФС лучше использовать для хранения большого числа файлов? например 50 млн, > 100 млн? И желательно чтобы при этом сильно не проседала производительность > чтения-записи. Классически для таких задач рекомендуют reiserfs, как наиболее эффективную, но её удалили из ядра.
	Ответить | Правка | Наверх | Cообщить модератору

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

	188. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Минона (ok), 27-Июл-25, 18:45
	Ну… фейсбук использует сабж для хранения фоточек и прочего мусора пользователей.
	Ответить | Правка | К родителю #144 | Наверх | Cообщить модератору

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

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

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