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

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

Сообщения

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

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

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

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

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

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

11. Сообщение от Аноним (11), 26-Июл-25, 11:11	+2 +/–
Примерно 5% под метаданные, какой ужас
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #13, #17, #94, #218

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

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

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

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

17. Сообщение от Fracta1L (ok), 26-Июл-25, 11:51	+3 +/–
Не 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
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #106

18. Сообщение от ананим.orig (?), 26-Июл-25, 12:03	–1 +/–
https://lwn.net/Articles/937239/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

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

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

22. Сообщение от Аноним (15), 26-Июл-25, 12:48	+/–
В ext4 никогда такого не бывает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #40, #47

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

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

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

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

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

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

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

33. Сообщение от Аноним (33), 26-Июл-25, 13:50	+/–
Как там bcache? Еще не выкинули?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #43, #229

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

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

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

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

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

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

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

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

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

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

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

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

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

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

51. Сообщение от Аноним (6), 26-Июл-25, 15:08	+/–
Хуже придумать трудно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #90

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

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

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

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

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

57. Сообщение от Аноним (-), 26-Июл-25, 15:40	–2 +/–
> Ошибка выжившего. И у всего миллиарда юзерей 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 ж было).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

99. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #97 Ответы: #101

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

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

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

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

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

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

106. Сообщение от НяшМяш (ok), 26-Июл-25, 23:21	+1 +/–
Какой маленький раздел, милота =) ❯ 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ообщить модератору
Родитель: #17 Ответы: #132

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

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

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

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

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

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

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

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

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

116. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #109 Ответы: #184

117. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #103 Ответы: #118, #124, #224

118. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #117 Ответы: #243

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

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

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

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

123. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #115

124. Сообщение от Аноним (-), 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 жмутся, меньше места жрет, в том числе и как снапшоты и проч.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117 Ответы: #180

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

190. Сообщение от Минона (ok), 27-Июл-25, 18:55	+2 +/–
Оно не умеет ни в какой рейд кроме 0 и 1
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

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

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

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

194. Сообщение от Минона (ok), 27-Июл-25, 19:38	+/–
> У фейсбука несколько доработанный форк. С тем же успехом ты можешь сказать, > что Гугл себя прекрасно с ext2 на всех серверах чувствует. То есть Фейсбук свои наработки в мейнлайн не отдаёт?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #192 Ответы: #195, #208

195. Сообщение от Аноним (49), 27-Июл-25, 19:47	+/–
> То есть Фейсбук свои наработки в мейнлайн не отдаёт? Что-то отдаёт. Ключевые для бизнеса изменения не отдаёт. Но и используют они её не так как будет использовать обычный пользователь, не может являться аргументом. Synology по-моему наиболее близкое, но у них тоже своя btrfs.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #194

196. Сообщение от Аноним (137), 27-Июл-25, 20:04	+/–
>Сравни man btrfs с zpool и zfs. man руководство у btrfs гораздо удобнее структурировано, благодарю за намек. А special device как в zfs там есть !? То есть устройство где фс хранит метаданные плюс порог размера, файлы размером ниже которого будут там хранится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #193 Ответы: #198, #205, #209

197. Сообщение от Аноним (197), 27-Июл-25, 20:44	+/–
> SSDшник выгрузивший труху под журнал ведет к полному дестрою фс при попытке реплея журнала > сыпучие сторажи Наблюдать как рассыпается xfs, ext4 и ntfs на китайских SSD соответствующего китайского качества бессмысленно. Эти ФС на такое поведение накопителей и не рассчитывали изначально, crc в паре критичных мест - это какая-то попытка заткнуть дыру тряпкой на корабле, который уже где-то посреди океана. Либо другие сложные ФС (типа zfs/btrfs), либо RAID (сместить обработку ошибок на другой уровень), либо бекапы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #148 Ответы: #203, #213

198. Сообщение от Минона (ok), 27-Июл-25, 21:41	+1 +/–
>>Сравни man btrfs с zpool и zfs. > man руководство у btrfs гораздо удобнее структурировано, благодарю за намек. Для меня наоборот. > А special device как в zfs там есть !? То есть устройство > где фс > хранит метаданные плюс порог размера, файлы размером ниже которого будут там хранится. Хз. Я юзаю ZFS.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #196

199. Сообщение от Аноним (-), 27-Июл-25, 23:58	+/–
> Ну как это не надо про потери? Потеря файлов есть - это факт. Факт оно - только с диагностикой и конкретикой. А так - при дурацких ситуациях сыпятся любые ФС. > Даже если мне трижды похрен на мои файлы факта потери это не отменяет. Почему-то когда просишь хотя-бы сообщение об ошибке процитировать - господа куда-то сливаются. Просто наблюдение такое. > Ну и в том же предложении я написал, что часть томов были с избыточностью > (не помню, признаться на каких томах были потери). Что есть "избыточность" в ваших терминах? У меня ощущение что вы даже терминологией этой штуки не владеете - но пытаетесь рассказать про какие-то "факты". Но факты - это когда конкретная проблема предъявлена с логами. А это - просто чат ни о чем. Ничего не доказывающий. > удобный кусок и его опровергнуть) - мне совсем не похрен на > данные так как я raid делаю. RAID разные бывают. Например RAID-0 не далеко от JBOD ушел по надежности. > По поводу удобства - согласен с Вами - удобнее. Это главное свойство ФС? Это хорошая добавка, особенно - для себя. > Ну или хотя-бы более важное чем сохранность данных на ней? 1) Ну вот лично у меня - данные не теряются. Может, секрет в том что я понимаю этот дизайн и знаю что я делаю. Хрен его знает. 2) Бэкапы никто не отменял. Потому что случаи бывают разные. Желательно в физически разные локации или на отключаемый диск хотя-бы. Потому что бывает недобрый софт, пыхнувший питальник, и много чего еще. 3) Вот лично у меня как ни странно самая большая потеря была на EXT2. Ибо я вынес файло с почтой - раскатыванием на него относительно старого бэкапа. А более нового блин и не было. С другой стороны в сабже я так пролошивщись и выпилив нужные файлы - достал их из относительно недавнего снапшота просто. Его ж фигачить сильно быстрее чем честный бэкап. Так что про потери - лично мне хотелось бы видеть какую-то КОНКРЕТИКУ. Если уж напирать на ФАКТЫ. Версию ядра, конфигурацию, сообщение об ошибке, вот это все. И/или анализ причин, если вы такое можете. Я вполне поверю если мне сказать "поставил драйвер нвидии, логи не читал - и все фигакнулось". Потому что я убитого таким манером - видел. И btrfs так тоже можно разнести. Но это вообще не к файлухам - а к индусам нвидии  у которых лапки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #185 Ответы: #201

200. Сообщение от Аноним (-), 28-Июл-25, 00:05	+/–
> О йо! > А я то думаю какого х… ext4 на 20 тб монтируется мгновенно, > а эта хрень тупит на 4 тб. Чтобы оно тупило - надо сочетание в виде большого и при том тормозного накопителя. Можно не очень большого - но очень тормозного. А с bg tree оно цепляется влет просто. А ext4 на 20 Tb - это круто - кроме fsck на нем - особенно на тормозном носителе. И даже с fsck оно всю площадь этой штуки - не проверит, как scrub вон там. XFS'ники о чем-то таком даже подозревать уже начали, но у них как обычно героическое преодоление на дизайне который для этого не предназначался, так что что-то где-то как-то экспериментально - уже вроде бы и есть. А в EXT4 такая блажь вообще не предусмотрена - чексум у него один фиг нету, проверять нечего. Конечно при сильном желании с LVM можно и такую камасутру попробовать, только потом менеджмент этой этажерки превратится - в садомазо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #187 Ответы: #250

201. Сообщение от Фофан (?), 28-Июл-25, 00:18	+5 +/–
Честно говоря ожидал что этим закончится не думад, только что так сразу. Логи значит Вам? Не, ну серьезно? Откститесь, это было 5 лет назад минимум. Какие логи? Какие версии ядер? Я просто не пользуюсь этой ФС и как ни странно больше проблем с тех пор не было. Я пришел поделиться своим опытом общения с данной ФС и тем как я решил свои проблемы с ней. Так уж получилось, что мой опыт вот такой. Для меня потеря данных - факт (в независимости от мнения Анонима). У меня не было и нет никаких намерений что-то доказывать. Например что данная ФС плоха или что лучше использовать вместо нее LVM. Вы понимаете дизайн - отлично, рад за Вас (заметьте верю и не прошу доказательств). Прошу только не надо ставить мне диагнозы по фотографии - это не прилично и я Вас об этом не просил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #199 Ответы: #216

202. Сообщение от Аноним (-), 28-Июл-25, 00:51	+/–
> Я тоже за все хорошее, и против всего плохого. Я просто иногда развлекаюсь "полупроф" рекавери данных. Потому что азы топика понимаю, могу рассчитать свои силы и откровенно глупых вещей не делаю. Поэтому насмотрелся на энное количество всякого разного. В принципе дохнет - все. Самыми странными способами. > Вот, что меня реально вымораживает, так это пропаганда невежества. > Как тут, замаскированная в пугалки, Потому что на самом деле - ядро довольно большое и сложное. И плотно трекать развитие всех его подсистем, даже чтобы просто осмысленно ответить на вопросы билдсистемы по части новых фич в i++'м кернеле - уже отдельный квест, назвать это простым я б постеснялся. Это надо плотно мониторить развитие проекта. Я этим занимаюсь, и на поверку большая часть знакомых гентушников знали топик хуже чем я сам - спрашивать их зарекомендовало бесполезным занатием. Возможно бывают и более прошареные гентушники. > что это непостижимые тайные знания, Вполне в пределах сил человеческих. Но вы же понимаете что чем более редкое комбо опций вы врубите - тем менее вероятно что кто-то это до вас делал. По этой причине народ довольно скептично относится к репортам гентушников, которые зачастую жестят с оптимизациями, странными наборами опций и проч - но уверены что это глобальный баг. Проблема только в том что он зачастую - невоспроизводим и уникален для этой тущки. > в убунте ядра собирают иллюминаты с IQ1000+. Судя по моему опыту - я довольно быстро этих иллюминатов обставил в десктопной конфиге. > От себя скажу: > 1)Надо понимать, что не существует живых людей хорошо разбирающихся во ВСЕХ аспектах > и драйверах ядра втч этого конечно же нет у Линуса и даже, ОМГ, у человека которому > я отвечаю, и у меня тоже. :) Вот это 100%. Ядро большое, там много всего. Я знаю в основном то что либо топик моего интереса, либо то что меня импактило. А иногда даже профан может заскорить EPIC WIN каким-нибудь git bisect. Ибо если я вижу с точностью до полстраницы кода в чем факап, я могу и сам допереть "локальным знанием" без раскуривания всей подсистемы от и до. > Не думаю, что есть люди знакомые и с 50%. Так происходит, по > тому, что это ни кому не нужно ибо это не Коран, > чтоб учить его наизусть. Я просто периодически билдую разные выводки ядер под разные железки, с моим тюнингом и неизбежно в курсе наиболее заметных изменений. Чему пруфом эта новость например. > Ваша задача состоит в постепенном увеличении своего кругозора за счёт драйверов, которые > необходимы вашему железу. Типа того. А также знании ключевых подсистем. И изменений в них. А желательно и откуда ждать подлян. Я просто немного доразвил скилл и стал этаким OEM Lite. Мой выбор это дебиан. Но у меня зачастую кастомные ядра вместо стоковых, основательный тюнинг под задачу и проч. И я сам генерю себе образа ос и проч. > Для старта вам достаточно скачать архив с исходниками ядра, На мой вкус при серьезном настрое лучше git склонить. Откуда я многие вещи и узнаю. > make и представлять, как происходит загрузка uefi (надо положить один файлик > и правильно его назвать) Но в таком виде это - это все же режим "в обезьянник принесли гранату". > Все. С большой долей вероятности у вас заработает ядро, собранное в конфигурации > "по умолчанию) т.е можно попробовать вообще ничего не знать про железо. Смотря что понимать под конфигурацией по умолчанию. Если defconfig - то на x86 вы скорее всего конкретно обломаетесь. Если конфиг дистро - пожалуй. Нр при билде i++ версии с оным, билдсистема все же задаст некоторые достаточно интересные и не всегда тривиальные вопросы. Ну это если захочется сбилдить вот имнено ядро, именно САМОМУ - без опоры на тех кто ДО сделает это. > вашего ноутбука. Через год вы будете смеяться в глаза тем, кто > говорит вам, что кроме него ещё только процентов 20 понимают, что делают :) И что, сможете затраблшутить какой-нибудь крутой факап в mm/ или невзлет pci? Второе кстати очень прикольно - ибо на экране нифига. Видяха ж тоже - PCI :) >>Если ФС будет диктовать структуру данных ограничениями - это плохая ФС. > Ну уважаемый Просветлённый ведь поделится с нами не далёкими списком ФС у > которых отсутствуют ограничения :) Это идеал к которому надо стремиться. Ну и вот у сабжа каких-то особых ограничений такого плана я так сходу не вижу. > Я вам еще раз говорю -- мне не нужна помощь для анализа ситуации. Зато я скажу что тут многовато джентльменов которые думают что надо им верить на слово - чтоб им карта как поперла, как поперла. Это провоцирует здоровый скепсис на их тему. И вот тут уж пардон - но мне это надоело и поэтому верить я рекомендую только пруфанутым кейсам с описанием конфиги и диагностики. > ФС с портеджами дала дуба из за комбинации косяка с > отыкливанием БЭТЕРА в ситуации включенного сжатия, и недостатка места, а так > же постепенного распухания ФС из за которого неспеша, но неуклонно пропадало > свободное место. Первый баг вроде поправили. Это все в каком ядре было хотя-бы? > монтироваться btrfs :) И узнал много нового про структуры ее данных. > Но я просто форматнул все в ext4 и занялся более интересными > делами, чего и желаю всем собравшимся. А я таки пожелаю гражданам не быть паразитами и участвовать в жизни экосистемы. Чтобы линух был замечательной системой, и чтобы не юзать окаменелый помет мамонта как топчик вечно. Видите, насколько разный подход ;). >>Теодор Тсо считается за достаточно грамотного? > Вы уж простите меня, но иконостаса с Теодором, Линусом, и даже, о > господи, Вами, у меня нет, лучше учиться, а не молиться. Учиться на EXT4 можно разве что - как ФС делать в 2025 году точно не надо. Уродец с фиксированным числом инод, довольно дурной работой с дирами, никаким менеджментом, без онлайн проверки целостности данных и чексум в 2025 году - очень так себе радость, имхо. >> Я всерьез считаю что у многих гентушников ЧСВ превышает квалификацию и понимание >> процессов. И просто для понимания - я автор этой новости. > А в этой вашей цитате прекрасно всё, ни какие комментарии веселее не будут :) А что делать - опыт с знакомыми гентушниками был вот такой. Вот если б вы крутой баг в этом btrfs (или ком-то еше) вывели на чистую воду и помогли зарулить - отношение было бы совсем другим. А паразитов в лине - не лю. Особенно с раздутым чсв. Экосистема такая. Вы конечно не обязаны, но и остальные не обязаны считать вас чем-то хорошим, это - некий баланс.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #184

203. Сообщение от Аноним (-), 28-Июл-25, 01:05	+1 +/–
> Наблюдать как рассыпается xfs, ext4 и ntfs на китайских SSD соответствующего китайского > качества бессмысленно. Да они и много где еще рассыпаются. Недавно вон рассыпались - у юзеров нвидий. SSD любой, главное драйвер нвидии вгрузить - он память порушит и вот уже тело удивляется - на меня рояль с неба упал - но откуда?! Вчера же все идеально работало?! А можно и энтерпрайзным SSD удружить - если китайские не нравятся. Сделайте его bcache и подкешируете им нагруженную фс. Когда SSD протрется - возможны варианты. Нередко таки начинаются крупноблочные факапы - и тому наступает амбма. Btrfs зачастую успевает поорать про csum error при этом - и это замечают до того как оно эскалирует - в вон то. А в bcachefs пошли дальше и сделали руление кешом частью логики управления репликами. В таком виде оно имеет шансы еще более вменяемо на это все реагировать. В отличие от тех этажерок. > Эти ФС на такое поведение накопителей и не рассчитывали > изначально, crc в паре критичных мест - это какая-то попытка заткнуть > дыру тряпкой на корабле, который уже где-то посреди океана. И тут мы приходим к простой идее. Если не выезжать за допушения дизайна ФС - все будет ок. А если выезжать - undefined. > Либо другие сложные ФС (типа zfs/btrfs), либо RAID (сместить обработку ошибок на > другой уровень), либо бекапы. Одно не замена другому. Но например снапшоты можно делать более часто чем бэкапы. Бэкапы сильно больше ресурсов на создание жрут и восстанавливать долго. Но одно другое никак не заменяет, скорее дополняет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #197 Ответы: #210

204. Сообщение от Аноним (-), 28-Июл-25, 01:12	+/–
> Ubuntu 20.04.6, в которой ядро версии 5.15.xx. Так вот - убунта > не смогла его даже смонтировать, пришлось заново форматировать, но уже в > поделии космонавта. Может там incompat какой-то просто выставился? Более новое ядро и утилсы могут поюзать новые фичи фс - которых тупо не было в старом ядре. В случае btrfs - пытаются делать хотя-бы частичную обратную совместимость. Есть compat флаги. Если ядро не понимает фичу, но она помечена как некритичная - смонтируется и более старым. Если помечена как readonly - старое ядро замаунтит только на чтение, ибо не знает как апдейтить новые индексы и тому подобное. И есть совсем incompat - когда совсем не будет маунтиться, но это как минимум в случае сабжа некая экзотика. > Это и есть та самая надёжность ext4, о которой тут все поют? Если обратить внимание - монтирование новых нтфс из свежих виндов в старые - тоже имеет некоторые особенности. Например read-write монтирование IIRC выносит shadow copies. Что так то - довольно прикольный сюрприз :D > То есть финский автор с товарищами от версии к версии вносят > изменения, после которых система элементарно не работает с другими ядрами, Внезапно в новых ядраз могут внести - улучшения и новые фичи. И даже MS с виндой это практикует. И тоже некие фаллауты по этой линии отхватить можно. А уж что они с ReFS устроить - даже коментировать не удобно. > помню) если и вносили изменения в файловую систему, то она работает > от XP до 11.. Ога, только shadow copies почему-то убивает без предупреждения. И тому подобные приколы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #182

205. Сообщение от Аноним (205), 28-Июл-25, 01:30	+1 +/–
> А special device как в zfs там есть !? Нет. Какие-то патчи были в начале 2023, но заглохло. https://github.com/btrfs/btrfs-todo/issues/19 https://github.com/btrfs/btrfs-todo/issues/50
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #196

206. Сообщение от Аноним (-), 28-Июл-25, 01:40	+/–
> Ну всё верно, только offtopic получается ;) Ну оно все же про то как ФС работают и "около топика", особенно cow. Ибо частично объясняет почему с этим дизайном - бодаются, а новые делают по образу и подобию. Как кент bcachefs. > Да, api для работы с ФС он такой. Там и апи не особо на это заточен, и устройство классических ФС - дико тормозящих с полным журналом. > Было бы красиво startTransaction/commit/rollback на уровне ФС, Я не уверен что апликухам надо самим менеджить ролбэк... но вообще CoW в первом приближении работает так: 1) Планируемая запись пишется в сторону. 2) Если это прокатило - метаданные апдейтятся так чтобы указывать на новый вид. 3) А когда-то потом GC деаллоцирует вон тот блок в середине файла. Прелесть этого? Если крах до завершения 2) это почти аналог rollback - фс просто игнорит недописенное, потому что "указатели еще не запдейтили". Зацепится в чуть более устаревшее состояние, рекавери простой, быстрый, ломаться почти нечему. Сабж делает довольно забавный фокус когда эта логика и к метаданным применяется. Некоторые БД делают нечто похожее, так называемые "версионники". Идея примерно такая же. > но можно в скорости сильно потерять - получить ФС со скоростью СУБД. Что уже ненужно. СУБД СУБД рознь. Скажем многие key-value базы весьма шустрые. Технически ФС является некой формой key-value базы, где key - путь файла, а value - его содержимое. > Хотел другое подчеркнуть - то что называют "багами ФС" багами-то и не > являются чаще всего! У любого дизайна есть особенности, сильные и слабые стороны. И конечто у CoW/LogStructured/etc соотношения и свойства заметно отличаются от "in place" классики. > - 50% - это отсутствие вообще sync/fsync. И как бы какие тут > претензии к ФС, если не сказали "помести данные на диск, они > важные, я подожду"? Это в принципе все так. Но когда у вас картинка дописанная до половины, это все же довольно слабое утешение - ибо читаться она не будет. И даже fsync не дает 100% гарантии ибо у EXT4 просто нет средств откатить частичную запись, если в этот момент случился крах. Точнее, с полным журналом оно конечно сможет закончить запись, но какой ценой... > - 20% - это отсутствие правильной последовательности open/write/fsync/rename/unlink > и т.д. Это в основном проблемы приложений, или немного не поняли > друг друга разработчики ФС и приложений Я бы сказал - ФС многоваот спихивают на разработчиков приложений что по хорошему должно быть в их епархии, а большая часть разоаботчиков софта - не парились. И получается то что получается. > - 20% - это баги именно в реализации ФС. Вот мы как бы про эти случаи... У сабжа fsync есть и работает. Правда - не очень быстро. В новых ядрах подразогнали но все равно - тяжеловатая операция. При обновлениях системы я как раз делаю подобие мануальной группировки транзакций: - Снапшот старого состояния ОС. - eatmydata apt upgrade <1500500 пакетов> (чтобы fsync вырубить, ага) - Если это прокатило - я получаю новую систему. - Если это не прокатило по любому поводу - откат в тот снапшот. В чем пойнт? Экономия в fsync в пакетнике ускоряет "apt upgrade" в несколько раз, а разбираться с полу-недо-апгрейженой системой я все равно в гробу видал. > - 10% - это баги в подсистеме ввода/вывода (записи/чтения секторов) и аппаратные > проблемы (или особенности работы) в дисках/RAID-массивых и т.д. Сейчас этого по моим наблюдениям стало сильно более 10%. Чудесатые черепицы в HDD, гонка за скоростью и емкостью при удешевлении в SSD. Ведет к странным свойствам и хлипкости. Более того. Чем больше поток данных при равном BER тем быстрее оно - пробьет. В какой-то момент FEC не выдюживает - и наружу вываливается нечто левое. Что доставляет немало радости ФС. Особенно если у них чексум не было и они это парсить попытались. > аккумуляторов/ионисторов/конденсаторов физически не успеет записать данные корректно > при потере питания. У накопителей есть некое подобие транзакционной семантики - управление кешами и проч. И поэтому ядро и фс знает - завершилась ли запись. И действует с учетом этого знания. У особо похабных девайсов - фирмвар может и таки соврать что записал, но реально пролюбить при слете питания. Но это баг фирмвари девайса и выходит за допущения семантики ФС. > Или со временем возникнет ошибка чтения. И вот как с этим жить? У btrfs есть DUP - я его как раз для парирования рандомных единичных бэдов местами поюзал, там где 2 девайса чисто технически - некуда. > Ну как бы тоже не проблема в реализации ФС, а скорее оценка > устойчивости ФС в целом к неустранимым внешним ошибкам в важных служебных > областях. Соберётся ФС сама после такого, или уже не спасти? > Не очень много ФС вообще какие-то гарантии дают в таких случаях. А > может быть гарантии и не нужны, просто бекапиться надо почаще ;) Сабж с схемой DUP неплохо в таких случаях трепыхается. В целом идея self heal кривой копии из исправной (кто правильный определяется по чексумам) - так то неплохо придумано. Кент этот момент тоже стырил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #191

207. Сообщение от Аноним (-), 28-Июл-25, 01:48	+/–
> А потому что софтрейд совершенно не модно. Кому оно надо? А без > него всё замечательно, это просто не заботы ext4. Ну правильно, надо еще в вендорлок вляпаться, зип девайсов и накопителей держать и проч, ага. Вот чтобы этим всем не заниматься - я и предпочитаю сабжа. А менджмент в том стиле должен умереть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #178

208. Сообщение от Аноним (-), 28-Июл-25, 02:13	+1 +/–
>> У фейсбука несколько доработанный форк. С тем же успехом ты можешь сказать, >> что Гугл себя прекрасно с ext2 на всех серверах чувствует. > То есть Фейсбук свои наработки в мейнлайн не отдаёт? Да все они отдают, там отвисает и Мэйсон и изрядная часть всем известной тусовочки блочнофайлушников. Эн ядер назад например был забавный фикс - мол, если файло более 20 терабайт - фс может помереть. Просто у FB юзкейсы специфичные. Скажем у них зачастую 1-дисковые конфиги. Ну у них RAID и не в приоритете. Особенно RAID56 который на типовые сервера вообще - по перфомансу "не очень" из-за RMW. Еще есть всякие фичи которые - экспериментальные. Чтобы их врубить - надо ядро билдить с соотв настройками в конфигах. Скажем raid stripe tree - или изменения формата уменшающие lock contention под большой нагрузкой. Просто это wip и плохо протестировано. И если что - вам и не обещали prod quality на этом. Гугло достаточно крутое чтобы делать вещи по типу big table, там требования к ФС специфичные, а целостность оно само обеспечивает на совсем других уровнях. Фйэсбук так высоко не летает - и у них сервера более типичные. Поэтому им сильно меньше смысла душиться жабой. И да, кому и зачем патчи гугли интересно? У вас big table есть? Не, вот это вам гугло точно не отдаст. Взращивать себе конкурентов они явно не планируют.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #194

209. Сообщение от Аноним (-), 28-Июл-25, 02:23	+/–
> man руководство у btrfs гораздо удобнее структурировано, благодарю за намек. Не такого результата этот минога ожидал :)) > А special device как в zfs там есть !? То есть устройство > где фс хранит метаданные плюс порог размера, файлы размером ниже > которого будут там хранится. Неа. То-есть чисто теоретически оно так наверное могло бы. Чисто практически - метаданные лучше хранить на более чем 1 девайсе в схеме RAID1 хотя-бы. И оно так то практикует tail packing и хранение мелочи - в метаданных. Для улучшения перфоманса, чтобы не переться куда-то еще за данными. Наверное потому и работает нормально без подпора сотнями рам как zfs.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #196 Ответы: #215

210. Сообщение от Аноним (197), 28-Июл-25, 02:28	+/–
> Да они и много где еще рассыпаются. Недавно вон рассыпались - у юзеров нвидий. SSD любой, главное драйвер нвидии вгрузить - он память порушит и вот уже тело удивляется - на меня рояль с неба упал - но откуда?! Надо быть честным. Там всё рушится, не только ФС. От разгона оперативки тоже всё порушится, или от RowHammer, или от криво настроенного DMA. Эффект иногда не сразу смертельный, а как-то система пытается работать, но постепенно бит за битом всё портит. crc в момет записи может и правильно посчитать, только данные уже не те, какие должны быть... > И тут мы приходим к простой идее. Если не выезжать за допушения дизайна ФС - все будет ок. А если выезжать - undefined. При глюках в процессоре/оперативке даже zfs и btrfs могут пострадать. Это надо ещё и правильно компилятор сделать. Драйвер ФС тоже может ошибку crc не заметить из-за глючно работающих флагов проца и свалится не в ту ветку кода. zfs/btrfs по идее должны выдержать баги с диском, но вряд ли они переживут баги с процессором или оперативкой!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #203 Ответы: #217

211. Сообщение от Аноним (211), 28-Июл-25, 05:32	+/–
Поддерживаю, за 20 лет использования NTFS - чтобы он "сам по себе сыпался" - не видел ни разу, только когда диск сыпался и обрастал БЭДами, и то, средствами NTFS можно "закрыть бэды", например для дисков, у которых появилось пару бэдов и они не растут. NTFS = скорость + надёжность + функционал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #183 Ответы: #219

212. Сообщение от Аноним (211), 28-Июл-25, 06:07	–1 +/–
NTFS!!! Если файлы меньше 1КБ - то они хранятся прямо в MFT. Но это кажется ещё вопрос в зависимости от версии NTFS, в разных источниках от 696 байт, 968 байт, до 4КБ. А если хранение длительное с редким доступом и без изменения - то почему-бы не рассмотреть VHD с оптимизацией или WinMount/WinArchiver чтобы монтировать ZIP-архив как диск. А если файлы ещё при этом большого размера - то лучше хранить в какой-нибудь кластерной БД с доступом через WebDAV.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #144 Ответы: #226

213. Сообщение от Anonimm (?), 28-Июл-25, 11:22	+1 +/–
> китайских SSD А есть другие? Вообще уровень экспертности местных завсегдатаев уже даже не удивляет. Они все не могут поверить, что "сверхнадежная" ext4 рассыпается уже даже без участия пользователя..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #197 Ответы: #222

214. Сообщение от Anonimm (?), 28-Июл-25, 11:28	–1 +/–
> всегда есть ненулевая "вероятность повреждения" по причине железных проблем. Точно! У всех, кто отписался на реддите, одинаковая модель диска.. 😆 Да уж, что люди только не придумают, лишь бы не разочароваться в своём кумире, который меняет ФС без обратной совместимости..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #179

215. Сообщение от sdfsdf444 (?), 28-Июл-25, 11:46	+/–
>метаданные лучше хранить на более чем 1 девайсе в схеме RAID1 хотя-бы Special Device mirror из коробки доступен
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #209 Ответы: #228

216. Сообщение от Аноним (-), 28-Июл-25, 15:14	–4 +/–
> Честно говоря ожидал что этим закончится не думад, только что так сразу. А что вы хотели то без конкретики, но при этом педалируя тему фактов? Чтобы так называемые "факты" приняли за чистую монету, при том что деталей не будет? Так не бывает. А тут периодически бывает еще нашествие ZFSников и NTFSников с комплексами, которые отродясь сабж не видели и не юзали - но рассказывают как он якобы сыпется. Так что я со своей стороны предлагаю - учитывать этот фактор и относиться к "фактам" без какой либо конкретики с здоровым скепсисом, понимая что это может быть и маркетинговый булшит. > этой ФС и как ни странно больше проблем с тех пор не было. А у других людей - были проблемы. С разными ФС. И какой отсюда вывод? > Я пришел поделиться своим опытом общения с данной ФС > и тем как я решил свои проблемы с ней. Опять же - без конкретики это все - о чем вообще? Никаких пруфов что это опыт а не бабушкины сказки как у тех господ - нет. > Так уж получилось, что мой опыт вот такой. Для меня потеря данных - > факт (в независимости от мнения Анонима). Этот факт в данном случае - ничем не подкреплен. Поэтому может и быть фактом. А может быть и очередным кульным рассказиком как у тех ZFSников/NTFSников. > не надо ставить мне диагнозы по фотографии - это не прилично > и я Вас об этом не просил. Если вы хотите иного отношения - тогда, начиная педалировать тему фактов - неплохо бы эти факты и хоть какие-то детали предоставить как пруф, имхо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #201 Ответы: #238

217. Сообщение от Аноним (-), 28-Июл-25, 16:16	+/–
> Надо быть честным. Там всё рушится, не только ФС. Просто с ФС это наименее приятно. От ВНЕЗАПНОЙ кончины системы до потерь данных - не круто ощущается. > постепенно бит за битом всё портит. crc в момет записи может > и правильно посчитать, только данные уже не те, какие должны быть... На практике чексуммы хорошо орут в логи на тему несовпадения. Что дает шансы разобраться с этим всем ДО наступления упомянутого сценария. Потому что чаще всего рушатся все же активно считаемые или кантуемые данные, и чексуммы - часто попадают под это определение. Их прелесть - end to end проверка что данные записываются и читаются ОК. Так что если сабж начал орать про csum failed - это 99.9% не баг фс, а проблемы оборудования и его надо в темпе вальса привести в порядок. > При глюках в процессоре/оперативке даже zfs и btrfs могут пострадать. Могут. Но как показала практика - как минимум btrfs обычно успевает изрядно поорать в логи на сбои чексумм до того как это эскалирует в что-то фатальное. Если логи все же мониторить немного - можно заметить дефектное железо до того как все развалится. А с чем-то типа EXT4 или NTFS сюрпризец получается - ВНЕЗАПНЫМ. Вот так просто сегодня на вас "рояль сверху упал". Почему именно сегодня и какие предпосылки? А попробуйте угадайте без чексумм корректно оно там работало или где.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #210

218. Сообщение от Анониматор (?), 28-Июл-25, 16:38	+/–
Это везде так, просто некоторые ФС врут и показывают максимальный или не очень размер диска, а на пустом диске доступно почему-то меньше (ext4, brfs), а есть честный xfs который показывает полный размер диска и честно показывает сколько реально занято включая метаданные.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

219. Сообщение от Аноним (-), 28-Июл-25, 18:48	+/–
> Поддерживаю, за 20 лет использования NTFS - чтобы он "сам по себе > сыпался" - не видел ни разу, И свеженькое про Win2016 server VS дедупликация VS карапт данных - тоже все врут? И настоящее индусское качествл когда кривые метаданные выносят в BSOD все, от винтукея до десятки - несчитово, видимо. Зачем же чинить баги в драйвере если пипл и так покупает? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #211

220. Сообщение от Аноним (-), 28-Июл-25, 18:53	–1 +/–
> Этот "капитан звездолета" диванный теоретик насмотревшийся конференций типа хайлоад. А капитан то - немного практикует. И вот лично свои проекты у капитана звездолета - есть. В отличие от тебя, придатка к корпорации, который в отрыве от этой корпы - ничто. Сбитый летчик, с этими твоими BSD и прочим ненужно. И ZFS там же скоро будет, вероятно. С тем девелопом проекта будеит много интересных вещей. На которые лучше смоетрть - со стороны :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #189

221. Сообщение от _ (??), 28-Июл-25, 19:29	+/–
>> Я прост не вижу смысла использовать Btrfs для файлопомоек. > Btrfs device add же, чтоб расширять эту файлопомойку без . В отличие от вон того. Уно моменто! "Того" - это lvm* чтоле? И что там записано в "лишних движений" ? Что совой об пенёк, что пеньком об сову... (С)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #171 Ответы: #233

222. Сообщение от _ (??), 28-Июл-25, 19:41	+/–
>> китайских SSD > А есть другие? Интересно из какого мухосранска ты ведешь репортаж? Потому как в моём мухосрансе есть _всё_, вот цена разная - да :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #213

223. Сообщение от bOOster (ok), 28-Июл-25, 21:51	+/–
ZFS отлично работает с JBOD. В отличие от обсуждаемого кривого поделия.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #185 Ответы: #232

224. Сообщение от Аноним (105), 28-Июл-25, 23:20	+/–
Что-то у вас тут слишком утрированно, не может быть на КАЖДЫЕ 4кб данных 60кб метаданных, тогда бы диск был заполнен метаданными в гораздо большей степени чем данными, а это не так, метаданные составляют небольшую часть от реальных данных, так что ваши теоретические циферки не совпадают с реальностью.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117 Ответы: #234

225. Сообщение от Аноним (105), 28-Июл-25, 23:30	+/–
Не модно у кого?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #178

226. Сообщение от Аноним (49), 29-Июл-25, 00:32	+/–
Ей это никак не помогает. А с каких пор? В ext4 уже 15 лет (начиная с ядра 4.2) ~4кб данных сохраняются прямо в иноде. В btrfs ~15кб.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #212 Ответы: #230

228. Сообщение от Аноним (-), 29-Июл-25, 01:47	+/–
> Special Device mirror из коробки доступен Не знаю что там у вас за коробки. В моей коробке в виде майнлайн кернела - я вижу btrfs и bcachefs из интересного. А zfs - точно не из коробки там. И заметно опосля релиза ядра.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #215

229. Сообщение от Аноним (229), 29-Июл-25, 14:16	+/–
А ведь это, действительно круто.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

230. Сообщение от Аноним (230), 29-Июл-25, 14:19	+/–
> ext4 ... ~4кб данных сохраняются прямо в иноде В ext4 размер смешной какой-то. От 60 до 160 байт в дефолте. Возможно, если размер inode большой, то получится до килобайтов догнать. Но такие большие иноды могут тоже боком выйти. > If the file is smaller than 60 bytes, then the data are stored inline in inode.i_block. If the rest of the file would fit inside the extended attribute space, then it might be found as an extended attribute “system.data” within the inode body (“ibody EA”). > Pending a change to compact the extended attribute key used to store inline data, one ought to be able to store 160 bytes of data in a 256-byte inode (as of June 2015, when i_extra_isize is 28). Prior to that, the limit was 156 bytes due to inefficient use of inode space.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #226 Ответы: #231

231. Сообщение от Аноним (49), 29-Июл-25, 16:31	+/–
Зависит от inode_size. Умолчание 256, помещается 100-120, откуда меньше? Для 1024 уже почти 900. Дефолтный размер блока 4кб, можно запихнуть иноду на весь размер блока. Если есть цель хранить определённые данные, может  иметь смысл увеличить размер блока. Потому что, в любом случае, при дефолтном размере блока 4кб максимальный размер файла 16тб, и это же ни о чём.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #230

232. Сообщение от Аноним (-), 29-Июл-25, 18:44	–3 +/–
> ZFS отлично работает с JBOD. В отличие от обсуждаемого кривого поделия. А вот еще видный эксперт от ZFS понабежал. Уровень экспертизы и доверия к сообщениям можно оценить прямо вот тут: https://www.opennet.me/~bOOster (да, интернет все помнит). От себя скажу что предпочитаю линух в том числе и потому что сообщество там - получше вот таких адептов BSD. По соотношению знаний, скиллов и чсв.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #223

233. Сообщение от Аноним (-), 29-Июл-25, 18:49	+/–
> Уно моменто! "Того" - это lvm* чтоле? И что там записано в > "лишних движений" ? Сколько вам приседаний потребуется чтобы запилить с LVM чексумы, снапшоты, гибкое управление местом, и в вот это все - device add? Это явно не 1 команда будет как вон там. И даже так оно потом врядли так сразу дотумкает на лету починить допустим битую реплику с исправной по несовпадению чексумы, а? Или вы и это показать - смогете? :) > Что совой об пенёк, что пеньком об сову... (С) Ну да, конечно, только вон там - "фантомас в очках на аэроплане" вместо 1 команды "btrfs device add" :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #221

234. Сообщение от Аноним (-), 29-Июл-25, 18:53	+/–
> Что-то у вас тут слишком утрированно, не может быть на КАЖДЫЕ 4кб > данных 60кб метаданных, тогда бы диск был заполнен метаданными в гораздо > большей степени чем данными, а это не так, метаданные составляют небольшую > часть от реальных данных, так что ваши теоретические циферки не совпадают > с реальностью. Оно и не будет на практике, кроме может БД с мелкими записями разложенной на cow без nocow на ее файлы. А реально - смотреть статистику накопителей и IO. Во многих случаях это мало чем отличается от EXT4 какого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #224

237. Сообщение от Аноним (-), 30-Июл-25, 01:22	+/–
Это мне известно, другим известно или нет вы у них узнавайте. Я подсчётами не занимался с какой разновидностью сжатия и на сколько будут сжаты файлы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #239

238. Сообщение от Фофан (?), 30-Июл-25, 01:29	+/–
> А что вы хотели то Я бы хотел чтобы Вы писали вы с большой буквы. ) Шутка. Если честно, то все, что я хотел - я уже написал. В первом своем сообщении: - Я дважды терял данные на btrfs и перешел, в связи с этим, на lvm. Вы же, защищая btrfs, могли бы не утруждать себя длинными ответами и просто написать - ВЫВСЕВРЕТИ. Идеальный бы получился диалог. Гораздо короче, и при этом, такой же по смыслу. И да, я нагло пользуюсь Вашим приемом отвечать на кусок фразы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #216 Ответы: #242

239. Сообщение от Аноним (-), 30-Июл-25, 01:39	+/–
Поправку надо сделать. "Насколько сожмутся - настолько и уменьшает, от данных и алго сжатия зависит" с этим я согласен. "Это ессно похуже чем архиватором - блоки мельче для рандомного доступа, что несколько ухучшает сжатие" частично согласен. "Зато распаковка - на лету, прозрачно, незаметно" согласен, но с оговоркой, что предположу, из-за того что процессоры сильно мощные не Pentium, Pentium 2 и младше, из-за этого и распаковка сжатых файлов алгоритмами сжатия встроенных в файловые системы незаметна, не видна нагрузка на процессор или она очень маленькая можно пренебречь. Проверять надо, может кто-то уже проверял не знаю, нет у меня для проверки Pentium, Pentium 2 и младше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #237 Ответы: #240

240. Сообщение от Аноним (-), 30-Июл-25, 01:53	+/–
"Зато распаковка - на лету, прозрачно, незаметно" вот тебе на подумать, а верить этому тексту или не верить каждый решает сам: "Нагрузку на CPU и «узкие места» при сжатии/распаковке файлов средствами файловой системы во многом определяют три фактора:     Выбранный алгоритм сжатия     Скорость носителя (HDD, SSD, NVMe)     Баланс I/O ↔ CPU (узкий ресурс системы) Ниже приведены усреднённые оценки по наиболее популярным алгоритмам (данные примерные, в реальных условиях зависят от версии реализации, настроек уровней сжатия, характеристик железа и паттерна доступа):     LZ4     • Очень быстрый алгоритм с небольшим коэффициентом сжатия (~1.5–2×).     • Распаковка: ~0.5–2 GB/s на одно ядро (зависит от частоты CPU).     • CPU-нагрузка: при последовательном доступе к SSD обычно занимает 5–15 % одного ядра, при нагрузке >1 GB/s может «вырасти» до 20–30 %.     Zstandard (zstd)     • Хороший компромисс скорость/коэффициент (2–3× на уровне «быстрого» режима).     • Распаковка: ~1–3 GB/s на ядро (уровень 1–3).     • CPU-нагрузка: примерно в 1.5–2 раза выше, чем у LZ4 при тех же скоростях, или ~10–25 % ядра для SSD.     gzip (DEFLATE)     • Достаточно эффективен по сжатию (2–3×), но медленнее zstd на «низких» уровнях.     • Распаковка: ~0.5–1.5 GB/s на одно ядро.     • CPU-нагрузка: 15–50 % одного ядра, в зависимости от уровня (–1 быстрый, –9 медленный).     bzip2     • Высокий коэффициент (~3–4×), но медленный.     • Распаковка: ~0.2–0.5 GB/s на ядро.     • CPU-нагрузка: 50–100 % одного ядра (узко используется как single-thread).     LZO/LZMA и другие     • LZO близок по характеристикам к LZ4, но чуть медленнее и более «тяжёлый» коэффициент.     • LZMA (7-zip-стиль) может давать сжатие >4×, но очень медленный: распаковка <0.5 GB/s, CPU до 100 %. Как это выглядит в реальной файловой системе • ZFS со сжатием LZ4 по умолчанию практически не создаёт узкого места по CPU на NVMe/PCIe 4.0, а даже на SATA-SSD редко нагружает ядро >10–15 %. • Btrfs/ZFS с Zstd (уровень 1–3) на SSD обычно съедают 10–25 % ядра под последовательными операциями чтения/записи. • NTFS Compression (Windows) — это Deflate (gzip-аналог), часто ограничено ~150–200 MB/s, и CPU-нагрузка на ядро может доходить до 30–50 % при «жёстких» нагрузках. Что важно учесть • При медленных накопителях (HDD ~100–200 MB/s) сам диск становится бутылочным горлышком: алгоритм сжатия/распаковки в подавляющем большинстве случаев «успевает за диском», и CPU-нагрузка будет низкой (<5 %). • При очень быстрых SSD/NVMe (в сотни гигабайт в секунду) более «тяжёлые» алгоритмы могут нагрузить CPU на 100 % и замедлить I/O до скорости компрессора. • Параллелизм: многие FS и ОС могут сжимать одновременно несколько файлов в параллельных потоках, но каждый поток обычно «сидит» на одном ядре при распаковке. Рекомендации     Для максимальной производительности и минимальной нагрузки CPU на современных SSD/NVMe: используйте LZ4.     Если нужна лучшая степень сжатия при умеренной нагрузке — Zstd на уровне 1–3.     Для совместимости с Windows-стандартами — NTFS Deflate, но учтите его меньшую пропускную способность. Итог: практически всегда выбор компромисса «скорость компрессии/распаковки ↔ коэффициент сжатия», и на конечную загрузку CPU сильно влияет быстродействие носителя"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #239

242. Сообщение от glebiao (ok), 30-Июл-25, 06:38	+1 +/–
>> А что вы хотели то > В первом своем сообщении: - Я дважды терял данные на btrfs > и перешел, в связи с этим, на lvm. Вы же, защищая на правах человека, у которого btrfs в проде в 3 местах, вставлю несколько копеек. 1) чтобы данные потерять, в настоящий (2025) момент, нужно специально постараться. btrfs великолепно справляется с аварийными ситуациями, отключениями питания. Раньше, лет 8 назад, ситуация была хуже. 2) при этом надо учитывать особенности. В частности, btrfs сильно не любит бэды. И обслуживание надо запускать регулярно, отключать scrub по крону не стоит. Но от наличия бэдов btrfs больше не разрушается. 3) душе милее (и объективно, сильно быстрее) xfs, но если нужны лёгкие снэпшоты, то btrfs. А они нужны, примерно, всегда. 4) бэкапы -- самоочевидно. 5) zfs -- игрок в другой категории, более тяжеловесный и требовательный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #238 Ответы: #247, #252

243. Сообщение от glebiao (ok), 30-Июл-25, 06:52	+/–
> Проверяйте кому надо, я сам не проверял. 3–4 MiB взято отсюда: "Вот > почему при записи нескольких KiB вы можете увидеть на диске «отдачу» > в мегабайты: да, но в реальных сценариях использования пишется не один маленький файлик. Коэффициент размножения будет сильно зависеть от того, сколько операций пройдут между интервалами commit. Ксати, указание commit=110 и выше, заметно повышает производительность. Но тут надо быть уверенным в стабильности питания и вообще, что делаешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118

244. Сообщение от glebiao (ok), 30-Июл-25, 09:21	+/–
> Какую ФС лучше использовать для хранения большого числа файлов? например 50 млн, > 100 млн? И желательно чтобы при этом сильно не проседала производительность > чтения-записи. отличный сценарий для XFS, если не нужны сжатие, снэпшоты и массовое удаление производится не слишком часто. на btrfs такой сценарий тоже вполне достоен, но по мере накопления снэпшотов будет заметное проседание времени доступа к снепшотам (не основным данным!).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #144 Ответы: #254

245. Сообщение от glebiao (ok), 30-Июл-25, 09:23	+/–
> то что меня должно будет удивить в использовании этой ФС > по сравнению с ZFS ? легковесность и удобство механизма снепшотов. в стандартных сценариях большинство фич zfs никто и никогда не использует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #249

246. Сообщение от Аноним (246), 30-Июл-25, 20:37    Скрыто ботом-модератором	+/–
А кроме лопат и шагающих экскаваторов ничего и не существует. Расскажи, каково это — жить с таким узким кругозором?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #248

247. Сообщение от Фофан (?), 30-Июл-25, 21:56	+/–
Спасибо большое за Ваш ответ! Как я понял из ответов, btrfs сейчас стабильнее, и стало быстрее монтироваться. Если будет возможность, то попробую еще раз собрать на ней тома. Насколько я понимаю, в моем втором случае как раз scrub файлы и повредил, поскольку модуль ОЗУ работал с ошибками и в нем не сходилась контрольная сумма.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #242

248. Сообщение от Фрол (?), 31-Июл-25, 01:06	+/–
> А кроме лопат и шагающих экскаваторов ничего и не существует. Расскажи, каково > это — жить с таким узким кругозором? хоссспади еще один ну давай расширь мне кругозор расскажи например про выгоды btrfs на виртуальном хранилище а то и дважды виртуальном про выгоды на лаптопе с одним диском про выгоды при работе с бд ( бонус пойнты - при работе с ораклом) про компрессию и дедупликацию на десктопе расскажи тоже, ты ведь наверняка хранишь там что-то кроме мс офисных док фотачек музыки и прона с птеродактилями? давай не стесняйся я как раз на дежурстве спешить некуда что бы и не послушать сказок венского леса?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #246

249. Сообщение от Минона (ok), 01-Авг-25, 09:17	+/–
>> то что меня должно будет удивить в использовании этой ФС >> по сравнению с ZFS ? > легковесность и удобство механизма снепшотов. > в стандартных сценариях большинство фич zfs никто и никогда не использует. ВЕ -- офигительная фича.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #245 Ответы: #251

250. Сообщение от Минона (ok), 01-Авг-25, 14:21	+1 +/–
time mount /mnt/disk15 real    0m0.283s user    0m0.000s sys     0m0.188s time mount /mnt/disk14 real    0m12.478s user    0m0.000s sys     0m0.051s df -hT Filesystem     Type      Size  Used Avail Use% Mounted on /dev/sdo       ext4       19T  3.5T   14T  21% /mnt/disk15 /dev/sdn       btrfs     3.7T  3.5T  188G  95% /mnt/disk14 Оба подключены к LSI SAS. ext4 монтируется в 44 раза быстрее. Да в опу этот ваш бтр...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #200 Ответы: #253

251. Сообщение от glebiao (ok), 03-Авг-25, 07:39	+/–
>>> то что меня должно будет удивить в использовании этой ФС >>> по сравнению с ZFS ? >> легковесность и удобство механизма снепшотов. >> в стандартных сценариях большинство фич zfs никто и никогда не использует. > ВЕ -- офигительная фича. На btrfs автоматически происходит то-же самое. поскольку снэпшоты не требуют дополнительных телодвижений, то и отдельной сущности типа boot environment, не нужно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #249 Ответы: #256

252. Сообщение от Аноним (-), 03-Авг-25, 17:54	+/–
> 2) при этом надо учитывать особенности. В частности, btrfs сильно не любит > бэды. И обслуживание надо запускать регулярно, отключать scrub по крону не стоит. На самом деле бэд - даже под метаданными - оно таки на отлично переживет. Если есть избыточность. Они одно время они наслушались господ глаголящих что "ssd все равно данные дедуплицировать может" и - на этой почве удумали на 1-дисковых конфигах отключить схему DUP для метаданных сделав по дефолту Single, подразогнав перфоманс. Это немедленно отлилось, рассыпонами при вылезании бэдов под метаданными. И сколько-то версий btrfs-utils назад DUP на 1-дисковых фс по дефолту - вернули обратно. Потому что в этом случае, даже если бэд - оно просто вытащит вторую копию, и починит проблемную - вызвав ремап кривого сектора к тому же. И в таком виде оно много кому может мастеркласс дать на тему как надо было. А бэд под _данными_ импактит только файл под который он попал и намного меньшая проблема. Впрочем даже и там DUP можно сделать, просто ценой 2x записей и ополовинивания скорости. Ну и от кончины девайса совсем - в отличие от RAID1 это не поможет. Если это понимать, то отличная штука, уже спасло меня от нескольких ненужных приключений на ровном месте. Но логи все же надо мониторить. > Но от наличия бэдов btrfs больше не разрушается. На самом деле он с его self heal может много кому мастеркласс дать на тему как надо было. Если избыточность есть. > 5) zfs -- игрок в другой категории, более тяжеловесный и требовательный. Это то что топящие за ZFS господа не понимают. Btrfs - general purpose файлуха как таковая. А адепты ZFS ничего кроме убер-хранилок знать не хотят. Тем временем сидя с NTFS или чем там и VSS как средство снапшотирования (кошмар какой!).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #242

253. Сообщение от Аноним (-), 03-Авг-25, 18:14	+/–
> real    0m12.478s > user    0m0.000s > sys     0m0.051s Так это - уже с bg_tree было, или где? Опцию bg_tree надо при создании фс пока указывать явно. Или явно "конвертить" в него (реально конверсия сводится к отстройке +1 индекса в новом дереве). Судя по временам - видимо без bg_tree. > Да в опу этот ваш бтр... Ну дык, юзай этот твой ext4 педальный, как будто кто-то кого-то заставляет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #250 Ответы: #255

254. Сообщение от Аноним (-), 03-Авг-25, 18:40	+/–
> отличный сценарий для XFS, если не нужны сжатие, снэпшоты и массовое удаление > производится не слишком часто. Он по метаданным XFS вообще-то не чемпион. Хотя ему скорее плохет от больших фрагментированных файлов, а вон то вполне может прокатить. > на btrfs такой сценарий тоже вполне достоен, но по мере накопления снэпшотов > будет заметное проседание времени доступа к снепшотам (не основным данным!). На btrfs не стоит накапливать много снапшотов. Это и место жрет и замедляет работу. Но оно как-то так и с виртуалками с cow дисками и проч. Вон то не столько от числа файлов зависит сколько от числа снапшотов референсящихся на 1 и тот же блок. С другой стороны, эквивалентом снапшота на не-cow то - полная копия разве что. Места это жрать будет дай боже. И это "не совсем то" ибо скопировать файлы консистентно с живой ФС это очень отдельный квест, ибо они могут меняться по ходу операции копирования. Тут конечно можно кое-что узнать про freeze() и thaw() и ... получить экспериенс уровня виндового VSS в подарок :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #244

255. Сообщение от Минона (ok), 04-Авг-25, 07:29	+/–
>> real    0m12.478s >> user    0m0.000s >> sys     0m0.051s > Так это - уже с bg_tree было, или где? Опцию bg_tree надо > при создании фс пока указывать явно. Или явно "конвертить" в него > (реально конверсия сводится к отстройке +1 индекса в новом дереве). Судя > по временам - видимо без bg_tree. >> Да в опу этот ваш бтр... > Ну дык, юзай этот твой ext4 педальный, как будто кто-то кого-то заставляет. Если ФС из коробки нормально не работает -- она и есть конь педальный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #253

256. Сообщение от Минона (ok), 04-Авг-25, 07:31	+/–
> На btrfs автоматически происходит то-же самое. Автоматически?! Ну-ну.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #251 Ответы: #257

257. Сообщение от glebiao (ok), 06-Авг-25, 10:29	+/–
>> На btrfs автоматически происходит то-же самое. >Автоматически?! >Ну-ну. Почему нет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #256

258. Сообщение от Аноним (258), 15-Авг-25, 07:48	+/–
Лучшая фс. На всех домашних компах уже более 8 лет. Много раз отключался свет, но фс не разу не разваливалась. Какое то время даже жил с тестовым рейдом5, из недостатков только низкая скорость. Надёжность высокая
Ответить | Правка | Наверх | Cообщить модератору

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

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