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

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

Сообщения

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

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

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

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

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

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

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

	105. "Повышение производительности Btrfs в ядре Linux 6.17"	+2 +/–
	Сообщение от Аноним (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"	+/–
	Сообщение от Аноним (-), 26-Июл-25, 21:45
	https://www.opennet.dev/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. Скрыто модератором	+/–
	Сообщение от Аноним (-), 26-Июл-25, 22:35
	А ZFS? Это вы сами выясняйте как работает ZFS кому надо.
	Ответить | Правка | Наверх | 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"	+/–
	Сообщение от НяшМяш (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ообщить модератору

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

	103. "Повышение производительности Btrfs в ядре Linux 6.17"	+/–
	Сообщение от Аноним (-), 26-Июл-25, 22:58
	> https://www.opennet.dev/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ообщить модератору

	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"	+9 +/–
	Сообщение от Аноним (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"	–3 +/–
	Сообщение от 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ообщить модератору

	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ообщить модератору

	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ообщить модератору

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

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

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

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

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

	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"	+/–
	Сообщение от Аноним (-), 27-Июл-25, 01:15
	> Надо было использовать ext4. Да сами свой пенопласт не умеющий в деаллокацию дир и педальный как черти что жрите. В btrfs можно - подоткнуть энный диск -> btrfs device add -> +N места. С 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ообщить модератору

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"	+1 +/–
	Сообщение от Аноним (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ообщить модератору

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

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

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

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

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

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

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

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

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