forum.opennet.ru - "Повышение производительности Btrfs в ядре Linux 6.17" (64)

"Повышение производительности Btrfs в ядре Linux 6.17"

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

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

Оглавление

Хорошая ФС , Аноним (1), 10:17 , 26-Июл-25, (1)

Хорош пока не потерял данные , Аноним (-), 15:27 , 26-Июл-25, (55) –1
До первого отключения света, Аноним (80), 18:07 , 26-Июл-25, (80) –1

У меня он пережил 1000 целенаправленных дергов питания при тестах Это уже доста, Аноним (-), 19:47 , 26-Июл-25, (85)

Достаточно одного во время важной операции, а не теста, Аноним (80), 20:24 , 26-Июл-25, (88)

Лучшая ФС Использую дома с 2016 года , Шарп (ok), 10:38 , 26-Июл-25, (4) +4

сочувствую btrfs тупо жрёт место непонятно куда, Аноним (9), 11:01 , 26-Июл-25, (9) –4

Примерно 5 под метаданные, какой ужас, Аноним (11), 11:11 , 26-Июл-25, (11) +2

А какие накладные расходы у ext4 или XFS Или, прости Господи, у NTFS , Аноним (13), 11:19 , 26-Июл-25, (13) –1

Это все на самом деле очень зависит от характера использования ФС Но в среднем , Аноним (-), 14:08 , 26-Июл-25, (36) +1
Прощаю У NTFS грубо гигабайт MFT для каждого миллиона файлов или папок, плюс хв, Аноним (-), 17:22 , 26-Июл-25, (79)

Миллион файлов Хы-хы Этот антиквариат от 300К файлов в 1 дире - становится нею, Аноним (-), 19:52 , 26-Июл-25, (86)

Не 5 , меньше btrfs filesystem df Data, single total 39 01GiB, used 32 09GiB, Fracta1L (ok), 11:51 , 26-Июл-25, (17) +3

Если у вас торренты или виртуалки короче, файлы с перезаписью частей файла , то, rm_ (ok), 12:09 , 26-Июл-25, (19) –3

Что пока не исправлено Ваше знание обсуждаемого предмета , Аноним (29), 13:24 , 26-Июл-25, (29)
О чем вы там В более-менее свежих ядрах там все известные случаи - устранены И, Аноним (-), 14:13 , 26-Июл-25, (37) –1

Свободное место может утекать при перезаписи частей файла Долго объяснять, сдел, rm_ (ok), 19:14 , 26-Июл-25, (84)

Нет уж, вот извольте С хрена ли То-есть, если посмотреть вот прям сей момент - , Аноним (-), 19:59 , 26-Июл-25, (87)

Понаделал снапшотов и забыл стереть У н00бов с виртуалками тоже такое бывает , Аноним (-), 14:06 , 26-Июл-25, (35) +2

Просто придут те кто потерял данные из-за сбоев btrfs и тебе наваляют , Аноним (6), 10:57 , 26-Июл-25, (6)

А зачем вы свои комплексы на всех проецируете , Аноним (1), 11:14 , 26-Июл-25, (12) +9

Чтов эти Все не теряли свои данные из за твоих росказней про надежность бэтера, Аноним (23), 12:50 , 26-Июл-25, (23) +2

Я вот юзаю btrfs уже дофига, в куче конфиг - и ничего не потерял А сказочники м, Аноним (-), 14:15 , 26-Июл-25, (38)

Ошибка выжившего Здесь все - 4 истинных линуксоидов - говорят, что ext4 сверхн, Anonimm (?), 14:51 , 26-Июл-25, (46) –3

Ntfs может долго на посыпавшемся диске работать Не очень хорошо, правда Btrfs , Аноним (49), 15:04 , 26-Июл-25, (49)

Только при каждом подключении выдаёт сообщение, что диск надо бы и проверить , Anonimm (?), 15:51 , 26-Июл-25, (60)

При том если на это еще и удумать согласиться - то это как раз его порой и добив, Аноним (-), 16:13 , 26-Июл-25, (64)

Ну да, только он постепенно деградирует а в какой-то момент - хлобысь - не монти, Аноним (-), 16:12 , 26-Июл-25, (63)

И у всего миллиарда юзерей FB - тоже И у кастомеров оракла который эту штуку в , Аноним (-), 15:40 , 26-Июл-25, (57) –1

Не знаю, где ты ее Дофига используешь, но я два раза для теста пробовал ее п, Аноним (23), 15:49 , 26-Июл-25, (59)

Много где В разнообразных сценариях От флешек до серверов Ничего, живое А вот, Аноним (-), 16:04 , 26-Июл-25, (61) –2

Лучшая из имеющегося , Анониссимус (?), 11:22 , 26-Июл-25, (14) –2

Хуже придумать трудно , Аноним (6), 15:08 , 26-Июл-25, (51)

С 2016 года сколько ты данных понерял Только честно , Аноним (-), 15:28 , 26-Июл-25, (56)

Чем фолианты от hugepages отличаются , Аноним (11), 11:09 , 26-Июл-25, (10)

https lwn net Articles 937239 , ананим.orig (?), 12:03 , 26-Июл-25, (18) –1
Вообще совсем другая ипостась Hugepage - страница памяти более чем традиционные , Аноним (-), 14:22 , 26-Июл-25, (39) +1

Почти совсем готова к использованию Уже 8 лет , Аноним (15), 11:33 , 26-Июл-25, (15) +3

Дай угадаю ты фанат иксов , Уникум (?), 15:24 , 26-Июл-25, (54)

А когда данные исчезнут или файлы станут битыми привет, ext4 , разработчики р, Anonimm (?), 12:38 , 26-Июл-25, (20) –1

В ext4 никогда такого не бывает , Аноним (15), 12:48 , 26-Июл-25, (22) +2

Именно поэтому они CRC к журналу экстренно привинтили - а то на кривом железе он, Аноним (-), 14:25 , 26-Июл-25, (40)
Серьёзно https www linux org ru news linux-general 17448413, Anonimm (?), 14:54 , 26-Июл-25, (47)

Ты перепутал с xfs у неё тихие повреждения файлов на диске , ext4 очень надёжна, Аноним (49), 13:08 , 26-Июл-25, (26) +1

У ext4 без полного журнала - файло при обрубившейся на середине записи модет вле, Аноним (-), 14:27 , 26-Июл-25, (41) –1

Уже два раза ломалась на рабочей станции, первый раз после обновления ядра, втор, Аноним (25), 12:56 , 26-Июл-25, (25) +2

Ntfs не менее успешно корёжит и теряет файлы, но главное фрагментация ни в какие, Аноним (49), 13:12 , 26-Июл-25, (27)
Лет 8 на этой фс все устройства Сломалось ровно один раз, когда из raid 1 диск, Fenix (??), 13:19 , 26-Июл-25, (28)

Смотря как часто из розетки дёргать И никаких ntfs3g или более старых версий ве, Аноним (49), 13:46 , 26-Июл-25, (32)
Скрыто модератором, Аноним (6), 15:10 , 26-Июл-25, (52)

Постоянные отключения света были полгода, ни одного падения фс Знаете что я дел, Аноним (75), 17:12 , 26-Июл-25, (75)

Вот тут https www linux org ru news linux-general 17448413 как раз о сверхнад, Anonimm (?), 19:10 , 26-Июл-25, (82)

Как там bcache Еще не выкинули , Аноним (33), 13:50 , 26-Июл-25, (33)

Пока еще - на месте А что будет в 6 17 - пока интрига Что называется, следите , Аноним (-), 14:30 , 26-Июл-25, (43)

Btrfs дефолтная ФС у Федоры, с версии 33 А это значит, что Btrfs станет дефолтн, Аноним (44), 14:35 , 26-Июл-25, (44)

В шапке btrfs уже была в preview, но убрали в пользу XFS Видимо, они что-то зна, Аноним (33), 15:00 , 26-Июл-25, (48)

Была, 10 лет назад Сейчас многое поменялось , Аноним (44), 15:43 , 26-Июл-25, (58)
А заодно убрали у себя и всех блочно-файлушников - все известные имена из RHBM т, Аноним (-), 16:18 , 26-Июл-25, (65) –1

Проверяют на сколько хомики согласны кушать отбросы Скорее всего не готовы , Аноним (6), 15:12 , 26-Июл-25, (53)

Остальные вообще предложили на выбор покушать песок, гравий и пенопласт , Аноним (-), 16:44 , 26-Июл-25, (73)

Судя по текущим бенчмаркам, это вряд лиhttps www phoronix com review linux-611, ptr (ok), 18:27 , 26-Июл-25, (81)

Btrfs -- это ZFS лайт , Аноним (45), 14:45 , 26-Июл-25, (45)

Скрыто модератором, Аноним (67), 16:22 , 26-Июл-25, (67)
Пофиксил Не благодари , Аноним (44), 17:16 , 26-Июл-25, (76) –1

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

1. "Повышение производительности Btrfs в ядре Linux 6.17" +/–

Сообщение от Аноним (1), 26-Июл-25, 10:17

Хорошая ФС

Ответить | Правка | Наверх | Cообщить модератору

55. "Повышение производительности Btrfs в ядре Linux 6.17" –1 +/–

Сообщение от Аноним (-), 26-Июл-25, 15:27

Хорош пока не потерял данные.

Ответить | Правка | Наверх | Cообщить модератору

80. "Повышение производительности Btrfs в ядре Linux 6.17" –1 +/–

Сообщение от Аноним (80), 26-Июл-25, 18:07

До первого отключения света

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

85. "Повышение производительности Btrfs в ядре Linux 6.17" +/–

Сообщение от Аноним (-), 26-Июл-25, 19:47

> До первого отключения света
У меня он пережил 1000 целенаправленных дергов питания при тестах. Это уже достаточно "отключений света", или где?

Ответить | Правка | Наверх | Cообщить модератору

88. "Повышение производительности Btrfs в ядре Linux 6.17" +/–

Сообщение от Аноним (80), 26-Июл-25, 20:24

Достаточно одного во время важной операции, а не теста

Ответить | Правка | Наверх | Cообщить модератору

4. "Повышение производительности Btrfs в ядре Linux 6.17" +4 +/–

Сообщение от Шарп (ok), 26-Июл-25, 10:38

Лучшая ФС. Использую дома с 2016 года.

Ответить | Правка | Наверх | Cообщить модератору

9. "Повышение производительности Btrfs в ядре Linux 6.17" –4 +/–

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

Сообщение от Аноним (13), 26-Июл-25, 11:19

А какие накладные расходы у ext4 или XFS? Или, прости Господи, у NTFS?

Ответить | Правка | Наверх | Cообщить модератору

36. "Повышение производительности Btrfs в ядре Linux 6.17" +1 +/–

Сообщение от Аноним (-), 26-Июл-25, 14:08

>  А какие накладные расходы у ext4 или XFS? Или, прости Господи, у NTFS?
Это все на самом деле очень зависит от характера использования ФС. Но в среднем по больнице разница обычно минимальна. Это не значит что так же будет в всяких эзотеритических случаях, разумеется.

Ответить | Правка | Наверх | Cообщить модератору

79. "Повышение производительности Btrfs в ядре Linux 6.17" +/–

Сообщение от Аноним (-), 26-Июл-25, 17:22

Прощаю. У NTFS грубо гигабайт MFT для каждого миллиона файлов или папок, плюс хвосты/слэк конечно же. USN журнал - по вкусу, кому как, за умолчания не в курсе. При компрессии write amplification жестокий, что для ФС 80-х годов прошлого столетия как бы ожидаемо.

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

86. "Повышение производительности Btrfs в ядре Linux 6.17" +/–

Сообщение от Аноним (-), 26-Июл-25, 19:52

> Прощаю. У NTFS грубо гигабайт MFT для каждого миллиона файлов или папок,
Миллион файлов. Хы-хы. Этот антиквариат от 300К файлов в 1 дире - становится неюзабельным нахрен. А теперь берем сабжа, кладем 300К файлов в диру там. Ну и вот сравниваем side by side у кого там какой перфоманс операций, и вообще.

Ответить | Правка | Наверх | 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ообщить модератору

19. "Повышение производительности Btrfs в ядре Linux 6.17" –3 +/–

Сообщение от rm_ (ok), 26-Июл-25, 12:09

Если у вас торренты или виртуалки (короче, файлы с перезаписью частей файла), то есть такой момент, там понятно куда, но пока не исправлено.

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

29. "Повышение производительности Btrfs в ядре Linux 6.17" +/–

Сообщение от Аноним (29), 26-Июл-25, 13:24

Что пока не исправлено? Ваше знание обсуждаемого предмета?

Ответить | Правка | Наверх | Cообщить модератору

37. "Повышение производительности Btrfs в ядре Linux 6.17" –1 +/–

Сообщение от Аноним (-), 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" +2 +/–

Сообщение от Аноним (-), 26-Июл-25, 14:06

> сочувствую.  btrfs тупо жрёт место непонятно куда
Понаделал снапшотов и забыл стереть? У н00бов с виртуалками тоже такое бывает :)

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

6. "Повышение производительности Btrfs в ядре Linux 6.17" +/–

Сообщение от Аноним (6), 26-Июл-25, 10:57

Просто придут те кто потерял данные из-за сбоев btrfs и тебе наваляют.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

12. "Повышение производительности Btrfs в ядре Linux 6.17" +9 +/–

Сообщение от Аноним (1), 26-Июл-25, 11:14

>"и тебе наваляют. "
А зачем вы свои комплексы на всех проецируете?

Ответить | Правка | Наверх | Cообщить модератору

23. "Повышение производительности Btrfs в ядре Linux 6.17" +2 +/–

Сообщение от Аноним (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" +/–

Сообщение от Аноним (-), 26-Июл-25, 16:13

> Только при каждом подключении выдаёт сообщение, что диск надо бы и проверить..
При том если на это еще и удумать согласиться - то это как раз его порой и добивает окончательно в вон том случае.

Ответить | Правка | Наверх | Cообщить модератору

63. "Повышение производительности Btrfs в ядре Linux 6.17" +/–

Сообщение от Аноним (-), 26-Июл-25, 16:12

> Ntfs может долго на посыпавшемся диске работать. Не очень хорошо, правда.
Ну да, только он постепенно деградирует а в какой-то момент - хлобысь - не монтируется - и внутри уже везде труха! И даже если что и удастся оттуда отковырять - то основательно попорченое к этому моменту. Ибо в таком режиме оно могло делать хзчто довольно долго.
> Btrfs в случаях неисправного оборудования статистически лучше.
Он по крайней мере орать начинает на csum error и проблему можно заметить на подлете. А не когда том уже загажен в вермишель и там живого места нет.

Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

57. "Повышение производительности Btrfs в ядре Linux 6.17" –1 +/–

Сообщение от Аноним (-), 26-Июл-25, 15:40

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

Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

59. "Повышение производительности Btrfs в ядре Linux 6.17" +/–

Сообщение от Аноним (23), 26-Июл-25, 15:49

Не  знаю, где ты ее "Дофига" используешь, но  я два раза для теста пробовал ее под фс для портеджей. Оба раза заметное на глаз проседание по скорти относиттельно ext4 и отсутствие возможности смонтировать череез 3 месяца. Ядра естественнно последние. С ext4 проблем не было ни когда.
По этому, я в целом за то, чтоб вы тестировали бэтера, даже в продакене. Но не надо заливать шлак в неокрепшие  умы.

Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

61. "Повышение производительности Btrfs в ядре Linux 6.17" –2 +/–

Сообщение от Аноним (-), 26-Июл-25, 16:04

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

Ответить | Правка | Наверх | Cообщить модератору

14. "Повышение производительности Btrfs в ядре Linux 6.17" –2 +/–

Сообщение от Анониссимус (?), 26-Июл-25, 11:22

Лучшая из имеющегося.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

51. "Повышение производительности Btrfs в ядре Linux 6.17" +/–

Сообщение от Аноним (6), 26-Июл-25, 15:08

Хуже придумать трудно.

Ответить | Правка | Наверх | Cообщить модератору

56. "Повышение производительности 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" +2 +/–

Сообщение от Аноним (15), 26-Июл-25, 12:48

В ext4 никогда такого не бывает.

Ответить | Правка | Наверх | Cообщить модератору

40. "Повышение производительности Btrfs в ядре Linux 6.17" +/–

Сообщение от Аноним (-), 26-Июл-25, 14:25

> В ext4 никогда такого не бывает.
Именно поэтому они CRC к журналу экстренно привинтили - а то на кривом железе оно могло вообще все развермишелить оказывается. А теперь - и к метаданным чего-то чексуммы привинчивать начала. И чего это они вдруг?...
А, ну да, наверное потому что ничего не теряло. А каску одевают - для красоты. И бронежилет - для антуражу. А миноискатель - чтобы шикануть. И страховку - по приколу цепляют. Ведь что может пойти не так?

Ответить | Правка | Наверх | Cообщить модератору

47. "Повышение производительности Btrfs в ядре Linux 6.17" +/–

Сообщение от Anonimm (?), 26-Июл-25, 14:54

Серьёзно?
https://www.linux.org.ru/news/linux-general/17448413

Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

26. "Повышение производительности Btrfs в ядре Linux 6.17" +1 +/–

Сообщение от Аноним (49), 26-Июл-25, 13:08

Ты перепутал с xfs (у неё тихие повреждения файлов на диске), ext4 очень надёжна. Если, конечно, не включать data=writeback -- тогда 1/1000 шанс, что открытый на запись файл будет замещён мусором.

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

41. "Повышение производительности Btrfs в ядре Linux 6.17" –1 +/–

Сообщение от Аноним (-), 26-Июл-25, 14:27

> Ты перепутал с xfs (у неё тихие повреждения файлов на диске), ext4
> очень надёжна. Если, конечно, не включать data=writeback -- тогда 1/1000 шанс,
> что открытый на запись файл будет замещён мусором.
У ext4 без полного журнала - файло при обрубившейся на середине записи модет влет остаться наполовину новым и наполовину старым. И конечно в большей части слуаев он вообще читаться не будет потом программами. ФС при этом конечно логически-консистентна по части трекинга аллокации места. Регионы под файлом корректно же трекаются. Так что fsck гонять не надо. А труха в файле - мало ли чего.

Ответить | Правка | Наверх | Cообщить модератору

25. "Повышение производительности Btrfs в ядре Linux 6.17" +2 +/–

Сообщение от Аноним (25), 26-Июл-25, 12:56

Уже два раза ломалась на рабочей станции, первый раз после обновления ядра, второй после отключения света, да починилось быстро по гайдам из интернета, но с нтфс и виндой такого не бывало, уже страшно за свои данные, планирую переезжать на что нибудь журналируемое типа ext4 или xfs, смысл от снапшотов для починки системы на том же диске, если вся фс сломалась и не может быть примонтирована.

Ответить | Правка | Наверх | Cообщить модератору

27. "Повышение производительности Btrfs в ядре Linux 6.17" +/–

Сообщение от Аноним (49), 26-Июл-25, 13:12

Ntfs не менее успешно корёжит и теряет файлы, но главное фрагментация ни в какие ворота.

Ответить | Правка | Наверх | Cообщить модератору

28. "Повышение производительности Btrfs в ядре Linux 6.17" +/–

Сообщение от Fenix (??), 26-Июл-25, 13:19

Лет 8 на этой фс все устройства. Сломалось ровно один раз,  когда из raid 1 диск наживую вытащили. Вырубил машину, воткнул обратно диск,  включил, пошуршало 15 минут и всё на своих местах, всё работает.

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

32. "Повышение производительности Btrfs в ядре Linux 6.17" +/–

Сообщение от Аноним (49), 26-Июл-25, 13:46

Смотря как часто из розетки дёргать. И никаких ntfs3g или более старых версий венды. Ну и повреждения будут тихими, она ничего не сообщает. А в целом, у нтфс очень низкая производительность при работе с кучей файлов, не просто так ресурсы бандлят.

Ответить | Правка | Наверх | Cообщить модератору

52. Скрыто модератором +/–

Сообщение от Аноним (6), 26-Июл-25, 15:10

Ты тролль и сидишь на Винде, нет у тебя никакого btrfs.

Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

75. "Повышение производительности Btrfs в ядре Linux 6.17" +/–

Сообщение от Аноним (75), 26-Июл-25, 17:12

Постоянные отключения света были полгода, ни одного падения фс. Знаете что я дела не так? Я сижу на Debian stable с LTS ядром и не парюсь что у меня "устаревшее" (новое я в chroot|flatpak|distrobox поставлю).

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

82. "Повышение производительности Btrfs в ядре Linux 6.17" +/–

Сообщение от Anonimm (?), 26-Июл-25, 19:10

Вот тут https://www.linux.org.ru/news/linux-general/17448413 как раз о "сверхнадежной" ext4 в Debian Stable.. 😆

Ответить | Правка | Наверх | Cообщить модератору

33. "Повышение производительности Btrfs в ядре Linux 6.17" +/–

Сообщение от Аноним (33), 26-Июл-25, 13:50

Как там bcache? Еще не выкинули?

Ответить | Правка | Наверх | Cообщить модератору

43. "Повышение производительности Btrfs в ядре Linux 6.17" +/–

Сообщение от Аноним (-), 26-Июл-25, 14:30

> Как там bcache? Еще не выкинули?
Пока еще - на месте. А что будет в 6.17 - пока интрига. Что называется, следите за новостями.

Ответить | Правка | Наверх | Cообщить модератору

44. "Повышение производительности Btrfs в ядре Linux 6.17" +/–

Сообщение от Аноним (44), 26-Июл-25, 14:35

Btrfs дефолтная ФС у Федоры, с версии 33. А это значит, что Btrfs станет дефолтной и в RHEL.

Ответить | Правка | Наверх | Cообщить модератору

48. "Повышение производительности Btrfs в ядре Linux 6.17" +/–

Сообщение от Аноним (33), 26-Июл-25, 15:00

В шапке btrfs уже была в preview, но убрали в пользу XFS. Видимо, они что-то знали.

Ответить | Правка | Наверх | Cообщить модератору

58. "Повышение производительности Btrfs в ядре Linux 6.17" +/–

Сообщение от Аноним (44), 26-Июл-25, 15:43

Была, 10 лет назад. Сейчас многое поменялось.

Ответить | Правка | Наверх | Cообщить модератору

65. "Повышение производительности Btrfs в ядре Linux 6.17" –1 +/–

Сообщение от Аноним (-), 26-Июл-25, 16:18

> В шапке btrfs уже была в preview, но убрали в пользу XFS.
А заодно убрали у себя и всех блочно-файлушников - все известные имена из RHBM таки свалили. И скучковались - вот - вокруг btrfs'а почему-то.
Видимо непотребства с сратисом и попытка гальванизации древнего дизайна с потугами сделать из пенсионера чемпиона-олимпийца им как-то не того. Чексумы и рефлинки даже кой-как прикрутили, вроде бы, но я так и не понял - можно ли это уже юзать, или оно как всегда wip и экспериментальное у них. Но даже нубоватый майнтайнер с горящими глазами - в процессе успел задолбаться с легасипроблем этого антика в край - и сбежал, тоже к btrfs'никам вроде.
> Видимо, они что-то знали.
Ага, как что-нибудь еще профачить. Например блочно-файлушное направление у себя. У IBM славные традиции факапов и пролетов, еще с полуоси аж :)

Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

53. "Повышение производительности Btrfs в ядре Linux 6.17" +/–

Сообщение от Аноним (6), 26-Июл-25, 15:12

Проверяют на сколько хомики согласны кушать отбросы. Скорее всего не готовы.

Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

73. "Повышение производительности Btrfs в ядре Linux 6.17" +/–

Сообщение от Аноним (-), 26-Июл-25, 16:44

> Проверяют на сколько хомики согласны кушать отбросы. Скорее всего не готовы.
Остальные вообще предложили на выбор покушать песок, гравий и пенопласт.

Ответить | Правка | Наверх | Cообщить модератору

81. "Повышение производительности Btrfs в ядре Linux 6.17" +/–

Сообщение от ptr (ok), 26-Июл-25, 18:27

Судя по текущим бенчмаркам, это вряд ли
https://www.phoronix.com/review/linux-611-filesystems/3
Пока что XFS для типичной серверной нагрузки (СУБД) выглядит предпочтительней.

Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

45. "Повышение производительности Btrfs в ядре Linux 6.17" +/–

Сообщение от Аноним (45), 26-Июл-25, 14:45

Btrfs -- это ZFS лайт!

Ответить | Правка | Наверх | Cообщить модератору

67. Скрыто модератором +/–

Сообщение от Аноним (67), 26-Июл-25, 16:22

Аксиома Эскобара (с).

Ответить | Правка | Наверх | Cообщить модератору

76. "Повышение производительности Btrfs в ядре Linux 6.17" –1 +/–

Сообщение от Аноним (44), 26-Июл-25, 17:16

>Btrfs -- это ZFS Next!
Пофиксил. Не благодари.

Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

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


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


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


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


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

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


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


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


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


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


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


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


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


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


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


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


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


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


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