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

"В ФС Ext4 намечен к удалению режим data=journal "	+/–
Сообщение от opennews (??), 09-Окт-26, 09:51
В состав ядра Linux 7.3, релиз которого ожидается 19 октября, принято изменение, переводящее режим монтирования файловой системы Ext4 "data=journal" в разряд устаревших технологий. Поддержку данной опции монтирования намерены прекратить в 2028 году... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=66430
Ответить | Правка | Cообщить модератору

Сообщения

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

1. Сообщение от Аноним (1), 09-Окт-26, 09:51	+26 +/–
Хлебом не корми - дай да выпилить что-нибудь что не сломано и жить не мешает.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #4, #20, #31, #74

2. Сообщение от A.Stahl (ok), 09-Окт-26, 09:54	+24 +/–
>жить не мешает приводит к значительному снижению производительности... не сочетается с некоторыми возможностями...и мешает реализации новой функциональности
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #8, #10, #11, #26, #122, #126, #149

3. Сообщение от Аноним (3), 09-Окт-26, 09:56	+/–
>по сравнению с режимами "data=ordered" и "data=writeback" Ну, writeback, вообще, опасная штука. Такое себе решение дропать журналирование... Сами себе палки в колеса. Я хз, какая там доля ext4 на серверах, но теперь вообще будет 0.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #127

4. Сообщение от iPony128014 (?), 09-Окт-26, 09:57	+7 +/–
У диванных анонимов так всегда... Для них код как шкаф, который стоит в углу и никому не мешает. Но такое не так часто.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #34, #123

5. Сообщение от Другой аноним (?), 09-Окт-26, 10:07	+1 +/–
Если прочитать получше - журналирование никто дропать не собирался. Дропают только режим полного журналирования вместе с данными, а не только метаданными - так никто не делает, ни на NTFS, ни на ext4.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #6, #14, #18, #66

6. Сообщение от Аноним (3), 09-Окт-26, 10:10	–5 +/–
Да, не подумал, что дети на тех.форуме под новостью о полном журналировании в коменте смогут увидеть что-то другое кроме полного журналирования. Именно это и имелось в виду: полное журналирование. Внезапно. Прости, что дропнул это слово. Ведь речь именно об этом в новости. Рукалицо бл. У меня в проде это критично ибо есть некоторые технические нюансы и требования.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #23, #35, #49, #91

7. Сообщение от Аноним (7), 09-Окт-26, 10:12	+3 +/–
>Кроме того данная опция не сочетается с некоторыми возможностями, такими как отложенное выделение блоков (delalloc) и прямой ввод/вывод А может лучше оставить пользователю выбор? Или новый функционал, или полная устойчивость системы? >мешает реализации новой функциональности в Ext4 Зачем нужно менять именно Ext4? Пускай новый функционал реализуют на уровне VFS.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #32, #151

8. Сообщение от Kilrathi (ok), 09-Окт-26, 10:12	+12 +/–
Если б "мешает реализации новой функциональности" было про "мешает внедрению copy-on-write" - это одно, а вырезать у фс единственный отказоустойчивый режим до/без внедрения альтернативы...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #70, #113

9. Сообщение от Аноним (9), 09-Окт-26, 10:12	+/–
Подождите... "в журнал записываются не только метаданные, но и сами данные" разве не приведет к дублированию всех данных на диске и занимаемого места?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12, #13, #16, #78

10. Сообщение от Аноним (10), 09-Окт-26, 10:13	+1 +/–
>приводит к значительному снижению производительности Если она не нужна. Опция она для этого и существует. >не сочетается с некоторыми возможностями Вот это уже политическая борьба внутри системы. Потребителя не спрашивают. Либо круг потребителей противоречивый. >мешает реализации новой функциональности Ну сейчас модно новое ради нового. План по новому - новое по плану.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

11. Сообщение от Аноним (11), 09-Окт-26, 10:15	+4 +/–
> приводит к значительному снижению производительности... не сочетается с некоторыми возможностями... и ... обеспечивает высокую устойчивость в случае сбоев. ПС. Сам пользуюсь этой опцией чуть ли не с самого начала. Жаль :(
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #19

12. Сообщение от Кирилл (??), 09-Окт-26, 10:16	+4 +/–
Может дублироваться, но только до момента подтверждения записи всей транзакции на диск (т.е. данных), после этого блоки журнала переиспользуются
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

13. Сообщение от Вацлав (?), 09-Окт-26, 10:17	+1 +/–
приводит
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #15

14. Сообщение от Kilrathi (ok), 09-Окт-26, 10:17	+1 +/–
Вообще-то полное журналирование есть в ufs через geom под "фрёй"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #36, #75, #135

15. Сообщение от Аноним (11), 09-Окт-26, 10:21	+/–
Ложь. Размер журнала фиксирован, он не увеличивается и не уменьшается. Увеличивается только количество записей на диск.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #54

16. Сообщение от Аноним (16), 09-Окт-26, 10:29	+/–
Приводит. Но обычно для этого используют отдельный SSD накопитель.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #290

17. Сообщение от Аноним (17), 09-Окт-26, 10:29	+1 +/–
>но усложняет сопровождение кода Но ведь сейчас ИИ из всех утюгов с историями успеха по сопровождению кода, как это может быть аргументов в 2026 году ?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #25

18. Сообщение от sabitov (ok), 09-Окт-26, 10:29	+2 +/–
А Вам не доводилось сталкиваться с потерей данных на ФС из-за падения питания? А у меня такое былО, когда в либцэшных .so файлах оказался мусор, а система не бутилась. Я с тех пор XFS не использую :) ХЗ, что там за прошедшие 25 лет поменялось :)  И мне пофиг, будет у меня сервер писать 300Мб/с или 250, главное, чтобы при любых раскладах данные не корёжились
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #24, #28, #29, #46, #119

19. Сообщение от Kilrathi (ok), 09-Окт-26, 10:30	+1 +/–
Классика opensource: либо брать на себя поддержку режима, либо переходить на cow в zfs/btrfs (если производительность позволяет), либо компромиссить на xfs
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #97, #189

20. Сообщение от опеншлёпивпродакшн (?), 09-Окт-26, 10:33	+1 +/–
Если противников наберётся достаточно - форкнут ext4 и будут сами поддерживать. А если не наберётся, то это ты один такой особенный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #42, #116

23. Сообщение от Другой аноним (?), 09-Окт-26, 10:43	–2 +/–
Не нравится - используй btrfs, которая для этого и создавалась, полная транзакционность за счёт copy-on-write. Данные гарантированно или записаны целиком, или не записаны совсем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #30

24. Сообщение от онанист (?), 09-Окт-26, 10:53	+1 +/–
приходилось на райзере лет так 27 назад :-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

25. Сообщение от Аноним (25), 09-Окт-26, 10:55	–1 +/–
Сопровождает. Успешно. Не бесплатно. Крупные корпы сидят на xfs и btrfs (судя по rhel и suse). Ну, возможно, кто-то ещё на zfs. А ext4 - удел подкроватных сисадминов с mdadm raid, которые даже не в курсе что такое тихие ошибки и data-integrity.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #41, #333

26. Сообщение от Аноним (26), 09-Окт-26, 10:55	+1 +/–
Простое же решение, в данном случае. Нужен максимум производительности - не включай data=journal, нужна повышенная надёжность - включай.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #152

27. Сообщение от RM (ok), 09-Окт-26, 10:58	+5 +/–
читая новость, приходит только одна мысль, про "неосилили".
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #110

28. Сообщение от Аноним (3), 09-Окт-26, 11:05	+1 +/–
>сталкиваться с потерей данных Я думаю, все с этим сталкивались, кто более-менее с компами работает и имеет опыт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

29. Сообщение от Другой аноним (?), 09-Окт-26, 11:07	–2 +/–
> либцэшных .so файлах оказался мусор Больше похоже на коррапшен данных по вине диска, не запарковавшего голову, чем на последствие (не)журналирования. Если, конечно, падение питания не произошло в аккурат во время обновления пакета libc, но тут даже журналирование не даст никаких гарантий, потому что если файл наполовину записался - то журнал откатит только половину блоков и получится всё равно битый файл. В итоге, печально, но судя по всему, большинство присутствующих даже не понимают, как именно работает механизм журналирования ФС.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #38, #40, #44, #71

30. Сообщение от Аноним (3), 09-Окт-26, 11:09	–1 +/–
>btrfs На домашней машинке как раз это со снапшотами. Хорошая вещь. Но проды ведь бывают разные. И такие, где ты не можешь просто так взять и перевести всю инфру. Да и не имеешь привелегий принимать подобные решения, к сожалению.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #133, #196

31. Сообщение от q (ok), 09-Окт-26, 11:09	+5 +/–
> дай да выпилить что-нибудь что не сломано и жить не мешает Если код только добавлять, но никогда не удалять, то любой проект становится unmaintainable, подумай об этом. Как говорил Хемингуэй (или кто там), "идеал -- это не когда больше нечего добавить, а когда больше нечего удалить". Добавлять код легко. Удалять крайне сложно: тут же выскакивают возмущенные пользователи, которые этим не пользовались, но выскочить и возмутиться хочется. За ними следуют разъяренные начальники, которые настроили метрики КПД по кол-ву добавленных строк, но не удаленных. Также обижаются разрабы оригинального кода: "э, слыш, я в одна тысяча девятьсот лохматом году этот код месяц писал. Целый месяц писал! А ты его щас так просто удаляешь? Пойдем выйдем, раз-на-раз побормочем." Добавлять код -- это бездумно идти за стадом, сохранять статус-кво, моя хата с краю, "я тут фичу сделяль, влейте". Удалять код -- это по-настоящему смелый мужской поступок, на который решится "не только лишь все". Чтобы удалить код, требуется качество, отсутствующее у многих: умение задавать вопрос "а нахрен нам эта хрень вообще упала?"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #61, #150

32. Сообщение от Скрудж (?), 09-Окт-26, 11:12	–3 +/–
> Или новый функционал, или полная устойчивость системы? Ну так не обновляй ядро, и тебе не будет нового функционала и сохранишь полную устойчивость систему
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #45

33. Сообщение от Аноним (34), 09-Окт-26, 11:14	+1 +/–
> но усложняет сопровождение кода Печально что ядродевелоперы даже с помощью ИИ не могут осилить сопровождение собственного кода.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #39, #105

34. Сообщение от Аноним (34), 09-Окт-26, 11:30	+10 +/–
у диванных проггеров так всегда... Для них код как шкаф, в котором ничего нельзя найти т.к. полки устарели. Но такое довольно часто.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

35. Сообщение от Аноним (35), 09-Окт-26, 11:40	+/–
И как часто в ваш прод попадает свежайшее ядро я кернел орг? Не знаю такого дистра для прода в котором будет 7.3 и выше раньше чем через 2-3 года.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

36. Сообщение от пох.. (?), 09-Окт-26, 11:40	+1 +/–
c silent data corruption works as intended, не забывай уточнять. потому что журналирование в обход фс и невидимое для нее - всегда вот этим и заканчивается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

38. Сообщение от пох.. (?), 09-Окт-26, 11:46	+1 +/–
> В итоге, печально, но судя по всему, большинство присутствующих даже не понимают, как > именно работает механизм журналирования ФС. ты вот, к примеру - кажется, не совсем понимаешь. Что на то и журнал что половина блоков не может записаться. Транзакция либо закрыта, либо нет (и будут заново записаны и те блоки что уже один раз записались и все остальные, либо ничего). (Ну, в предположении что автор писалки тоже не совсем дол... и дергает fsync/dsync прежде чем рапортовать об успешном успехе - журналу тоже откуда-то нужно узнать, *что* именно тут - транзакция. Держать целиком все данные до закрытия файла он не сможет, потому что файл может закрыться и через пару лет.)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #51

39. Сообщение от пох.. (?), 09-Окт-26, 11:47	–1 +/–
там как надо девелопер, старик а все сам делал. Ну вот поэтому такие и пироги.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #136

40. Сообщение от Аноним (40), 09-Окт-26, 11:53	+/–
В Unix/Linux любые обновления файлов делаются путём создания в том же каталоге (или в той же ФС) нового файла, а далее - атомарной операции rename. Никто не открывает на запись действующую .so-шку (да это и невозможно просто так, файл залочен операционкой). Вот удалить его можно, и переименование с удалением тоже возможно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #50, #53, #128

41. Сообщение от Аноним (35), 09-Окт-26, 11:54	+3 +/–
ext4 замечательно работает поверх железных рейдов. там все нормально и с тихими ошибками, и резервированием, и проверками на фоне и тд. и даже с пропавшим питанием, если вдруг на ибп пожмотились. речь не про интеловские интеграшки разумеется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #184

42. Сообщение от Аноним (42), 09-Окт-26, 11:54	–1 +/–
> Поддержку данной опции монтирования намерены прекратить в 2028 Люди и дистры просто будут массово сидеть на LTS вышедшем перед проблемной сборкой 2028, пока окончательно не прижмёт. Т.е. аж до самого 19 января 2038, а то и дольше
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #106

43. Сообщение от Аноним (-), 09-Окт-26, 11:55	+/–
>Опция "data=journal" включает режим полного журналирования, при котором в журнал записываются не только метаданные, но и сами данные, что обеспечивает высокую устойчивость в случае сбоев, но усложняет сопровождение кода Пыцаны btrfs же есть. Зачем из ext4 делать btrfs, или я что-о путаю?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #48, #65, #137

44. Сообщение от Аноним (35), 09-Окт-26, 11:58	+/–
xfs действительно страдал всяческими пропажами при упавшем питании (ядра тогда крэшились тоже частенько, но не про это речь). в нулевых xfs можно было использовать только строго с ибп, это было само собой разумеющимся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

45. Сообщение от Аноним (7), 09-Окт-26, 12:08	+2 +/–
Все новости про уязвимости ядра мимо тебя прошли, да?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

46. Сообщение от Аноним (46), 09-Окт-26, 12:10	–2 +/–
Xfs вообще интересная в плане багов, занулять рандомные файлы тоже любит и никак это не исправят до конца. Ext4 может повредить открытый на запись файл при data=writeback, но это надо, чтобы звёзды сошлись. После того, как она сотни внезапных отключений энергии подряд переживала без заметных последствий (худшее кэши браузера повреждаются и пару раз экстеншены браузера пришлось обнулить), у меня нет сомнений в её надёжности. Главное, fast_commit не включать, или придётся ждать часами пока убитый журнал регенерирует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #77

47. Сообщение от Аноним (46), 09-Окт-26, 12:13	+/–
Скорее всего это чатботы шалят опять. Ну конечно, будто в ext4 всё остальное работает. У неё куча ограничений и ограничения data=journal не самые худшие (особенно, если они задокументированы).
Ответить | Правка | Наверх | Cообщить модератору

48. Сообщение от Аноним (48), 09-Окт-26, 12:14	+1 +/–
Должен остаться только ntfs3g и fuse.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

49. Сообщение от похнапоха (?), 09-Окт-26, 12:27	+/–
В продакшене для отказоустойчивости используют надежные СХД с поддержкой (внезапно?) соответствующих потребностям уровней RAID, а так же в дополнение к этому используют метро-кластеры, если данные действительно важные. ext4 в продакшене с опцией data=journal для хранение данных - это баловство, можешь просто использовать пяти дюймовые дискеты для таких данных.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #85

50. Сообщение от Другой аноним (?), 09-Окт-26, 12:38	–1 +/–
По хорошему - да, через rename. И поэтому ситуация, как у автора вызывает больше вопросов, чем ответов. rename - это операция с метой, которая идёт через журнал, даже если data=journal нет. При этом оно /должно/ было случиться уже когда данные в новый .so уже записаны. И уж точно, даже без журнала на ext4 не мог побиться файл, в который не писали. Поэтому либо автор рукоспинствовал, и сделал rename перед записью, после чего писал .so в чистый файл, либо (намного вероятнее) это data corrupt на уровне диска, от которого всё равно никакой журнал не спасёт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

51. Сообщение от Другой аноним (?), 09-Окт-26, 12:43	–1 +/–
Ситуация, описываемая автором настолько странная, что там либо кривая писалка была, которая после каждого блока fsync'ала, либо (что вероятнее) это было повреждение данных на уровне HDD, от которого журнал никак бы не спас, ибо оно не для этого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #52

52. Сообщение от пох.. (?), 09-Окт-26, 12:54	+/–
не, ну можно ж вообще не фсинкать? а я хрен знает как всякие dpkg принято было писать в том самом ламповом 93м. Файл открываем сразу тот который обновляем, никаких этих вам mkstemp/rename, читаем откуда-то пишем куда-то вперемешку, чтоб шибкоумная фс не могла предугадать наших действий, надо быть непредсказуемым для противника, где-нибудь по дороге еще тупим (например потому что чтение подзависло на фоне записи), прилетает внезапное отключение электричества - проооофит! с повреждениями на hdd у нас все плохо с тех пор как секторные метки начали записывать вместе с данными - будет сбойный сектор, а это слишком заметно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

53. Сообщение от пох.. (?), 09-Окт-26, 12:57	+/–
> В Unix/Linux любые обновления файлов делаются путём создания в том же каталоге хачю - делаю, не хачю - не делаю! И чо ты мне сделаешь, я вообще в другом городе! Вот за такими нехачухами тут надысь километр кода пришлось перебирать, потому что система которая должна была гарантировать надежность данных - внезапно, как оказалось, вообще ничего не гарантирует да еще и в упор не видит потери. Вот то самое хрестоматийное - "а зачем нам коды возврата printf?" вишенкой на тортике. (хенд мейт между прочим, трю органик, не нейрослоп какой! Вполне вероятно у кого-то до сих пор в проде.)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #102

54. Сообщение от пох.. (?), 09-Окт-26, 12:58	+/–
> Ложь. Размер журнала фиксирован да вроде нет? Ты с journal inode не перепутал?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #289

56. Сообщение от pfg21 (ok), 09-Окт-26, 13:03	+2 +/–
интересно какой процент возмущающихся и почему использует журналирование содержимого в своей практике ??
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #62, #120

57. Сообщение от Аноним (57), 09-Окт-26, 13:06	+1 +/–
Выкапывайте стюардессу! JFS всмысле.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #59, #60, #82

59. Сообщение от Аноним (59), 09-Окт-26, 13:21	+/–
Что-то,. помню, она ломалась при любом нештатном выключении питания, требуя ручного запуска fsck после.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

60. Сообщение от Аноним (60), 09-Окт-26, 13:24	+/–
NILFS!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #79

61. Сообщение от пох.. (?), 09-Окт-26, 13:27	+/–
> Чтобы удалить код, требуется качество, отсутствующее у многих: умение задавать вопрос "а > нахрен нам эта хрень вообще упала?" главное задавать его с безопасной дистанции - чтоб тебе при этом не задали встречный - а нахер ТЫ нам, отважный удаляльщик, упал?! И да, в эпоху ыы безопасной дистанции "вообще в другом городе" может неожиданно перестать хватать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #95

62. Сообщение от пох.. (?), 09-Окт-26, 13:33	+/–
ну мы когда-то давно обсуждали перспективу хранилки с быстрым ssd (сейчас бы это был наверное dm mirror поверх nvme) для журнала. Т.е. синхронная запись почти мгновенно приземляется в журнале, и возвращает ок, а переписыванием на медленную основную фс мы занимаемся асинхронно и никому не мешаем, данные уже один раз сохранены. Но по факту разумеется все выбрали готовые промышленные схд. А поверх ext4 nojournal.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #112

63. Сообщение от Аноним (34), 09-Окт-26, 13:34	+/–
Арчеводы не согласны! https://wiki.archlinux.org/title/Ext4#Disabling_journaling > Use the journal to optimize performance
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #67, #73

65. Сообщение от Метрика (?), 09-Окт-26, 13:44	–3 +/–
Есть две работающие ФС это NTFS и ZFS, все остальное это попытка студентов в ФС, не более чем
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #109

66. Сообщение от Метрика (?), 09-Окт-26, 13:49	+/–
Это называется резервным копированием так то, а журналирование это сохранение всех inode файла, чтобы можно было найти его данные на диске, если их не затерли конечно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

67. Сообщение от Аноним (46), 09-Окт-26, 13:50	+1 +/–
Сколько не замерял, то, что они предлагают только снижает общую производительность раз в 10. Больше слушайте этих домохозяек.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

68. Сообщение от EuPhobos (ok), 09-Окт-26, 14:03	+3 +/–
Почему не сделаю ext5 если ломают обратную совместимость?! Что за идиотизм..
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #114, #138

69. Сообщение от DEF (?), 09-Окт-26, 14:23	+/–
Теодор Тцо, разработчик ext4, рекомендует переходить на Btrfs, как на более продвинутую и современную ФС.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #72, #76, #80, #84, #88

70. Сообщение от Аноним (70), 09-Окт-26, 14:31	–6 +/–
> а вырезать у фс единственный отказоустойчивый режим до/без внедрения альтернативы... Бггг. Ну вы ж по иному не возжелаете поработать для гугля и эй-би-эм б̵е̵с̵п̵л̵а̵т̵н̵ы̵м̵и̵ ̵т̵е̵с̵т̵и̵р̵о̵в̵щ̵и̵ка̵м̵и̵ для (более экзотических) сценариев бтрфс, будете на своем замшелом ext4 сидеть до посинения! А так вроде бы и причин больше не останется особо луддитствовать - шо там, шо там данные при жестком сбое могут помахать ручкой, так пусть хотя бы на более современной файлухе! Ведь режим data=journal гуглу, фейсбуку и прочим платиновым спонсорам никуда не сдался, у них надежность сохранения данных либо на другом уровне обеспечивается, либо "да и крен с этими данными, еще раз своих котиков загрузят".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

71. Сообщение от Аноним (71), 09-Окт-26, 14:32	+/–
У меня была такая же проблема на ноуте, только там был NVMe от Samsung, Evo 970 вроде бы. Так же поставил ноут обновляться, всё скачалось, началось распаковываться, но происходило это очень медленно. Никаких ошибок в dmesg не было. После ребута нихрена не запустилось, потому что все файлы, в бут разделе в том числе (FAT32), оказались размером 0. Я грешу на фейл проца либо чего-то на материнке, что создаёт коррапт памяти (такое в ноутах делл было со сломанной клавиатурой, а на моём финке как раз у клавы кнопки коротить начали на мембранке), потому что потом с ноутом были такие же проблемы из разряда "чё этот прид*рок делает" и замена диска и плашек оперативки не помогла.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

72. Сообщение от Аноним (72), 09-Окт-26, 14:36	+/–
Значит теперь будут искусственно кастрировать другие файловые системы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #89

73. Сообщение от Аноним (71), 09-Окт-26, 14:40	+/–
Во-первых, "Use the journal to optimize performance" - это следующий пункт, сразу после того на который ты ссылку скинул. Во-вторых прочитай что ты скинул. Там сравнение идёт между "data=journal" и дефолтным "data=ordered".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

74. Сообщение от Аноним (74), 09-Окт-26, 14:52	+2 +/–
Тебе прямым текстом сказали что сломано и жить мешает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #104

75. Сообщение от Аноним (74), 09-Окт-26, 14:56	–2 +/–
В UFS кривейший механизм soft updates, который так и не сделали нормально, а журналирование в geom отдельное от ФС разваливается при первом попадении питания, да так что fsck падает на unexpected soft update inconsistency и файловой системы считай что больше нет. Но какой идиот будет под FreeBSD использовать не ZFS.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #94

76. Сообщение от Аноним (76), 09-Окт-26, 14:57	+/–
Потом выйдет EvenBetterFS и все дружно на неё переходить будем?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #86, #96

77. Сообщение от Аноним (74), 09-Окт-26, 14:58	+1 +/–
> тоже любит и никак это не исправят до конца Что значит "исправят"? У них в FAQ написано что это бай дизайн
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #108

78. Сообщение от Аноним (74), 09-Окт-26, 14:59	+/–
Записать нужно два раза, да, но копию в журнале после подтверждения записи можно больше не хранить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

79. Сообщение от Tron is Whistling (?), 09-Окт-26, 15:01	+/–
devnullfs
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

80. Сообщение от Аноним (42), 09-Окт-26, 15:51	+/–
Но на неё забил редкат?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

82. Сообщение от Аноним (48), 09-Окт-26, 16:10	+1 +/–
Ее корпораст пилил, она работает. Только фсчек надо из чрут запускать, а то ридонли станет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

83. Сообщение от Инопланетянин (?), 09-Окт-26, 16:13	+/–
> Опция "data=journal" включает режим полного журналирования, при котором в журнал записываются не только метаданные, но и сами данные, что обеспечивает высокую устойчивость в случае сбоев Получается журналирования данных не будет или есть какая-то другая опция?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #92, #158

84. Сообщение от Аноним (48), 09-Окт-26, 16:13	+1 +/–
На СистемД перевели и тут никуда не денуться. Организация одна и та же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

85. Сообщение от пох. (?), 09-Окт-26, 16:24	+/–
> В продакшене для отказоустойчивости используют надежные СХД лучше - сразу облачка, на которых восседает святой дух! (внезапно, чтобы твои данные добрались до супернадежной [тоже нет] схд - они проходят даже не через одну, а иногда аж через 3 fs - включая и обычную ext4. И да, на КАЖДОМ из этих этапов неуклюжее обращение с данными может что-то испортить.) главное ж веровать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #93, #118

86. Сообщение от Аноним (86), 09-Окт-26, 16:26	+/–
Есть же bacachefs. Лучшая ФС. Жаль только выпилили побоявшись конкуренции.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76

87. Сообщение от Cyber100 (ok), 09-Окт-26, 16:32	+2 +/–
удалить журналирование, которое каждый по желанию мог отключать сам == это гипер-сильно. и на каких таких скоростных устройствах кто-то там заметил якобы тормоза от создания записей транзакций...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #99

88. Сообщение от Аноним (57), 09-Окт-26, 16:35	+/–
А на ней система за 2 секунды загружается? А файлы там сами себя пишут, сами проверяют контрольные суммы, а фс это типа композитор?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #125, #139

89. Сообщение от Аноним (89), 09-Окт-26, 16:36	–1 +/–
Именно, в этом и смысл
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #130

91. Сообщение от Аноним (91), 09-Окт-26, 16:58	–1 +/–
> У меня в проде это критично ибо есть некоторые технические нюансы и требования. Ну раз критично аж в проде, то пиши скорее в lkml, предлагай проспонсировать сохранение опции. Это опенсорс, детка, тут никто никому ничего не должен, тут либо сам пишешь что надо, либо ешь что дают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #190

92. Сообщение от Аноним (92), 09-Окт-26, 17:02	–1 +/–
Да, не будет. Чтобы клиенты начали покупать специализированные средства.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83

93. Сообщение от похнапоха (?), 09-Окт-26, 17:03	+/–
Кроме вафли на ONTAP, чего они не скрывают и о чем гордятся, в остальных случаях корпоративные СХД - это простое блочное устройство, с собственной реализацией структур метаданных (конечно ведь снимки как-то должны работать) и тд, но называть это ФС - глупо. А ext4 на СХД - это для iSCSI, что в корпоративном секторе редкость, либо какой-нибудь NAS, что достаточно популярно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #182

94. Сообщение от Kilrathi (ok), 09-Окт-26, 17:11	+/–
> В UFS кривейший механизм soft updates, который так и не сделали нормально, Вроде как проблемы были в ранних версиях su, а позже поправили (но сам еще со времен 4ки привык ufs без su, а в десятках уже перешел на zfs, так что спорить не буду - ufs + su в проде не гонял) > журналирование в geom отдельное от ФС разваливается при первом попадении > питания, да так что fsck падает на unexpected soft update inconsistency > и файловой системы считай что больше нет. А это наглядный пример поговорки "если не RTFM, то ССЗБ" - использование одновременно SU и gjournal ;) Это все равно что под данные прода брать ssd без plp. Либо мета+данные чисто на журналировании geom без SU, либо SU+J только метаданных средствами фс без geom. Перепроверился по букварю: https://docs.freebsd.org/en/articles/gjournal-desktop/ Key characteristics of GEOM journaling: ... Disables Soft Updates ... Технически они могут работать одновременно, но... > Но какой идиот будет под FreeBSD использовать не ZFS. Ответ был на "Дропают только режим полного журналирования вместе с данными, а не только метаданными - так никто не делает" Не смотря на то, что  еще 5+ релизов назад gjournal назвали устаревшей после полноценного внедрения zfs, ufs geom все до сих пор в актуальном generic-релизе. Плюс не стоит забывать про зависимость от производительности: для какой-нибудь домашней файлопомойки на бюджетном одноплатнике с попыткой использовать кучу сервисов/функций в режиме "640кб ОЗУ хватит всем": ufs с geom-журналированием для защиты мета+данные может оказаться более интересной, чем zfs cow.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #101

95. Сообщение от Аноним (95), 09-Окт-26, 17:24	–3 +/–
> главное задавать его с безопасной дистанции Зачем? Потому что т#пого б@дла аргументов нет и в ход пойдут кулаки? Ну так да, лучше с такими говорить с безопасной дистанции.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #98, #103, #159

96. Сообщение от Аноним (95), 09-Окт-26, 17:30	+/–
> Потом выйдет EvenBetterFS и все дружно на неё переходить будем? А почему бы и нет? Вам цифорка 4 в Ext4 ни на что не намекает?)) Если будет лучше - то разумеется перейдем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76

97. Сообщение от Аноним (-), 09-Окт-26, 17:40	+/–
> Классика opensource: либо брать на себя поддержку режима, либо переходить на cow > в zfs/btrfs (если производительность позволяет), либо компромиссить на xfs Если вас XFS устраивал то EXT4 тоже так то наверное с теми неполными режимами журнала - пойдет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #100

98. Сообщение от Аноним (11), 09-Окт-26, 17:52	+/–
> лучше с такими говорить с безопасной дистанции. Зачем вы вообще хотите с такими говорить? Чтоб продемонстрировать им, что они такие а вы не такой?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95

99. Сообщение от пох.. (?), 09-Окт-26, 18:28	–2 +/–
тормоза как раз на медленных устройствах - буквально вот 8x write amplification вместо 4x у обычной ext4. И решалось это выносом лога на сверхбыстрый носитель. Но, кстати, верю что там тоже код тяпляпаный и скорость nvme используется только на треть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87

100. Сообщение от Kilrathi (ok), 09-Окт-26, 18:38	+/–
> Если вас XFS устраивал то EXT4 тоже так то наверное с теми > неполными режимами журнала - пойдет? Если просто в лоб сравнивать ext4 и xfs в режиме "сферического коня в вакууме": для меня, субъективно, xfs "интереснее". Если же подбирать не в режиме "ок-по-дефолту", а смотреть по платформе и задачам - уже большая вариативность, не ограничивающаяся этими двумя. На большинстве используемых мною сейчас систем руты на ext4 и ffs, данные на btrfs и zfs. В частности/конкретных примерах: на домашнем бюджетном бесшумном минипк под микросервисы система на ext4, виртуалки на xfs, а флешка с бакапами на exfat; на основном пк calibre с зеркалом Флибусты в f2fs, а хостинг служебных ro демо-баз, вообще, в tmpfs...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97 Ответы: #131

101. Сообщение от Аноним (70), 09-Окт-26, 18:52	+1 +/–
>> В UFS кривейший механизм soft updates, который так и не сделали нормально, > Вроде как проблемы были в ранних версиях su, а позже поправили (но Я другой аноним, но у меня "кривейший" + SU ассоциируется лишь c режимом SU+J. Там да, долго (до 2022) не работали те же снапшоты, как врочем и фоновый fsck. Сам SU как концепт был неплох и даже элегантен, там ведь (если я за давностью лет ничего не путаю) корректность/атомарность записи метаданных подтверждалась  записью последнего блока - если она не удалась, то "ничего не было", метаданные оставались в консистентном состоянии, а fsck нужен был лишь чтобы удалить мусор и работал в фоновом режиме (что для UFS+J сделали емнип уже сильно потом). Но сам SU (при этом, емнип, избегающий использовать "лишние" синки) сильно зависит от сохранения очередности записи ... и тут "оптимизирующая" для более лучших показателей в бенчах фирмварь диска, меняющая последовательность записи (Write Cache Reordering, NCQ и че там еще как раз с начала 2000х появилось) на "как быстрее" - может очень нехило подна*ть. К самому SU без журналирования у меня никаких нареканий не было и нет. Чексуммы метаданных, ino64 (inode на 64 бита, штоб точно хватило на все) долго доходили, зато тот же TRIM, причем с обобщением (consolidation) уже давно есть - в отличие от той же ext4, где это прикрутили только как continuous (что может выдать разом пару тыщ TRIM запросов к накопителю при удалении пары сотен мб).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94

102. Сообщение от Аноним (91), 09-Окт-26, 19:00	+/–
> за такими нехачухами тут надысь километр кода пришлось перебирать Ну не тебе ж пришлось, а агенту. А ему вообще без разницы, он железный. Ты там небось сидел и лениво пальчиком тыкал в ответы: это хочу, это не хочу, и вообще работай на другом хосте, не шуми мне тут вентилляторами. > "а зачем нам коды возврата printf?" вишенкой на тортике. Всегда ли должна функция что-то возвращать, и всегда ли нужно это проверять -- классика, академики ещё в 70х не одну пивную кружку об голову собеседника расхерачили в пылу спора на эти темы. И только потом переключились на algol или lisp, emacs или vim, unix или cp/m.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #107

103. Сообщение от Аноним (103), 09-Окт-26, 19:00	+2 +/–
Пишите ваш код так, словно его будет сопровождать после вас маньяк знающий где вы живете (с) дейкстра. Дебилов-удаляльщиков "я не пользуюсь - значит никто не пользуется" только так и можно учить не лезть своими ручонками туда, куда не просят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95

104. Сообщение от Аноним (103), 09-Окт-26, 19:00	–3 +/–
Навешали лапши на уши а ты и рад слушать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #121

105. Сообщение от Аноним (103), 09-Окт-26, 19:02	+/–
Не "не могут", а "не хотят" очевидно. Почему - отдельный вопрос.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

106. Сообщение от _ (??), 09-Окт-26, 19:17	+4 +/–
Нет не будут! Они и не такое-на-лопате жрали, жрут и будут жрать. К чему иллюзии то?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

107. Сообщение от пох.. (?), 09-Окт-26, 19:21	–1 +/–
> Ну не тебе ж пришлось, а агенту. да он, сссскотина, вопросы какие-то задает... а я ж не настоящий сварщик, я б вообще рад это развидеть нахрен! но printf он красиво объехал, я не уверен что сам бы сообразил а не стал бы просто все переделывать заново. (про printf нифига не фигура речи - там реально был printf)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102

108. Сообщение от пох.. (?), 09-Окт-26, 19:26	+1 +/–
>> тоже любит и никак это не исправят до конца > Что значит "исправят"? У них в FAQ написано что это бай дизайн да это просто местный гений-самоучка без мотора очередной фуфел нашел и без конца про него вспоминает. Наверное бэкап не делал и ценный ридмитхт потерял. На ext4 в этом файле просто окажется мусор или не окажется самого файла если до барьера попал. Первое гораздо хуже чем очевидно обнуленный файл. И лечится это правильным написанием кода - вот с теми самыми fsync ДО делания действий которые этот файл считают достоверным, а не чудесами фс.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

109. Сообщение от пох.. (?), 09-Окт-26, 19:28	–1 +/–
> Есть две работающие ФС это NTFS и ZFS, все остальное это попытка > студентов в ФС, не более чем одна, к сожалению. ТОЙ zfs уже двадцать лет как тоже нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #111, #191, #199

110. Сообщение от _ (??), 09-Окт-26, 19:32	+4 +/–
А у меня почему то про "сахар в бензобак"(С) :( яЪ - ну чё им бтрфс для опытов не хватало? :(
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #174

111. Сообщение от _ (??), 09-Окт-26, 19:34	+/–
Ну ежели так, то и XFS _той_ нет столько же :(
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109 Ответы: #115

112. Сообщение от _ (??), 09-Окт-26, 19:36	+/–
bcachefs ... но аффтЫрь чего то того ... :(
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #117

113. Сообщение от User (??), 09-Окт-26, 19:38	+/–
Если в части "отказоустойчивости" вы полагаетесь на ФС - вы уже очень сильно обо...клались, вот
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #132

114. Сообщение от _ (??), 09-Окт-26, 19:39	+1 +/–
Почему - почему ... по - плану!(С) :(
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

115. Сообщение от пох.. (?), 09-Окт-26, 19:43	+/–
та была образцовым копропродуктом поздних 80х, в ней как раз ничего хорошего и не было, ну может кроме идей чуть лучше чем идей extfs из 70х. насколько хороша та что есть сейчас, существенно переписанная рабами ibm в 2010-2014м - не уверен, поскольку в уже переписанной видел те же глюки что видел в 2009м.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111 Ответы: #141

116. Сообщение от User (??), 09-Окт-26, 19:43	+/–
Ждите девуанный форк, ага!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

117. Сообщение от пох.. (?), 09-Окт-26, 19:45	+/–
> bcachefs ... но аффтЫрь чего то того ... :( я показывал ссылку на статью 12го года про bcache без fs. Все плохо. С этим автором каши не сваришь. только storage space direct спасет мир. Может быть. (но говорят что как раз это место в ней лучше обходить горными тропами)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112

118. Сообщение от User (??), 09-Окт-26, 19:51	+/–
Ну, внезапно если тебе нужно надёжное хранение данных, то избыточность, ec и вот это всё ты закладываешь вот - на уровне данных, нет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #134

119. Сообщение от User (??), 09-Окт-26, 19:56	+/–
Ну а беда-то в чём? Ну выпала нода из кластера, и? Или то ЕДИНСТВЕННЫЙ сервер был, второй под кровать не влез?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

120. Сообщение от User (??), 09-Окт-26, 20:11	+/–
Да вот как будто бы и пофиг уже. Вона, даже в postgresql чексуммы на уровне страниц в 18 версии по дефолту включили. Во всяких block storage навроде недоброй памяти minio erasure coding И избыточность по дефолту, в кафке crc аж в двух местах (но надо знать нюансы), в nosql consistency level На чтение/запись почитай с самого начала - и примерно пофиг, что там под седалищем лежит - нижний слой по определению не надежен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #145

121. Сообщение от Аноним (74), 09-Окт-26, 20:11	+/–
Мне обоснование для удаления кода вообще не нужно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104

122. Сообщение от Кирилл (??), 09-Окт-26, 20:44	+1 +/–
...решается реорганизацией кода с сохранением отдельной подверсии/подрежима. В котором все конкурирующие опции отключены. Очевидно режим максимальной надёжности это не про ускорение с отложенными операциями.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

123. Сообщение от Кирилл (??), 09-Окт-26, 20:47	+/–
Странно, но когда то существовал такой термин как legasy-код, из которого состояло 70++% всего софта и на протяжении примерно 30 лет разработчики каким то образом умели с этим работать, получалось быстро, надёжно, дёшево и функционально. Потом ещё научились делать это безопастно. Ну а потом пришли новые "разработчики" и решили исправить "быстро, дёшнво, надёжно" да и собственно "работать".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #148, #284

124. Сообщение от Аноним (124), 09-Окт-26, 20:48	+2 +/–
Ext4 - журналируемая файловая система. Начиная с ядра 7.3 не журналируемая. Как теперь её описывать - Ext4 - журналируемая файловая система до ядра 7.2 включительно. Полужурналируемая система. Недожурналируемая система. Все кто против - старые пердуны, луддиты ретрограды. Главное первым начать громко и чётко стигматизировать тех кто против. Часто вспоминаю времена, когда перешли на Ext4 после Ext2... эх.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #140, #179

125. Сообщение от _ (??), 09-Окт-26, 20:54	+/–
Не важно. Не тебе решать что в линуксе юзать. И не мне. Да и * с ним! (C), ну что ж поделаешь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88

126. Сообщение от Аноним (126), 09-Окт-26, 21:24	+2 +/–
>>жить не мешает > приводит к значительному снижению производительности... не сочетается с некоторыми возможностями...и > мешает реализации новой функциональности Для реализации новой функциональности следует пилить EXT5 или ещё какую-нибудь вундервафлю! А EXT4 как раз и выбирают, среди прочего, в том числе и потому, что она уже устоялась, настоялась и никакие грязные ручонки там ничего "прорывного и фичастого" не пилят, в том числе потому, что "Опция "data=journal" включает режим полного журналирования, при котором в журнал записываются не только метаданные, но и сами данные, что обеспечивает высокую устойчивость в случае сбоев". EXT4 не выбирают, потому что она более быстрая и фичастая, а как раз за то, что она надёжная и консерватиная - читай её никакой оболтус не шатает и не ломает. А если надеть шапочку из фольги, то данная инициатива вообще больше похожа на саботаж, типа: "А давайте мы зacpём EXT4, авось на наши альтернативы охотнее будут переходить, потому что на фоне новой фичастой EXT4 они будут уже получше выглядеть!"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #147, #227

127. Сообщение от Аноним (127), 09-Окт-26, 21:41	+/–
> Ну, writeback, вообще, опасная штука. Ничего там опасного нет вообще! Но только, если в программе правильно расставлены write и fsync. Во времена внедрения режима writeback оказалось, что мало кто вообще знает как надо использовать fsync правильно. И вот тут повылезали ошибки с "обнулением файлов", появилась инфа про небезопасность режима writeback и костыль от Теодора для быстрого детекта опасный ситуаций и отключения delayed allocation (которое не будет так часто приводить к появлению битых файлов). Проблема действительно была проблемой, т.к. вылезло в kde3 (уже после последнего релиза kde3), откуда она пришла из Qt3 (а в то время уже вовсю был Qt4 и Qt3 патчить никто не собирался). В torrent-клиентах разных тоже вылезало и ещё много где (в основном редакторы, кажется даже в StarOffice 1.x было).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

128. Сообщение от maximnik0 (?), 09-Окт-26, 22:22	+/–
>Никто не открывает на запись действующую .so-шку (да это и невозможно просто так, файл залочен операционкой). Эта возможность опция, можно блокировку отключить.А юзер файлы записать без блокировки - вообще штатная возможность (root превелегии) .Да и samba тоже может писать без losk файла если это нужно.Механизм простой : записываться новый файл - старый файл помечается как удаленный- но пока дескрипторы заняты, не удаляется.Поэтому через отладку возможно файл восстановить - где то даже howto было на примере видиофайла который проигрывает mplayer  ,а каталог удалили.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

129. Сообщение от ятупойтролль (ok), 09-Окт-26, 22:40	+1 +/–
а в чем проблема сделать ext5? религия не позволяет? нужно сломать то, что уже работает у миллионов людей?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #167, #330

130. Сообщение от yylloc (-), 09-Окт-26, 23:14	–1 +/–
> Именно, в этом и смысл Но где? APFS не загнулась, NTFS тоже. Хотя, не о тех вспомнил. Начинаем: NILFS, QIC, 9fs, NFS, eroFS, exFAT, F2FS, ZFS. Да даже FAT32. Продолжать можно долго, это ещё BSD не упоминаю. btrfs чем так ужасна? Насчёт слишком раннего выпиливания - полностью согласен. ext4 должна умереть в январе 2038, как и огромное количества не критической legacy инфраструктуры.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89 Ответы: #142

131. Сообщение от Аноним (132), 09-Окт-26, 23:34	+/–
> На большинстве используемых мною сейчас систем руты на ext4 и ffs, данные на btrfs и zfs. Что еще за ffs бжд?! Это какой-то ископаемый, из древних юниксов? Necromancy is a forbidden art! И так то система на btrfs - весьма удобна. Нормальными снапшотами, а заодно и проверкой целостности что в случае глюков хардвара хотя-бы подхайлайтит с фиги ли тут глюкало ором в логи задолго до этого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100 Ответы: #146, #163

132. Сообщение от Аноним (132), 09-Окт-26, 23:35	+1 +/–
>  Если в части "отказоустойчивости" вы полагаетесь на ФС - вы уже очень > сильно обо...клались, вот О том что стратегии можно при наличии головы совмещать и оптимизировать - клиенту Accenture никто разумеется не рассказал. И правильно, не гоже себе и коллегам бизнеса портить, немамонт должен - доиться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113 Ответы: #154

133. Сообщение от Аноним (132), 09-Окт-26, 23:39	+/–
> На домашней машинке как раз это со снапшотами. Хорошая вещь. Но проды ведь > бывают разные. И такие, где ты не можешь просто так взять и перевести всю инфру. > Да и не имеешь привелегий принимать подобные решения, к сожалению. А если б даже и имел - случаи бывают разные. Скажем нагруженный БД на cow класть ну такое себе. Можно nocow на ее файлах врубить но тогда большая часть фишек отвалится. И если это был основной сценарий появится вопрос - а за что мы собссно боролись? Перфоманс - просадили, ибо оверхеда все же больше. А взамен с nocow в комплекте ... что? В общем серебряных пуль все же не бывает. Если кто утверждает обратное, обойдите его стороной - пули у него из другого материала.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #181

134. Сообщение от пох. (?), 09-Окт-26, 23:40	+/–
нет, потому что тогда тебе придется эти данные писать на raw носитель. И то - исключительно в надежде что ну хоть вот фирмварь для самого ссд все же написана нормально. А то ты избыточность, ec, вот ето все - а там подтверждение записи до самой записи. И твои избыточные данные - прикрытая несходящимся ec тыковка. В схд замногоденях тоже нет никакого прямого канала между памятью твоего докера в докере и носителем. А есть та самая ext4 где-то под слоем оверлейфсов, возможно поверх виртуального диска какой-нибудь вмвари, поверх фс уже самой вмвари, которая создана вон там на схд (у которой хотя и не "настоящая" но тоже фс а не прямой доступ к накопителю). Отдельные уровни этой этажерки можно пропускать, но надо хорошо понимать зачем и чем это грозит, а в целом - не рекомендовано. И _каждый_ из этих уровней должен гарантировать тебе что записанное с fsync - доехало до носителя и будет оттуда прочитано. (и в идеале бы - что записанное без fsync все равно доедет до носителя хотя бы в большинстве случаев. Потому что fsync стоит дорого. Поэтому вот существуют barriers, тоже по всей этой иерархии.)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118

135. Сообщение от Аноним (132), 09-Окт-26, 23:41	–1 +/–
> Вообще-то полное журналирование есть в ufs через geom под "фрёй" Вот только кому весь этот адский кластерфак сдастся и зачем?...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

136. Сообщение от Аноним (132), 09-Окт-26, 23:44	+/–
> там как надо девелопер, старик а все сам делал. > Ну вот поэтому такие и пироги. Если это про Теодора - он уже давно всем объяснил что гальванизировать ЭТО - смысла вообще осталось довольно мало. А уж сильно развивать или там EXT5 какое - забудьте про это. Если кому next gen хочется, это не ext5 а скорее структуры как в bcachefs и проч. И Тсо об этом уже тоже догадывается. Как и разработчики btrfs с своими новыми деревьями и проч.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #144

137. Сообщение от Аноним (132), 09-Окт-26, 23:46	–1 +/–
> Пыцаны btrfs же есть. Зачем из ext4 делать btrfs, или я что-о путаю? Btrfs не делает двойную запись при сохранении семантики примерно равной полному журналу. А вот EXT4 очень даже - поэтому сабжевой фичой мало кто пользуется: больно уж это тормозит. В случае настоящих CoW фокус в первом приближении в том чтобы журналом сделать всю площадь вообще. Тогда комитить в основную область не придется за ее отсутствием. Такой вот нахальный чит. Даже работает в целом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #143, #178

138. Сообщение от Аноним (132), 09-Окт-26, 23:47	–2 +/–
> Почему не сделаю ext5 если ломают обратную совместимость?! Что за идиотизм.. Теодор Тсо предельно ясно высказался по этому поводу. Если ты святее папы римского - сам и девелопай.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #161

139. Сообщение от Аноним (132), 09-Окт-26, 23:51	–5 +/–
>  А на ней система за 2 секунды загружается? Две не две а одноплатник с 1ГГЦ 1 ядерным 32 бит процом секунд за 5 подымается. С системдой, ога. При том половину занимает декомпресс ядра и проч. Если скорость монтирования btrfs важна - его надо делать с block group tree. Можно его потом отрастить, требует ядро 6.1 или новее. Так он маунтится... чуть не быстрее сабжа. А если сабж еще и крешнулся и там fsck... ух... ну запустите это на винче терабайт на 5 забитом, посмотреть как вам идея fsck такой шляпы вообще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88

140. Сообщение от Аноним (132), 09-Окт-26, 23:52	–1 +/–
Вообще XFS тоже такой полунедожурналируемый. Как и JFS какой. Полный журнал на классике - пишет данные два раза и это комбо посему тормозит как апокалиптец.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124 Ответы: #157

141. Сообщение от Аноним (132), 09-Окт-26, 23:54	+/–
А чего такого хорошего в блочнике-переростке с типа-переменными блоками для галочки? Сделанным ТАК по причине "мы так привыкли и этот паттерн нас не подводил"? Перфоманс таких структур и оверхед всего этого на современных SSD с зиллионами iops и gbps вызывает у энтерпрайзников только печальку. И никак это особо не починится уже. Этот мир просто изменился. Сети и IO приблизились к процам по скорости.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115

142. Сообщение от Аноним (72), 10-Окт-26, 00:01	–2 +/–
>Начинаем Всё это сторонние фс в линксе не являются конкурентами btrfs. >btrfs чем так ужасна? https://lkml.org/lkml/2010/6/3/313
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130 Ответы: #239

143. Сообщение от пох.. (?), 10-Окт-26, 00:22	–1 +/–
>> Пыцаны btrfs же есть. Зачем из ext4 делать btrfs, или я что-о путаю? > Btrfs не делает двойную запись при сохранении семантики примерно равной полному журналу. У нее нет ничего похожего на полный журнал, и она делает не двойную а примерно 16рную. > В случае настоящих CoW фокус в первом приближении в том чтобы журналом > сделать всю площадь вообще. Тогда комитить в основную область не придется > за ее отсутствием. Такой вот нахальный чит. Даже работает в целом. нет. журнал либо есть либо его нет вообще. У btrfs его, можно считать, что нет. Зато есть 32-64x оверхед на запись единичного блока.  И конечной точкой являются стопиццот копий суперблока, каждую из которых надо обновить чтобы запись одного байтика можно было считать подтвержденной. У ext4 даже с data=journal оверхед минимум вдвое меньше, потому что данные обновляются в том же месте где были, поэтому не надо корректировать указатели на эти данные и указатели на указатели.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #237

144. Сообщение от пох.. (?), 10-Окт-26, 00:37	+/–
> Если это про Теодора - он уже давно всем объяснил что гальванизировать ЭТО - смысла > вообще осталось довольно мало. ну так - складывай дедуля полномочия - и выметайся. Устал - уходи. Но нет. Денежки платиновых спонсоров будет тянуть до могилы. А разработчики btrfs рабы другого хозяина, и делают то что велит тот хозяин (и ничего не собираются чинить за что тот не платит). А ему твои данные нафиг не упали, новых еще быстрее накачаешь, заодно будет куда новую рекламу насовать. > Если кому next gen хочется, то пусть сам его прдлит как умеет. Получится что-то съедобное - приходит, нет - следом за бкэшем строем на йух. А пока неплохо было бы не ломать то что _работает_ (пусть и не у миллионов, тут аноним лоханулся, у миллионов работает совершенно дурацкий data=ordered, гарантирующий ровно ничего и при этом тормоз. А, прастити - быстрый fsck он гарантирует, да. С неконсистентыми данными. Но быстро!)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136 Ответы: #234

145. Сообщение от пох.. (?), 10-Окт-26, 00:46	+/–
> Да вот как будто бы и пофиг уже. Вона, даже в postgresql > чексуммы на уровне страниц в 18 версии по дефолту включили. И что будем делать если чексума не совпала - встанем колом и будем ждать бэкап? > Во всяких block storage навроде недоброй памяти minio erasure coding И избыточность тоже не для этого. это дублирование данных на случай отказа носителя. А не потери управления в момент записи. В этом минио точно так же полагается на xfs. Попытки все слепить в одного монстра - это недоброй памяти ceph. Вот там все в одном, и база данных на raw части носителя, и block storage прямо в физические блоки диска. И неотвратимый п-ц всему, потому что сделать надежно там даже и не думали, да и было им нечем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120 Ответы: #153

146. Сообщение от черпало (?), 10-Окт-26, 00:56	+2 +/–
>  btrfs - весьма удобна ты восстанавливал сломанную фс? или оно удобно, пока проблем нет? если да, то давай встретимся, принесу тебе мертвый ссд с этой заячьей лупой удобной, запишу подкаст про тебя, как ты там все поправил и восстановил?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131 Ответы: #210

147. Сообщение от черпало (?), 10-Окт-26, 01:00	+/–
> EXT4 не выбирают, потому что она более быстрая Отчего так думаешь? она как раз самая быстрая (настоявшаяся, отполированная), даже если смотреть по количеству инструкций/цпу тайм, я (и не только) замерял и выбирал. Это тебе и простой гуглёж скажет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126

148. Сообщение от derfenix (ok), 10-Окт-26, 01:48	+/–
Интересно даже, что же изменилось за 30 лет, да....
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123 Ответы: #175

149. Сообщение от Аноним (149), 10-Окт-26, 04:30	+1 +/–
> приводит к значительному снижению производительности... А оно включено по умолчанию?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #162

150. Сообщение от Аноним (149), 10-Окт-26, 04:36	+1 +/–
Тонна бесполезной словесной софистики. Удалять нужно не рабочее, сломанное, а не то что работает и даже полезно но ты в это не можешь поэтому это тебе не нужно, а так как ты это подавляющее меньшинство то ты решаешь за всех и делаешь. Остановите этот мир на минуту, я сойду.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

151. Сообщение от Аноним (149), 10-Окт-26, 04:41	+/–
Свобода выбора, в свободном софте?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

152. Сообщение от ананим.orig (?), 10-Окт-26, 05:28	–4 +/–
>нужна повышенная надёжность - Бери raid.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #226

153. Сообщение от User (??), 10-Окт-26, 06:46	+/–
> И что будем делать если чексума не совпала - встанем колом и будем ждать бэкап? Ээээ... Ну вот pgpro автоматически данные с реплики запрашивает, что не так? > тоже не для этого. это дублирование данных на случай отказа носителя. И для этого тоже. Он так-то data shards и parity shards разбрасывавет и из этой "parity" их вполне себе восстанавливает что "налету", что при ручном heal. Это не "n-копий файла" В общем-то.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145 Ответы: #164

154. Сообщение от User (??), 10-Окт-26, 06:47	+/–
... И натянул четвёртый слой резинотехнической защиты на свечку - ну, для НАДЁЖНОСТИ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132 Ответы: #208

155. Сообщение от Аноним (162), 10-Окт-26, 06:48	–5 +/–
Этот древний хлам вообще давно пора выбросить из ядра. Что заставляет людей при наличии таких фс как btrfs и zfs продолжать пользоваться откровенно отсталой ext4 одному богу известно.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #156

156. Сообщение от Аноним (158), 10-Окт-26, 07:10	+4 +/–
Толсто. Ext4 самая надёжная ФС.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #155 Ответы: #160

157. Сообщение от Аноним (158), 10-Окт-26, 07:13	+/–
>Полный журнал на классике - пишет данные два раза Ты выдумываешь. Такой классики не бывает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140 Ответы: #165, #264

158. Сообщение от Аноним (158), 10-Окт-26, 07:15	–2 +/–
Журналирование никуда не делась. Просто убрали не нужный функционал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83

159. Сообщение от Аноним (159), 10-Окт-26, 07:18	+1 +/–
То есть линксоиды новой волны считают всех заранее б...м с ск..м. И лучше знают что всем нужно методом запретов и удалений. Когда тоже самое делает госмашина они подпискивают и орут что они не такие снежинки, и так делать нельзя. Удивительное разложение мозга. Хотя чему тут удивляться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95

160. Сообщение от Аноним (162), 10-Окт-26, 07:51	–2 +/–
> Толсто. Ext4 самая надёжная ФС. Это пока у тебя при обновлении что-нибудь не сломалось, и толку тогда от этой надёжности? Снимков нет, контрольных сумм данных нет, возможности хранить чувствительные данные в нескольких образцах нет, возможности создания рейд-массива (хотя бы зеркала) нет. Хочешь рейд и контрольные суммы -- будь добр, городи многоэтажные костыли из кучи малосвязанных инструментов. Зато быстрая, ага.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #156 Ответы: #166, #212

161. Сообщение от EuPhobos (ok), 10-Окт-26, 08:21	+1 +/–
Всё отлично, но было бы хорошо, не получить мне сюрприз в самый неподходящий момент: В надежде, что у меня всё сработает, я записал кучу информации на HDD на ext4, и поехал с этим HDD к другому ПК, и при попытке смонтировать его там - получаю ошибку. А потом погуглив понимаю, что создал я ext4 на более новой версии, а более старая система, у которой rootfs тоже на ext4, она которая не может примонтировать мой HDD, потому что на нём ext4 созданная более свежими тулзами. И тут я понимаю, какой п#$%@ц тут происходит, когда у тебя система на ext4, не может примонтировать ext4
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138 Ответы: #168, #176, #263

162. Сообщение от Аноним (162), 10-Окт-26, 08:33	+1 +/–
Нет. Если включить на ext4 полное журналирование, то она по скорости приблизится к zfs. И усиление записи вырастет в 2 раза.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149

163. Сообщение от Kilrathi (ok), 10-Окт-26, 08:43	+/–
> Что еще за ffs бжд?! Это какой-то ископаемый, из древних юниксов? Под ряд сетевых задач крутятся OpenBSD более 10 лет и кушать не просят, просто, предсказуемо, стабильно и надежно. Все обслуживание сводится лишь к накатке обновлений и замене выходящего из строя железа.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131 Ответы: #211

164. Сообщение от пох.. (?), 10-Окт-26, 09:43	+/–
> И для этого тоже. нет. parity - на случай отказа _носителя_ и только для этого. При внезапном отказе питания/сбое ноды - оно полностью полагается на позикс семантику и надежность файловой системы, это принципиальное решение самого Бабу еще времен гластера. Что если fscync вернул управление - данные ТОЧНО уже на диске и ими можно пользоваться (поэтому не выделывайтесь, и пользуйтесь только xfs, только с ним они на самом деле тестируют и только для него будут подкладывать костылики и подпорочки). Иначе восстанавливать будет просто нечего. В том числе потому что метаданные тоже должны писаться гарантированно и до ответа ок в приложение. И так - по _всей_ иерархии хранения - во всяком случае, должно быть. Приложение-база или блокстор-диск под ним-диск под виртуализацией или что там тот диск имитирует-хранилка-диски самой хранилки. У тех у кого данные представляют хоть какую-то ценность. Потому что если ты все синкнул, а шибкоумный дисковод решил проигнорировать flush cache - результат тот же как если бы ты вообще все асинхронно писал, только еще и медленнее в разы. И проверки могут потом не сработать, потому что crc блока совпадет - потому что это другой какой-то блок либо уже удаленный сто лет назад, либо не туда записавшийся, но crc-то в нем ему соответствует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153 Ответы: #170

165. Сообщение от пох.. (?), 10-Окт-26, 09:46	–1 +/–
>>Полный журнал на классике - пишет данные два раза > Ты выдумываешь. Такой классики не бывает. бывает, гугли про log structured fs. Ну по дороге нагуглишь, конечно, почему бывает, но как динозавры примерно. В каких-то окаменелостях иногда находят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157 Ответы: #274

166. Сообщение от пох.. (?), 10-Окт-26, 09:51	–1 +/–
>> Толсто. Ext4 самая надёжная ФС. ну нет. Ладно б еще ntfs3g, скажем. Самая надежная - fat32. Максимальная избыточность метаданных, максимальная простота восстановления, обычно линейная запись. Ну есть и недостатки но они не в ненадежности. > Это пока у тебя при обновлении что-нибудь не сломалось, и толку тогда Как тебе удается при обновлении что-нибудь сломать и что ты там блин обновляешь?! > от этой надёжности? Снимков нет, контрольных сумм данных нет, возможности хранить опять эти свидетели контрольных сумм... да где вы берете такие проблемы, и почему ни один не смог ни разу хотя бы лог предъявить? (я уж молчу - провести _инженерное_ расследование инцидента) > чувствительные данные в нескольких образцах нет, возможности создания рейд-массива (хотя > бы зеркала) нет. Хочешь рейд и контрольные суммы -- будь добр, > городи многоэтажные костыли из кучи малосвязанных инструментов. Зато быстрая, ага. А рейд и контрольные суммы вообще нужны не всегда и частенько куча малосвязных инструментов в том и или ином виде и так в наличии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160

167. Сообщение от пох.. (?), 10-Окт-26, 09:55	–2 +/–
> а в чем проблема сделать ext5? религия не позволяет? гранты платиновых спонсоров не позволяют. Те не собираются вносить двойную оплату, а в виду шта6ле нонсенса - второй клон фс сам себя не поддержит. А дедушка стар и устал, он желает - в сортир. (на самом деле изрядно нае..лись с ext2 и потом ext3, это реально было крайне хреновое решение, и, поскольку гугль не собирался делиться патчами - проще было зак0пать, чем оживлять те трупики. А деду еще не было и 50, он был еще полон сил и энтузазизьма.)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129 Ответы: #308

168. Сообщение от пох.. (?), 10-Окт-26, 09:58	+/–
> И тут я понимаю, какой п#$%@ц тут происходит, когда у тебя система > на ext4, не может примонтировать ext4 МВАХАХХАХАХХА! и этот поц еще не в курсах про block size != page size А вот приехал бы ты к другу с ntfs - если у того не 98я конечно винда - все бы прочиталось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161 Ответы: #192

170. Сообщение от User (??), 10-Окт-26, 10:17	+/–
>> И для этого тоже. > нет. parity - на случай отказа _носителя_ и только для этого. Эээээ... там отдельно - highway hash для обнаружения и кодирование с избыточностью в рамках erasure set (Который у тебя вот не одна нода) для восстановления если что. _И_ обнаружение, _И_ самовосстановление. И нет, на надежность ФС под ней примерно пофиг И да, сценарий с "а теперь я чего-нибудь в данных на ноде ручками попорчу" я лично проверял - работает )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164 Ответы: #172

172. Сообщение от пох.. (?), 10-Окт-26, 11:08	+/–
ты неправильно проверял. Положи вместо чанка - другой чанк. Контрольная сумма - совпадет. ecc не совпадет но восстановить ничего все равно нельзя. И даже обнаружить проблему сложно. А именно это происходит если после крэша у тебя произвольный мусор вместо даных (потому что произвольный мусор на диске забитом блокстором - будет в основном из бывших блоков и состоять - а у них все суммы сойдутся) Еще хуже будет - если что-то произойдет с xl.meta
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #170 Ответы: #177

173. Сообщение от Аноним (173), 10-Окт-26, 11:48	+/–
Подскажите, какая файловая система Linux лучше всего подойдёт для хранения данных на внешних / съёмных жёстких дискаx? Ну, и на флешках...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #185, #206

174. Сообщение от пох.. (?), 10-Окт-26, 12:16	+/–
> яЪ - ну чё им бтрфс для опытов не хватало? это кого надо нога. И они дедулю в свой огород подкармливаться пускать не собирались. А дедуле тоже ж хочется подачек от спонсоров и не вылететь в early retirement с невыплаченным моргиджем. Приходится изображать бурную деятельность там, где ему позволяют. Одна только надежда - что ыы поставит жырную точку на всей этой камарилье года через два.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110 Ответы: #186

175. Сообщение от Кирилл (??), 10-Окт-26, 13:16	+1 +/–
Изменились разработчики. Точнее их изменили менеджеры. Теперь на первом месте разработка ради разработки и график написания строк кода.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #148 Ответы: #213

176. Сообщение от Аноним (176), 10-Окт-26, 13:20	–1 +/–
> ext4, не может примонтировать ext4 ну это же было достаточно давно, хотя неприятно. посему у мну для хомяка ext3, а ext4 для системы...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161

177. Сообщение от User (??), 10-Окт-26, 14:04	+/–
> ты неправильно проверял. Положи вместо чанка - другой чанк. > Контрольная сумма - совпадет. > ecc не совпадет но восстановить ничего все равно нельзя. И даже обнаружить > проблему сложно. > А именно это происходит если после крэша у тебя произвольный мусор вместо > даных (потому что произвольный мусор на диске забитом блокстором - будет > в основном из бывших блоков и состоять - а у них > все суммы сойдутся) > Еще хуже будет - если что-то произойдет с xl.meta Ну, те-о-ре-ти-чес-ки возможность, что тебе отгрузят вот правильный datadir, правильный part правильного размера и даже набор блоков в нем с правильными контрольными суммами - но не все они вот именно от этого объекта/версии есть - но это скорее из разряда "если в слове хлеб сделать четыре ошибки - получишь слово пиво". И нет, с восстановлением-то как раз никаких проблем нет (да вот хоть бы и через пересоздание проблемной ноды) - а вот насчет своевременного обнаружения вопросики. Но тут уж если тебе _настолько_ важны не те данные, чтобы события с такой вот вероятностью обрабатывать - ты, наверное, контрольную сумму объекта перед записью в стор и сам посчитаешь с хоронением её куда-нибудь в диапазоне от S3'шных метаданных до отдельной базюли включительно, да? За одним и часть сценариев с повреждением-до-записи отсечёшь. А вот делать под этим всем бырбырбыр или там ext4 с тем вот журнальчиком ты не будешь, ибо производитель не рекомендует, а в случае с ext4 так и явно запрещает - minio записью сам управляет и O_DIRECT во всю использует. Ну и с xl.meta тоже не беда - там так-то кворум, эти типовые сценарии я тоже проверял ).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #172 Ответы: #188

178. Сообщение от Аноним (-), 10-Окт-26, 14:08	+/–
Btrfs имеет просто огромный оверхед. Нам просторах интернета даже исследование на эту тему встречалось... сравнение с ext4, xfs, zfs. Если мне не изменяет память, все очень плохо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #180

179. Сообщение от Аноним (-), 10-Окт-26, 14:20	–1 +/–
ZFS? Тут все честно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124 Ответы: #219, #261

180. Сообщение от Аноним (162), 10-Окт-26, 14:41	–2 +/–
Нет там никакого оверхеда, по крайней мере не при обычном повседневном использовании.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #178 Ответы: #238

181. Сообщение от bx (?), 10-Окт-26, 15:13	+/–
У меня диск отвалился, сильно много писал, китайчатина, если бы не btrfs, хрен бы чего поднял. 13 лет примерно самому старому снапшоту. Но пару раз сдыхал, да. Лечилось, без потерь пока.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133 Ответы: #230

182. Сообщение от bx (?), 10-Окт-26, 15:15	+/–
А что же там? Ну так, ради интереса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

184. Сообщение от bx (?), 10-Окт-26, 15:20	+/–
ИБП )) Аккумуляторные. И ДГУ. И нахер с пляжа всех энергетиков, если дгу не завелся в установленное время. РКН не двет булки расслаблять.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #232

185. Сообщение от пох.. (?), 10-Окт-26, 15:31	–2 +/–
размер дисков-то какой? И в чем цель хранения? А то в диапазоне от ntfs3g до fat32+mtools Зависит от того - тебе кинцо с десктопа до шибкоумного телевизора донести, свою нетленку на двести лет сохранить (но тут ты выбрал не те технологии вовсе), или ты с работы секретные доки тыришь. Или наоборот от налоговой прячешь...хотя да, причем бы тут линукс и его системы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #173

186. Сообщение от bx (?), 10-Окт-26, 15:35	–1 +/–
Через 2 - морда не треснет? Лет 5, если "друзья" не подключатся. Ну или мы объясним, что не стоит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #174

188. Сообщение от пох.. (?), 10-Окт-26, 15:40	+/–
> Ну, те-о-ре-ти-чес-ки возможность, что тебе отгрузят вот правильный datadir, в смысле? Это и есть то что гарантирует data=ordered Хватит одного случайно восстановившегося/смотрящего не на нужную иноду файлика. > И нет, с восстановлением-то как раз никаких проблем нет есть, потому что мы теперь не знаем на каком именно узле файл неправильный. ec на этот вопрос либо не отвечает вовсе, либо отвечает странным образом при n>=2 - декодировать _все_ возможные варианты, сравнить и выбрать единственный несовпадающий - это и есть правильный, а в остальные попал битый блок. Поэтому пользуйтесь xfs при всех ее минусах - да, ее фишка с обнулением сомнительных инод - именно для этого и затевалась. Теперь ты ТОЧНО знаешь какая копия битая и никак не сможешь незаметно использовать оттуда данные.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #177 Ответы: #220

189. Сообщение от Аноним (189), 10-Окт-26, 16:12	+/–
А как COW обеспечивает лучшую сохранность данных? Наоборот, если повредится блок - он может принадлежать нескольким файлам, значит можно одним повреждением запороть несколько файлов. Значит с COW сохранность данных как раз хуже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #225

190. Сообщение от пох. (?), 10-Окт-26, 16:19	+/–
> Это опенсорс, детка тут ты жрешь с лопаты то что одобрили платиновые спонсоры, и ничего кроме! (и нет, твои копейки тут ничего не изменят, их с радостью возьмут и подотрутся твоими хотелками)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #231

191. Сообщение от Аноним (162), 10-Окт-26, 16:32	+/–
Если не секрет, чем ТА zfs лучше ЭТОЙ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109 Ответы: #193, #235

192. Сообщение от Аноним (189), 10-Окт-26, 16:48	–1 +/–
Враньё. NTFS вечно меняет версию ФС втихую. И при подключении диска с новой NTFS в комп со старой виндой, ФС либо не читается, либо вообще весь комп выпадает в синий экран.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #168 Ответы: #207

193. Сообщение от пох.. (?), 10-Окт-26, 17:03	+1 +/–
там статья на пять страниц. неформат дляэтогосайта. Если готов сам разбираться - посмотри для начала вокруг abd.c вот ничего подобного в "той" - не было. И это вершина айсберга, под водой скрыты чудовищных размеров п-цы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #191 Ответы: #194, #214

194. Сообщение от Аноним (162), 10-Окт-26, 17:21	–2 +/–
Т.е. претензий по существу нет. Так и запишем...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #193 Ответы: #195, #244

195. Сообщение от пох.. (?), 10-Окт-26, 17:30	+/–
> Т.е. претензий по существу нет. Так и запишем... ты м-к, так и запишем. нахрен вот ты спрашивал если тебя вообще не интересовал ответ? Я тебе буквально ткнул пальцем в код, в самую его простую и обезьянами понимаемую часть. Но ты - т-пой м-к, и ты не умеешь читать и понимать код.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #194 Ответы: #197

196. Сообщение от Аноним (196), 10-Окт-26, 17:37	+1 +/–
Это наоборот к счастью, что умные дяди не разрешают тебе на бэтер переходить. А то еще чужие данные просохатишь
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

197. Сообщение от Аноним (162), 10-Окт-26, 17:38	+/–
Свой палец ты сам знаешь куда можешь засунуть. Своими словами ответь. Или настолько бухой что не можешь буквы на клавиатуре найти?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #195 Ответы: #198

198. Сообщение от пох.. (?), 10-Окт-26, 17:45	–1 +/–
> Свой палец ты сам знаешь куда можешь засунуть. Своими словами ответь. на х-й пошел! я не собираюсь общаться со свиньями. Я отвечаю людям в предположении что они - люди. Поэтому мой первый и последний ответ тебе был по делу. Если бы тебя действительно интересовало, что не так с современной zfs. И если бы ты даже не справился, но задал уточняющие вопросы - я бы подсказал. Но ты - т-пой м-к и тебе вовсе не это было интересно. И идешь на-й, ничего я м-кам объяснять не буду.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #197 Ответы: #202

199. Сообщение от Аноним (196), 10-Окт-26, 17:48	+/–
Да, одна! И это ext4 на raid6.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109 Ответы: #201

201. Сообщение от пох.. (?), 10-Окт-26, 18:09	–2 +/–
> Да, одна! И это ext4 на raid6. бльо... ну откуда ж вы лезете...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #199

202. Сообщение от Аноним (162), 10-Окт-26, 18:18	–1 +/–
Когда аргументов нет приходится переходить на оскорбления. Понимаю. Что ж, истерикой очередного пустозвона удовлетворён ))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #198 Ответы: #204

204. Сообщение от пох.. (?), 10-Окт-26, 18:36	+/–
> Когда аргументов нет Когда собеседник полный м-к и аргументы ему непонятны, и не за аргументами он приходил. Ему показывают где проблема - он хамит в ответ. Поэтому - пшел на-й!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #202

205. Сообщение от Аноним (205), 10-Окт-26, 20:48	+/–
до дропа слегка барахлящих жёстких дисков на всяких там пульсирующих аэрокулах 3... 2... 1... ждём разброса на индийских и сомалийских помойках электронного мусора а домой, похоже, придётся ставить redox, пока разрабы не пойдут ужинать с очередным баллмером
Ответить | Правка | Наверх | Cообщить модератору

206. Сообщение от Аноним (207), 10-Окт-26, 21:27    Скрыто ботом-модератором	+/–
NTFS
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #173 Ответы: #240

207. Сообщение от Аноним (207), 10-Окт-26, 21:29	+/–
Только вот диски, отформатированные ещё в XP, "почему-то" работают в "десятке" 🤦
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #192 Ответы: #218

208. Сообщение от Аноним (-), 11-Окт-26, 00:12	+/–
> ... И натянул четвёртый слой резинотехнической защиты на свечку - ну, для НАДЁЖНОСТИ. Ты не понял. Снапшоты в правильном CoW - значительно "дешевле" бэкапов и фигачить их куда ненапряжнее чем бэкапы. И времена восстановления - более другие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #154 Ответы: #216

209. Сообщение от Аноним (209), 11-Окт-26, 00:23	–1 +/–
Господи, разговоров-то. Будто каждый второй использует data=journal (возможно, эти же люди пытаются попутно выиграть чуть-чуть производительности с помощью mitigations=off, чтобы уравновесить зло добром).
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #241

210. Сообщение от Аноним (-), 11-Окт-26, 00:39	–1 +/–
> ты восстанавливал сломанную фс? или оно удобно, пока проблем нет? Я не занимаюсь "восстановлением сломанных фс" в общем случае. Компьютеры должны - работать, а не иметь мозг. Если сохранность ФС важна - я принимаю соотв. меры, как то - минимум DUP для метаданных. А лучше RAID1 - и в идеале и для данных тоже. И мониторинг логов чтобы сбойное железо не прохлопать клювами. И нормальное железо, а не смердящий мусор с опухшими кондерами которому пора на свалку - либо радикальный фикс. Если мне какие-то данные из сильно убитой ФС потребуются - я их "btrfs restore ..." выну вообще. Это альтернативный парсинг без монтирования с возможностью цеплять разные generation, ибо это - cow. Но вот именно чинить сильно раздолбаные тома - я это и для иных ФС не практикую так то. Была охота с глюками иметь дело. > если да, то давай встретимся, принесу тебе мертвый ссд с этой заячьей > лупой удобной, запишу подкаст про тебя, как ты там все поправил > и восстановил? У лично меня - оно почему-то за столько лет ни разу фатально не сдохло. Наверное я что-то делаю не так. Может я просто понимаю что и зачем делаю, а? И не юзаю откровенно глюкавое железо? А твои подкасты мне нахрен не упали. Я так в режиме полупро - data recovery с подубитых носителей прикалываюсь. И у меня уже есть стайка "прикормленных" знакомых которые в курсе что я норм делаю и несколько дешевле тематичной лабы. Но это вообще не основной мой род занятий. Но и в более "профильном" роде занятий (эмбедовка с линем) btrfs у меня тоже есть. Ибо - на ура на лету парирует единичный случайный бэд раз в эн лет на условной sd/eMMC - вместо позорного факапа загрузки системы и полного отказа девайса на ровном месте как EXT4 поганый. И да, представляешь, там некому колупаться в останках ФС! На серверах - аналогично. Да и на десктопе я ошметки колупать не хочу кроме самых крайних случаев. И я хочу видеть все это - как то так. Эти системы сделаны для того чтобы работать. А не для того чтобы чиниться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146

211. Сообщение от Аноним (-), 11-Окт-26, 00:44	–1 +/–
>> Что еще за ffs бжд?! Это какой-то ископаемый, из древних юниксов? > Под ряд сетевых задач крутятся OpenBSD более 10 лет и кушать не > просят, просто, предсказуемо, стабильно и надежно. Все обслуживание сводится лишь к > накатке обновлений и замене выходящего из строя железа. Будем считать что я предпочитаю более современные и простые в эксплуатации решения с более хорошими параметрами чем вон то. И почему-то это не мешает реализации примерно тех же паттернов и пожеланий.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #163

212. Сообщение от maximnik0 (?), 11-Окт-26, 01:14	+/–
>контрольных сумм данных нет Уже есть.Но костыльно - проверка только на чтение, есть специальная псевдо фс ,записывает методанные с контрольной суммой в скрытые файлы на существующию фс.Теоретически позволяет создавать КС для данных даже для фат.Костыли для снимков делали ,в основное ядро не пошло,аж два независимых проекта,лень вспоминать названия.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160 Ответы: #250

213. Сообщение от derfenix (ok), 11-Окт-26, 01:16	+/–
> Изменились разработчики. Точнее их изменили менеджеры. Теперь на первом месте разработка > ради разработки и график написания строк кода. Фух, ну слава богу.. А то я уж подумал, что требования к софту теперь не те, что 30 лет назад, как и сам темп разработки, диктуемый другим темпом жизни.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175 Ответы: #221, #293, #294, #295, #298

214. Сообщение от Аноним (70), 11-Окт-26, 01:43	+/–
> abd.c > вот ничего подобного в "той" - не было. И это вершина айсберга, Не, на чо - зато с ним, родимым, ZFS на малинке (причем, еще той самой) заработает! Не уверен, проверял ли кто-то, включая авторов этого драндулета.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #193 Ответы: #217, #256

215. Сообщение от Аноним (215), 11-Окт-26, 06:37	+/–
В плане устойчивости к внезапным выключениям ничего лучше NTFS не встречал. А Btrfs эта так вообще может сама по себе глючить.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #247

216. Сообщение от User (??), 11-Окт-26, 07:21	+/–
Оу. А для тех, кто считает "снапшоты" "бэкапами" в пятёрочке самая лагучая касса припасена.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #208 Ответы: #228

217. Сообщение от пох.. (?), 11-Окт-26, 09:24	–1 +/–
Mem: 25M Active, 101M Inact, 10M Laundry, 809M Wired, 34M Free ARC: 383M Total, 96M MFU, 146M MRU, 272K Anon, 9918K Header, 131M Other Swap: 1024M Total, 129M Used, 895M Free, 12% Inuse как видишь без него (ну почти, избавиться от нарезания всей памяти на 4k ломти невозможно уже в принципе, но самая хреновая деталь с еще и их последовательным перебором на каждый чих  тут отключена вручную) тоже могло бы работать - у поздних typeB было по 512 мег. тасамая даже наверное и помощнее будет чем эта виртуалочка (ядро тут тоже только одно) не уверен, стоит ли проверять, поскольку авторы драндулета абсолютно точно этого не делают, и если даже и соберется - совсем не факт что не посчитают тебе контрольные суммы задом-наперед. И если(когда) это выяснится - ты останешься с еще одним совершенно ненужным тебе знанием, которое прибавит тебе, конечно, любви и обожания к прогрессивному человечеству. (тоже вряд ли)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #214

218. Сообщение от пох.. (?), 11-Окт-26, 09:39	+/–
> Только вот диски, отформатированные ещё в XP, "почему-то" работают в "десятке" 🤦 и наоборот работают, повторяю - каждая первая флэшка больше 4 гигабайт с 12 по 18й годы. xp уже давно была антиквариатом (что не отменяло и даже увеличивало шансы что придется таки тащить на нее что-то на флэшке) И вероятно по сей день - каждый первый внешний жесткий диск на рынке. (давно не покупал новых, но вряд ли там exfat) Откуда, откуда они тут берутся да еще в таком количестве? Ну это ж в каком пузыре надо существовать, чтоб такое нести уверенным тоном?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #207

219. Сообщение от пох.. (?), 11-Окт-26, 09:43	–1 +/–
> ZFS? Тут все честно. там нет именно журнала данных. Там за счет структуры фс чуть лучше с гарантиями, но все зависит от аккуратности автора приложения. (и немножко от везения) Т.е. как раз читеры ;-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #179 Ответы: #275

220. Сообщение от User (??), 11-Окт-26, 09:57	+/–
> Хватит одного случайно восстановившегося/смотрящего не на нужную иноду файлика. Поигрался. Забавно, да. На single-node instance (все data-shards объекта доступны ноде, необходимости читать\считать четность нет) замена одного part.N другим приводит к выдаче поврежденного объекта. В multi-node замена "втупую" обнаружилась во всех тестах, а вот ручная замена одного EC-блока другим с корректным хешем обнаруживается с некоторой вероятностью (что именно поменяли - data shard или parity-shard, к какой ноде обратились, в какой фазе была луна и т.д.) и "с некоторой же вероятностью" heal'ится (Что прикольно - в старом формате хранения, где хеши болтались в xl.meta этой проблемы бы не было!). Насколько вот этот вот сценарий возможен\вероятен в реальной жизни - гадать не возьмусь. Неудобненько получилось в общем. > есть, потому что мы теперь не знаем на каком именно узле файл неправильный. ec на этот вопрос либо не отвечает вовсе, либо отвечает странным образом при n>=2 - декодировать _все_ возможные варианты, сравнить и выбрать единственный несовпадающий - это и есть правильный, а в остальные попал битый блок. Угу. "починить" не проблема - а вот найти, что чинить - таки да. Откуда будут читаться "не локальные" данные - не детерминировано. В изолированном окружении по десять запросов к каждой ноде проблему вполне себе локализиовали - а вот в большом кластере под нагрузкой - ну, удачи мне с этим не встретиться (С учетом выноса minio по лицензионным соображениям - уфф, пронесло!) ). > Поэтому пользуйтесь xfs при всех ее минусах - да, ее фишка с обнулением сомнительных инод - именно для этого и затевалась. Теперь ты ТОЧНО знаешь какая копия битая и никак не сможешь незаметно использовать оттуда данные. Ну так и пользовались же ж - пока тот minio жив был.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #188 Ответы: #233

221. Сообщение от Кирилл (??), 11-Окт-26, 10:15	+/–
А о каких таких требованиях к софту вы подумали? Кто требует выпускать новой версии андроида каждый год? Наверное это пользователи устроили митинг и под угрозой бойкота требуют переписывать весь плэймаркет по сути заново каждые 1,5-2 года? И вероятно это они же потребовали чтобы обновления андроида на устройствах приходили только на 20-30% устройств и в половине случаев приносили больше проблем чем затыкали дыр в безопастности, а о новом функционале речи в принципе не идёт уже давно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #213 Ответы: #245

222. Сообщение от Аноним (222), 11-Окт-26, 10:29	+/–
использую data=journal всегда и везде, производительность устраивает. они там о чем думают ломать надежный инструмент? давайте хоронить все что тормозит и плевать что это дает надежность, так?
Ответить | Правка | Наверх | Cообщить модератору

223. Сообщение от Аноним (222), 11-Окт-26, 10:32	+/–
безумие какое-то. с data=journal ext4 действительно надежная и быстрая fs. на что тогда уходить если отключат? ext4 по сути реинкарнация ext3 которая продолжение ext2 с журналом - оно развивается больше 20 лет - стабильно уже очень и очень что проверено и мной в куче установок и множеством людей. что еще настолько же стабильно и надежно?
Ответить | Правка | Наверх | Cообщить модератору

224. Сообщение от Аноним (222), 11-Окт-26, 10:34	+/–
скажем ACID не будет работать на 100% если fs не гарантирует консистентность. ext4 с data=journal консистентность гарантирует и они это хотят сломать???
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #236, #277

225. Сообщение от Аноним (-), 11-Окт-26, 10:53	+1 +/–
> А как COW обеспечивает лучшую сохранность данных? Наоборот, если повредится блок - > он может принадлежать нескольким файлам, значит можно одним повреждением запороть несколько > файлов. Значит с COW сохранность данных как раз хуже. Если это важно - надо избыточность юзать. При том если на "обычном" RAID1 у вас был условный EXT4 - ну вот видим мы 2 копии. Видим что данные там разные. Теперь вопрос на миллион: а какая из 2 копий - правильная?! В случае с btrfs (bcachefs, ...) - чексумирование фс интегрировано с управлением девайсами и оно знает что плохая копия - вон тот девайс, надо починить из вот этой копии (self heal). И вот так вот можно на лету востановить повредившуюся реплику из исправной. А обычный RAID1 такого не обеспечит. При расхожлении копий - вы не знаете какая верна и идете за бэкапом в общем то. А из сабжа + raid такое свойство извлечь? Да вы опупеете быстрее чем нарулите такое. Кстати с схемой DUP сие и на 1-дисковой конфиге работает, пусть и компромиссно (не спасет от полного отказа). Для сыпучих девайсов радикально разворачивает теорвер в правильную сторону.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #189

226. Сообщение от Аноним (-), 11-Окт-26, 10:54	+/–
>>нужна повышенная надёжность - > Бери raid. Вот уж блеснул экспертизой на весь опеннет! Raid у него журнал оказывается заменяет :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152

227. Сообщение от Аноним (-), 11-Окт-26, 11:04	+/–
> Для реализации новой функциональности следует пилить EXT5 или ещё какую-нибудь вундервафлю! Теодор Тсо прямым текстом сказал что никакого EXT5 делать не будет. Этот дизайн себя исчерпал. И по его мнению ФС будущего тоже - по лекалам btrfs/bcachefs/etc, а вовсе не. Потому что более перспективные паттерны дизайна. Если сильно убиваться - то уж над ними. > А EXT4 как раз и выбирают, среди прочего, в том числе и > потому, что она уже устоялась, настоялась и никакие грязные ручонки там > ничего "прорывного и фичастого" не пилят, в том числе потому, что > "Опция "data=journal" включает режим полного журналирования, ...который тормозит что п...ц - ибо двойная запись - так что мало кто вообще включает это. Он и ушел в режим заброшки. Но если ты вдруг реально нуждаешься в этом высунься и предложи себя как майнтайнера кода, кули. Или сиди на древних ядрах. LTS вон какой возьми и вот те стабильность. > раз за то, что она надёжная и консерватиная - читай её > никакой оболтус не шатает и не ломает. Интересно где это все кто-то кому-то гарантировал или хотя-бы обещал? > А если надеть шапочку из фольги, то данная инициатива вообще больше похожа > на саботаж, типа: "А давайте мы зacpём EXT4, авось на наши > альтернативы охотнее будут переходить, Пудем дропа полурабочей фичи с кучей проблем которые никто не фиксил? Интересный способ "засрать" что либо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126

228. Сообщение от Аноним (-), 11-Окт-26, 11:10	+/–
> Оу. А для тех, кто считает "снапшоты" "бэкапами" в пятёрочке самая лагучая > касса припасена. Этот тип начал о чем-то догадываться :). Эти технологии не заменяют друг друга а дополняют. Если у меня при апгрейде ОС/софта или сильной смене конфигурации что-то пойдет не так, я отыграю это за 2 минуты в вид как было 5 минут назад. А если у меня совсем железо разволилось, ФС в вермишель и проч - тогда я уже пойду доставать бэкапы, разумется. В чем профит? Я экономлю прилично времени и сил в первом варианте развития ситуации :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #216 Ответы: #229

229. Сообщение от User (??), 11-Окт-26, 11:18	+/–
... и натянул вот еще четвёртый, ага. Сыночка - эти вот твои аналоговнетные снапшоты перед выполнением потенциально проблемных операций обслуживания обеспечивает среда виртуализации - и да, при этом не приходится ронять в днину перформанс работы с БД, как в случае с "неимеющими аналогов в мире ФыСы". и нет, "бэкапами" это все еще не называют.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #228 Ответы: #252, #253

230. Сообщение от Аноним (-), 11-Окт-26, 11:21	+/–
> У меня диск отвалился, сильно много писал, китайчатина, если бы не btrfs, > хрен бы чего поднял. Я на нескольких особо сыпучих штуках по приколу btrfs разложил с DUP как данных так и метаданных. Не то чтобы этот фокус сильно рекомендуется к повторению - но так намного прикольнее в целом. В обычной ФС с 1 копией данных и метаданных: вы проигрываете если бэд попал под данные, а если под метаданные - вообще ДЖЕКПОТ! Правда со знаком минус. В случае DUP: чтобы "проиграть" надо чтобы сбойнул не только этот сектор - но еще и место куда записана вторая копия этого набора данных. Это уже произведение вероятностей. Если сбои относительно редкие - так намного веселее. > 13 лет примерно самому старому снапшоту. Но > пару раз сдыхал, да. Лечилось, без потерь пока. У меня как самый максимум 1 из суперов на флешке улетал после ее выдергивания без размонтирования. Но там есть опция использования запасных суперов. Восстановил с другого супера да дальше поехал. А так мне обещают что оно сдохнет, yada-yada, но толи я слишком хорошо понимаю дизайн фс и как железо работает, толи хз. Но оно не дохнет, хотя у меня куча инстансов уже. Какие-то проблемы оно испытывает только при откровенных сбоях оборудования. И даже так до того как испытать измеримые проблемы - долго орет в логи сбоями чексум. Что само по себе полезно - если меня предупредили что тут мины это совсем другой расклад чем бегать на удачу по полю без миноискателя, гадая есть ли там мины.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #181

231. Сообщение от Аноним (-), 11-Окт-26, 11:26	–1 +/–
> тут ты жрешь с лопаты то что одобрили платиновые спонсоры, и ничего кроме! У него выбор - шире чем у тебя, внезапно... ты то вообще выбираешь из 1 спонсора в лице муласофта который и сам не знает уже чего хочет. Кажется они доигрались до точки когда даже сами для себя не прочь на линух свалить, как минимум на своих же серверах. Потому что маркетинговый BS это прекрасно, но когда он начинает дурить своих же топов и стоить денег прям самому майкрософту - акционеры чем-то недовольны. И вот уже всякие баллмеры и гейтсы отправлены в почетную отставку. Конечно с золотым парашютом, если не всем самолетом, иначе остальные топы не поймут. Но - теперь дедушки все же будут -  развлекаться на своих островах или что там у них. И не будут влиять на решения компании. > и подотрутся твоими хотелками) Как ты с своим юниксвеем, приведшим тебя на виндузи? Так что ты эникей и в том и в другом оказался? Вот это я понимаю - фэйсом об тэйбл в своей IT карьере, поставив не на тех лошадей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #190

232. Сообщение от Аноним (-), 11-Окт-26, 11:29	–1 +/–
> ИБП )) Аккумуляторные. И ДГУ. И нахер с пляжа всех энергетиков, если > дгу не завелся в установленное время. РКН не двет булки расслаблять. Ага, сейчас тебе пох. еще расскажет как правильно нарулить упсу. Чтоб заметить что АКБ сдох - когда свет пропал. Вместе с ФС по закону подлости :).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #184 Ответы: #291

233. Сообщение от пох.. (?), 11-Окт-26, 11:32	+/–
такая же вот фигня. Поэтому надеемся на xfs, на которой такая подмена _вроде_бы_ невозможна, файл либо нулевой, либо правильный, либо предыдущей версии (чего быть не должно при правильной конструкции хранилки) А ее глюки на моем конкретном железе под хранилкой - пока - не всплывали. > Ну так и пользовались же ж - пока тот minio жив был. ща нам тут прибегут рассказывать как код с гитхаба никуда не испарился ;-) на самом деле он и теперь живее всех живых, а дядиных денег-то мне ничуть и не жаль. (импортозамечателям вот не повезло, их деньгов никто даже и не возьмет. придется самим.)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #220

234. Сообщение от Аноним (234), 11-Окт-26, 11:43	+/–
> ну так - складывай дедуля полномочия - и выметайся. Устал - уходи. Ну так ты ж на замену не пришел... если дедули уйдут - EXT4 совсем придется дропануть, как unmaintained код. В соответствии с полисями Linux. При том там дропают любой код на который забили кукуй. Независимо от того корпоративный он или нет. Какую-то экзотику для S390 чтоли тоже кто-то где-то дропал после того как на ене ibm забил. Могу приврать малость - ибо не слежу в деталях за этой платформой и читал ессно по диагонали. Но полися достаточно универсальна. Код без майнтайнера - имеет общее свойство: он оказался никому не нужен настолько чтобы притащить свою тушку и впрячься. > Но нет. Денежки платиновых спонсоров будет тянуть до могилы. Спонсоры обычно в состоянии найти денег на майнтайнеров и решать свои проблемы. Не трансформируя сие в проблемы проекта, майнтайнеров и Торвальдса. А если не могут - см выше, для них тоже работает :) > А разработчики btrfs рабы другого хозяина, и делают то что велит тот > хозяин (и ничего не собираются чинить за что тот не платит). Да вообще-то те господа по своим инициативам ряд вещей не особо нужных всяким мордокнигам все ж сделали. Но их главная проблема в том что они на uncharted area. Скажем эффективные RAID56-like с оптимизацией на CoW это в целом относительно малоиссдедованная область. И да, большей части корп нафиг надо оплачивать такие эксперименты за их счет - канители много, а отдача им малоинтересна. Потому что они даже лучше могли на более глобальном уровне инфры, где плюс-минус пару датацентров - не так уж и смертельно, пока вы в микродеталях ковыряетесь. > А ему твои данные нафиг не упали, новых еще быстрее накачаешь, > заодно будет куда новую рекламу насовать. А со своими данными я разберусь без "благодетелей" типа тебя. Тем более что разработчики btrfs у меня "at my fingertips" и если что - я скажу правильные волшебные слова, задам праильные вопросы и все будет хорошо. Более того. Если профак в смежной подсистеме ядра (да, и такое тоже бывает) меня не пошлют в пешее, и починят совместно. А ты настолько же эффективен с своими фетишами не будешь. А в ситуации типа последней смошешь только злобно шипеть что ядро не так и не сяк видите ли девелопают - но мою проблему не решишь вообше. И как максимум сможешь попытаться из меня сделать немамонта разведя на бабки в пользу майкрософтов или иной пропертари. Все это как ты понял мне нафи надо в таком виде - так что я лучше вон тем доверю тушку. Опыт эффективного и результативного работинга с ними у меня - есть. А от тебя я ничего кроме пафоса не видел. > нет - следом за бкэшем строем на йух. Бкеш на месте :). А бкэшфс - ну, э, Кентушка все ж как-то перестарался - начитывать лекции Торвальдсу на тему как ядро девелопать. И если вывод что процессы ядра не годятся для Кента - ну ок, значит он наруливает другие процессы. Не, семеро 1 не ждут и радикально ломать работавший десятилетиями процесс не будут. Потому что так можно продолбать не 1 ФС а вообще совсем все... > А пока неплохо было бы не ломать то что _работает_ (пусть и > не у миллионов, тут аноним лоханулся, Дык загружай ядро 2.6.32 и наслаждайся Финальной Стабилизацией :). Хотя MSDOS 3.30 надежнее в этом плане.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #144 Ответы: #242

235. Сообщение от Аноним (-), 11-Окт-26, 11:48	+/–
> Если не секрет, чем ТА zfs лучше ЭТОЙ? Раньше солнце было зеленей, трава светила ярче, и ZFS - вот лучше был. Ща, похонах протрезвеет и продолжит мыслю. Я попытался в его стиль на первых двух, но для ZFS пусть он сам опишет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #191 Ответы: #246

236. Сообщение от пох.. (?), 11-Окт-26, 11:59	+/–
> скажем ACID не будет работать на 100% если fs не гарантирует консистентность. > ext4 с data=journal консистентность гарантирует и они это хотят сломать??? если твой acid пишет транзакции printf'ом не проверяя возвращаемое значение - нет, тоже не гарантирует. Если правильно использует позик-семантику - даже data=writeback достаточно. data=journal ни разу не для этого. Не нужно его использовать, если не понимаешь, для чего оно. (реальных причин - крайне мало или вообще ноль - зависит от вещей которые нужно тестировать прежде чем бежать внедрять, и если это кто и делал - они результатами не поделились)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #224

237. Сообщение от Аноним (-), 11-Окт-26, 12:03	+/–
> У нее нет ничего похожего на полный журнал, Это лишь вопрос точки зрения. Т.е. механику commit/rollback можно видеть и эксплуатировать на довольно разных уровнях. И в конечном итоге прелесть CoW именно в том что они ЭТО могут без двойной записи. > и она делает не двойную а примерно 16рную. Ты забыл уточнить что это все - в маргинальных случаях типа БД каких. Которым вообще на самом деле raw device было а остальное они сами как им там надо - но вот админы плют кислотой с этого, менеджить капец неудобно, все дела. А если мы начнем на скорость записывать DVD-iso-sized файло - соотношения станут совсем иные. И EXT4 с полным журналом как-то совсем не круто там будет. >> за ее отсутствием. Такой вот нахальный чит. Даже работает в целом. > нет. Да. В случае именно btrfs я даже развил идею. И теперь "commit" и "rollback" могут быть - макроскопическими. Скажем "апгрейд системы на новую версию, 1500 пакетов своротить". Т.е. мне не надо потуги msi или rpm в их микротранзакции на уровне каждого пакетика и я могу 1500 пакетов вкатить в десять раз быстрее как "eatmydata apt <what>". Меня интересуют только старое состояние и новое, в промежуточных я копаться не буду все равно. И вот тут - снапшоты как "макро" транзакции для целей именно системного менеджмента как по мне так очень ничего. Я это и с VM практикую. И даже с целыми флотами VM. Я просто привел управление bare metal к похожим идеям. Неплохо работает. > журнал либо есть либо его нет вообще. У btrfs его, можно считать, что нет. Ты считать можешь что угодно, а с точки зрения апликух и апей все нормально и семантика всех вызовов - не хуже остальных работает. > Зато есть 32-64x оверхед на запись единичного блока. Но в среднем по больнице это меня - не парит. Сие проблема только для больших серверов БД и ряду иных специфичных нагрузок. А "в среднем" при переходе ext4 -> btrfs метрики моих тазиков типа (sectors written/month) мало изменились. Разница может 20-30%. И никаких 64x, внезапно. Наверное я юзаю ФС в более-менее типичном режиме а не worst case. И не упарываюсь огромными БД на CoW. Ибо серебряных пуль не бывает, и у всех дизайнов есть сильные и слабые места. > И конечной точкой являются стопиццот копий суперблока, Их там внезапно не 100500 - и кроме всего прочего - на странные случаи там есть свои оптимизации с таки всяким побочным журналированием. > обновить чтобы запись одного байтика можно было считать подтвержденной. У ext4 > даже с data=journal оверхед минимум вдвое меньше, потому что данные обновляются > в том же месте где были, поэтому не надо корректировать указатели > на эти данные и указатели на указатели. Теперь заменяем единичный блок на DVD-szied болванку - и получаем ровно обратные соотношения. И внезапно - никакого распухания записей в 64 раза. Надо же. Я конечно понимаю что подгонять решение под ответ твое все, но именно поэтому я еще и мониторю малость мои хосты и собираю "bean counters" чтобы не читать фантазии а вместо этого - ЗНАТЬ. Сколько и чего там в граммах было под МОИМИ сценариями. Что там твой сферический блок в вакууме делает - мне малоинтересно. Потому что это не мой сценарий.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143 Ответы: #249

238. Сообщение от Аноним (-), 11-Окт-26, 12:05	+2 +/–
> Нет там никакого оверхеда, по крайней мере не при обычном повседневном использовании. При обычном десктопном юзеже рост sectors written за скажем месяц - на btrfs vs ext4 ну может на 20-30% отличается в крейсерском режиме. И конечно никаких 64х и рядом нет. Так что если он проживет не 100 лет а "всего" 70 - я, наверное, переживу...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #180 Ответы: #243

239. Сообщение от Аноним (-), 11-Окт-26, 12:07	+/–
>>Начинаем > Всё это сторонние фс в линксе не являются конкурентами btrfs. >>btrfs чем так ужасна? > https://lkml.org/lkml/2010/6/3/313 Сведения 16-летней давности. Какая милота :). И главное - все эти говорящие головы забыли решения лучше выкатить. Так что могут идти обратно в свой телевизор.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142

240. Сообщение от пох.. (?), 11-Окт-26, 12:33	+/–
> NTFS подколка не засчитана. ntfs (и ntfs3g) хорошая фс, но у человека задача поставлена хоть и недостаточно четко, но - _хранение_ на _внешних_ носителях. А значит скорее всего - больше запси чем чтения (или чтения нет вообще), это очень плохой паттерн для ntfs3g и так себе для ntfs3 (остальные вовсе мертвенькими родились), и возможность повреждения при отключении. Возможно его задачи гораздо лучше порешает mtools и fat32. (и да, очень жаль что нет похожего для ntfs)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #206

241. Сообщение от пох.. (?), 11-Окт-26, 12:39	+/–
> Господи, разговоров-то. Будто каждый второй использует data=journal (возможно, эти же > люди пытаются попутно выиграть чуть-чуть производительности с помощью mitigations=off, > чтобы уравновесить зло добром). "когда они пришли за коммунистами..." а когда они придут сломать тебе твою любовно построенную этажерку (потому что могут!) - уже всем будет похрену.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #209 Ответы: #307

242. Сообщение от пох.. (?), 11-Окт-26, 13:04	+/–
> Ну так ты ж на замену не пришел... а что, кто-то звал? Там дедуля (на зарплате ibm, насколько я его мутные речи понял) был недоволен что ему неполиткорректно распугивают бесплатных тестировщиков и настройщиков интеграций. (Комитеры таки на зарплате тоже) > если дедули уйдут думаешь, зарплату поделят менеджеры звена повыше, и никому новому не передадут? В принципе, могут, конечно. > А со своими данными я разберусь без "благодетелей" типа тебя. Тем более что разработчики > btrfs у меня "at my fingertips" и если что - я скажу правильные волшебные слова "дам миллион"? Да откуда у тебя, фантазер. Да и тоже в общем ни о чем, у них одних долгов за недвигу на пять у каждого, им шта6ильные оклады подавай. Волшебный пендель им даст работодатель, и они с радостью и энтузиазмом разрушат то на чем ты построил свои системы. Потому что могут, а ты им никто и звать тебя никак. А ты все продолжаешь раздувать щечки и рассказывать как ты жрешь с лопаты и тебя все устраивает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #234 Ответы: #255

243. Сообщение от пох.. (?), 11-Окт-26, 13:12	–1 +/–
>> Нет там никакого оверхеда, по крайней мере не при обычном повседневном использовании. Вот у этого анонима лучше получилось - на 30 процентов! > При обычном десктопном юзеже рост sectors written за скажем месяц - на > btrfs vs ext4 ну может на 20-30% отличается в крейсерском режиме. показатели достигли потолка, с которого и были взяты? > И конечно никаких 64х и рядом нет. ты конечно - мерял? И можешь сейчас продемонстрировать методику измерения? (единственное с чем соглашусь - при обычном чтении опеннета и просмотре прона - современные носители как-нибудь справятся за приемлемое время, и выбор основан на других факторах)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #238 Ответы: #262, #269

244. Сообщение от Neandertalets (ok), 11-Окт-26, 13:17	–1 +/–
Если не становиться в позу оскорблённой невинности, то простой запрос к ДипСику даёт такой ответ: --- Сам по себе файл abd.c реализует ARC Buffer Data (ABD). Это не просто оптимизация, а смена парадигмы того, как кэш ARC (Adaptive Replacement Cache) хранит данные в памяти. Вот в чём суть претензии: 1. «Та» ZFS (Sun): простота через виртуальную память Изначально ZFS (в Solaris) использовала для буферов ARC обычную виртуальную память (vmalloc). Это было элегантно и работало на «родной» ОС (Solaris), где управление памятью было оптимизировано под такие задачи. 2. Проблема порта на Linux Когда ZFS портировали на Linux (ZFS on Linux, будущий OpenZFS), выяснилось, что ядро Linux не любит активное использование виртуальной памяти для таких целей. Это вызывало фрагментацию и проблемы с производительностью, особенно на 32-битных системах (где виртуальное адресное пространство ядра было сильно ограничено). 3. «ЭТА» ZFS (OpenZFS): сложность ABD Чтобы обойти ограничения Linux, разработчики создали ABD. Вместо одного непрерывного куска памяти теперь используются scatter/gather списки страниц (разбросанные по физической памяти куски). Это решило проблемы Linux, но породило архитектурную сложность: Код теперь должен уметь работать с двумя форматами буферов: Linear (для метаданных) и Scatter (для данных). Появились дополнительные структуры (abd_t), статистика, логика «сшивания» (gang ABD) и т.д.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #194 Ответы: #279

245. Сообщение от derfenix (ok), 11-Окт-26, 13:18	+/–
> А о каких таких требованиях к софту вы подумали? Кто требует выпускать > новой версии андроида каждый год? Наверное это пользователи устроили митинг и > под угрозой бойкота требуют переписывать весь плэймаркет по сути заново каждые > 1,5-2 года? И вероятно это они же потребовали чтобы обновления андроида > на устройствах приходили только на 20-30% устройств и в половине случаев > приносили больше проблем чем затыкали дыр в безопастности, а о новом > функционале речи в принципе не идёт уже давно. Да понял я уже, что во всём виноваты злобные менеджеры, которые спят и видят только, как бы простому пользователю подгадить, а пользователи такие "Нет! не надо нам новых фичей, пусть всё будет работать как работало ещё 15 лет!". Не ходят по форумам миллионы "а вот эту фичу почему не добавили?", "а почему на вот этой моей железке без спецификаций и из говна и палок собранной работает не так?", "АА! Вы сделали фичу как Вася просил, а мне она не нужна, оставьте поддержку и старого поведения!". Ну да, чего это я...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #221 Ответы: #299

246. Сообщение от Аноним (70), 11-Окт-26, 13:25	–2 +/–
> Раньше солнце было зеленей, трава светила ярче, и ZFS - вот лучше > был. Ща, похонах протрезвеет и продолжит мыслю. Я попытался в его > стиль на первых двух, но для ZFS пусть он сам опишет. А там нечего особо продолжать, abd.c - "каноничный" пример улучшизьмов. > * ABDs are an abstract data structure for the ARC which can use two > * different ways of storing the underlying data: который по дефолту (b) Scattered buffer. In this case, the data in the ABD is split into *     equal-sized chunks (from the abd_chunk_cache kmem_cache), with pointers *     to the chunks recorded in an array at the end of the ABD structure. ... struct abd_scatter {     uint_t        abd_offset;     uint_t        abd_nents;     struct scatterlist *abd_sgl; }; а чанки - размером с pagesize. Ага. И  Теперь представь, сколько их даже на 1 гиг выходит и как там с поиском нужного чанка дело обстоит ... или если прилетает invalidation/evict. Что может пойти не так (особенно с современными скоростями ИО)?™ Правда, за давностью лет уже все обсуждения из тырнета пропали, но https://github.com/openzfs/zfs/issues/12813 > zfs_abd_scatter_enabled: slow reads and very high CPU load > On a Linux/KVM host, sequentially reading some disk image files resulted in subpar performance and very high CPU load. At the same time, setting zfs_abd_scatter_enabled=0 or zfs_prefetch_disable=1 (ie: disabling scatter list or prefetch) fixed both the performance and CPU load issue. > "И вот так у них - все"(с).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #235 Ответы: #248, #305

247. Сообщение от пох.. (?), 11-Окт-26, 13:25	+/–
> В плане устойчивости к внезапным выключениям ничего лучше NTFS не встречал. а ты с винды-то слезать - пробовал? У меня есть вот такое: -rw-r--r-- 1 root root 118 Nov  2  2011 /etc/os-release LABEL=tmp     /tmp            ext4    noatime,noacl,nosuid,nodev,bsdgroups,barrier=0  1       2 внутри nojournal. Примерно до 19го года - стабильно висло и перезагружалось ресетом раз в неделю (глюки встроенной графики и несуществующего интеловского драйвера) ничего кроме совершенно ненужных временных файлов открытых в этот момент на запись - не пострадало, т.е. сама фс как была создана в 2011м, так и осталась - при том что да, это /tmp, это не модная-современная чудопомойка с /run, туда все время идет активная запись. Хотя и не все доходит до носителя из-за вон тех настроек. Я очень сомневаюсь что так используемую ntfs не пришлось бы все же лечить переформатированием несколько раз за такой промежуток времени.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #215

248. Сообщение от пох.. (?), 11-Окт-26, 13:34	–1 +/–
А ты неленивый, однако. (но зачем, тут некому это читать и понимать, а я и так знаю) > "И вот так у них - все"(с). вот это ключевое, к сожалению. abd я бы просто выпилил, это с ыышной помощью - несложно. Просто это хрестоматийный пример, не требующий глубоко лазить в сложные материи, все прямо там в файлике видно. Но не местному контингенту. "Все" остальное починить - ну... когда-нибудь... на пенсии... непременно возьмусь. (... или сам Ходжа...) P.S. prefetch БЕЗ abd - меряли, не опрашивали. Не надо его выключать. Даже на виртуалках с гигом - не надо. Это, кстати, кажется от тех, титанов еще, не новодел. В общем, титаны тоже были так себе, но их костыль - работает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #246 Ответы: #268

249. Сообщение от пох.. (?), 11-Окт-26, 13:58	+/–
>> У нее нет ничего похожего на полный журнал, > Это лишь вопрос точки зрения. Т.е. механику commit/rollback можно видеть и причем бы здесь - журнал (данных)? Журнал не про комиты. Журнал про линейность записи прежде всего. Там где нужна гарантия что записанное вторым - всегда записано _вторым_. > каких. Которым вообще на самом деле raw device было а остальное нет. ты опять демонстрируешь познания ни в чем? НЕТ больше современных бд в принципе работающих с raw device (кривую поделку kv не считаем). ВСЕ рассчитывают на позиксные соглашения. Даже оракл двадцать лет назад закрыл этот путь. (поэтому им журнал данных не нужен, у них свой журнал есть) Потому что никому нафиг не упало делать сложную и нетривиальную работу второй раз. > Теперь заменяем единичный блок на DVD-szied болванку - и получаем ровно обратные И обвиняем оппонента в подгонке решения под ответ. Ну ты хоть на протяжении одного сообщения не можешь перестать врать и вилять ,это не твое? > Я конечно понимаю что подгонять решение под ответ твое все, но именно но лично я последний раз писал какую-то "dvd болванку" десять лет назад. И это был архив 2004го года, да и тот в виде отдельных VOB. Где ты в 2k26 берешь какие-то "dvd болванки"? (вероятно там же где миллион файликов в одном каталоге на ntfs, в своих фантазиях) > и чего там в граммах было под МОИМИ сценариями. Что там > твой сферический блок в вакууме делает - мне малоинтересно. Потому что > это не мой сценарий. держи в курсе. (особенно смешно с учетом единственного озвученного тобой правдоподобного сценария, хотя и в его правдоподобие верится с большим трудом. И тем более в то что ты проверял сколько и чего там пишется в этом случае.)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #237 Ответы: #260

250. Сообщение от пох.. (?), 11-Окт-26, 14:04	+/–
> Уже есть.Но костыльно - проверка только на чтение, есть специальная псевдо фс г-ди... ну осильте ж вы уже md5sum , а?! (я уж молчу про mtree, если ценность имеют не только отдельные файлики а то как они лежат при этом) никакие специальные фс для этого не нужны, и перепроверить что вы имеете дело с неповрежденными файлами можно хоть на винде потом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #212 Ответы: #265, #267

252. Сообщение от alexanderyt (ok), 11-Окт-26, 17:36	+/–
Про виртуализацию тут никто и не вспомнил, кроме тебя. Так что, не пиши лишнего, за умного сойдешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #229 Ответы: #254, #257

253. Сообщение от Аноним (-), 11-Окт-26, 17:41	+/–
> ... и натянул вот еще четвёртый, ага. Дедуля, в отличие от тебя я не убиваю время на переустановку систем при факапе, с реинсталом софта, настройкой и проч. Мне время пригодится для других дел. И я смогу позволить себе эксперименты даже и с bare metal, если оно надо. > Сыночка - эти вот твои аналоговнетные снапшоты перед выполнением потенциально проблемных > операций обслуживания обеспечивает среда виртуализации - Дедушка, мне - удобно и bare metal менеджить в том же стиле. А зачем рулить по разному? Этим займешься ты, загатив голову бОльшим объемом ритуалов, а в результате будучи эникеем и в том и в другом. А потом ты идешь сдаваться Accenture, ибо все что ты смог - быть кормовой базой для кучи индусни. Это - твой уровень экспертизы в айти, как он есть. > и да, при этом не приходится ронять в днину перформанс работы с БД, Все твои перфомансы БД актуальны - очень сильно некоторым, в очень сильно некоторых задачах. Да и менеджить жирные бд лучше ее средствами и прочим узкоспециализированным добром. Но это интересно довольно узкой касте всяких DBA на которых мир не заканчивается. > как в случае с "неимеющими аналогов в мире ФыСы". > и нет, "бэкапами" это все еще не называют. Назвать снапшот бэкапом может только клиент Accenture. Поэтому и клиент собственно, даже индусы вероятно могут разницу усвоить, если их хорошенько отдрессирует манагер.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #229 Ответы: #258

254. Сообщение от Аноним (-), 11-Окт-26, 17:43	+/–
> Про виртуализацию тут никто и не вспомнил, кроме тебя. Так что, не > пиши лишнего, за умного сойдешь. Да не мешайте вы ему. Клиентом Accenture становятся не от избытка экспертизы, так что дедуля видимо очень плохо представляет себе насколько именно он с своим пафосом промахнулся с адресатом своих лекций и "экспертизы".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #252

255. Сообщение от Аноним (-), 11-Окт-26, 18:00	–1 +/–
> а что, кто-то звал? Это немного не так работает. В опенсорсе кому работа нужна тот ее и делает. А на каких условиях - а уж как договоритесь с другими интересантами. Не, нянек бегать за тобой в этом мире нет - и к твоему возрасту пора б уже - привыкнуть. > Там дедуля (на зарплате ibm, насколько я его > мутные речи понял) был недоволен что ему неполиткорректно распугивают бесплатных > тестировщиков и настройщиков интеграций. (Комитеры таки на зарплате тоже) Это про кого сие? В EXT4 вроде тестировать по крупному уже и нечего, так, оптимизируют майнтенанс. Ибо - внезапно - VFS/блочники/FS/... и правда - жестко understaffed. И не то чтобы корпы и прочие фаундейшны спешат это исправлять. А коли так - господа оптимизируют все по технологии "балласт за борт!" :) > думаешь, зарплату поделят менеджеры звена повыше, и никому новому не передадут? > В принципе, могут, конечно. Ну, э, вот что-то как-то призывы впрячься и увеличить firepower команды - остались без ответа. А коли так - причастные начинают выруливать сохраняя проект уж как умеют в пределах доступных им ресурсов. А это стало быть - вот так. Дроп всякой редко используемой проблемной хрени и проч. >> btrfs у меня "at my fingertips" и если что - я скажу правильные волшебные слова > "дам миллион"? Миллион я им не дам конечно - но борзыми щенками в виде квалифицированных работ помогающих зарулить баги их тоже устраивает. А поскольку это порой надо и мне - а конфиг как у меня они собирать в свое время врядли станут - особенно на не очень попсовой конфигурации какой - ну и вот кто с проблемой разберется то? Можно конечно орать на форуме - но это баги не починит. > им шта6ильные оклады подавай. Вот именно btrfs'ники таки - более менее нормально там тушек. А над чем еще работать то? Bcachefs? Слишком уж %^нутй кент там оказался. А то архаичное легаси - ну такое себе. > Волшебный пендель им даст работодатель, и они с радостью и энтузиазмом разрушат > то на чем ты построил свои системы. Я не строил ни 1 системы на базе сабж + полный журнал. Потому что я себе не враг. CoW считается некстгеном как раз потому что "классика" пытающаяся изобразить что либо по типу семантики полного журнала - ужасна по определению. > А ты все продолжаешь раздувать щечки и рассказывать как ты жрешь с > лопаты и тебя все устраивает. А что делать если мои системы и правда построены по тем технологиям? А Ext4+полный журнал это ну такое себе, для весьма утонченных ценителей. Я не настолько долбанут чтоб юзать все это с ТЕМИ свойствами. Предпочитаю баланс "цены-качества" и это точно не про то.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #242

256. Сообщение от Аноним (-), 11-Окт-26, 18:04	–2 +/–
> Не, на чо - зато с ним, родимым, ZFS на малинке (причем, > еще той самой) заработает! Не уверен, проверял ли кто-то, включая авторов > этого драндулета. Да как-то и жигули летают, особенно - ежели с высокого обрыва и почти вертикально вниз не парит. Только пилотов найти на это дело почему-то сложно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #214

257. Сообщение от User (??), 11-Окт-26, 18:31	+/–
> Про виртуализацию тут никто и не вспомнил, кроме тебя. Ну и зря так-то не вспомнил. Мне вот еще один уровень снапшотов поверх того, что и так обеспечивают схд и система виртуализации нужен вот ээээ... а ни для чего примерно не нужен, да. Ну, т.е. application-aware snapshots сами-знаете-откуда какбыда - а вот это вот - неа.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #252 Ответы: #266

258. Сообщение от User (??), 11-Окт-26, 18:43	+/–
>> ... и натянул вот еще четвёртый, ага. > Дедуля, в отличие от тебя я не убиваю время на переустановку систем > при факапе, с реинсталом софта, настройкой и проч. Мне время пригодится > для других дел. Оу. Так и я нет - decomission+deploy ноды в 2026 чуть-чуть не так, как ты себе это представляешь делается. > И я смогу позволить себе эксперименты даже и с bare metal, если оно надо. Можешь конечно же. Тут - верим. У тебя ж время-то забесплатновое, чего б не экскрементировать то? >> Сыночка - эти вот твои аналоговнетные снапшоты перед выполнением потенциально проблемных >> операций обслуживания обеспечивает среда виртуализации - > Дедушка, мне - удобно и bare metal менеджить в том же стиле. > А зачем рулить по разному? Ну, тут самое главное условие - найти этот зачем-то нужный и еще не виртуализованный bare-metal в 2026. И нет, под кровать к тебе я не полезу, не уговаривай. >> и да, при этом не приходится ронять в днину перформанс работы с БД, > Все твои перфомансы БД актуальны - очень сильно некоторым, в очень сильно > некоторых задачах. Ну да. А перформанс шины данных - которая вот wal-лог - для шинников. А block storage, который угадай как версионность обеспечивает - для администраторов хранилища. А кому и зачем может понадобиться вот это вот "с ашотами" если честно - не очень себе представляю. >> как в случае с "неимеющими аналогов в мире ФыСы". >> и нет, "бэкапами" это все еще не называют. > Назвать снапшот бэкапом может только клиент Accenture. "Снапшоты в правильном CoW - значительно "дешевле" бэкапов и фигачить их куда ненапряжнее чем бэкапы."(Ц) И немножко вот самоделкины-без-мотора путают. Капельку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #253 Ответы: #270

259. Сообщение от Alladin (?), 11-Окт-26, 19:41	+/–
ext4 надежная система, никогда на ней данных не терял. но и никакого data=journal я никогда не активировал а значит, думаю ничего не поменяется
Ответить | Правка | Наверх | Cообщить модератору

260. Сообщение от Аноним (-), 11-Окт-26, 19:42	–1 +/–
> причем бы здесь - журнал (данных)? Журнал не про комиты. В конечном итоге цель всей этой возни - получение того или иного диалекта ACID-подобной механики. Когда запись либо доведена до конца - либо откачена - атомарно. В этом смысле именно классические фс с журналом только метаданных отстой, ибо их недо-журналирование покрывает только корректность аллокации, но все что сверх этого вообще за кадром. Хуже всего это лезет в in place перезаписях. Если в энном файле в середину начали что-то писать и тут случился факап - на этот случай нет плана совсем. Нельзя ни откатить незавершенную запись ни докатить до финала, данных для undo/redo просто нет, без полного журналирования. CoW этой хренью не страдает - пока указатели на новый вариант не перевесили, undo - получается сам собой. Делать вообще ничего не надо. Реально чуть сложнее конечно - но в целом это то почему с ними вообще столько возятся. Такие свойства при избегании записи сперва intent потом commit. А, внезапно, наполовину перезаписаный ZIP или картинка или офисный докумет открываться - тадам - не будет. Будет нарушение формата данных в середине файла и все, приплыли. И это намного хуже чем получить целиком старый или целиком новый файл - поскольку так он вообще не юзабелен никак и это самый поганый из всех вариантов. Это и не лечится, и инфо потеряно, при том не восстановимо. И программам которым это неприемлимо приходится дико костылять на app layer совсем другую семантику операций. Сильно навороченнее. > Журнал про линейность записи прежде всего. Там где нужна гарантия что записанное > вторым - всегда записано _вторым_. Журнал это про корректность трекинга аллокаций, консистентность метаданных, а в идеале и данных - и поддержку выбранной семантики операций. Если записанное первым и вторым меняются ролями это частный случай нарушения консистентности но это лишь 1 из многих сценариев. Скажем "частичная запись" из примера выше может быть и на дизайне где 1 и 2 запись упорядоченны правильно, просто 2-я до конца не доехала - для undo данных нет - и файло в середине безнадежно испорчено. >> каких. Которым вообще на самом деле raw device было а остальное > нет. ты опять демонстрируешь познания ни в чем? БД как таковые - почти то же что и ФС, просто кастомные диалекты под несколько разные задачи. Им было бы удобнее всего - линейное пространство, а рулить им они будут сами. Без лишнего уровня трансляции в виде ФС. Вот только так становится очень геморройно управлять этим по линии администрирования. И бэкапать, и тем более увеличить/уменьшить размер и проч. > НЕТ больше современных бд в принципе работающих с raw device Но лишь потому что админы очень не любят с этим всем иметь дело - это нестандартное знание и масса неудобств на ровном месте. А технически БД и ФС по сути диалекты одной и той же идеи, просто разный респин. И даже Кент это может признать. Честно сказав что b-tree FS берут свои идеи - из того как это БД делают. > kv не считаем). ВСЕ рассчитывают на позиксные соглашения. То что хочется != то что можется. Странно, да? > Даже оракл двадцать лет назад закрыл этот путь. Потому что это баланс интересов и то что было бы хорошо технически - натыкается на то что административно это полный кошмар и админы волком смотрят на такие идеи. >> Теперь заменяем единичный блок на DVD-szied болванку - и получаем ровно обратные > И обвиняем оппонента в подгонке решения под ответ. Ну ты хоть на > протяжении одного сообщения не можешь перестать врать и вилять ,это не твое? Я лишь симметрирую твои бредни - другими кейсами. Потому что ФС и их паттерны использовани бывают разные. >> Я конечно понимаю что подгонять решение под ответ твое все, но именно > но лично я последний раз писал какую-то "dvd болванку" десять лет назад. Т.е. даже всякие там образа ОС и VM ты - таки - не кантуешь? Хотя я слишком много хочу, от юзера винды такого ожидать то. > Где ты в 2k26 берешь какие-то "dvd болванки"? Образа систем и виртуалок всякие фигачу, все такое. > (вероятно там же где миллион файликов в одном каталоге на ntfs, в > своих фантазиях) Ну до миллиона я не догонялся - а 300К в 1 дире реальная цифря при процессинге некоторых данных. Да, это вокруг процессинга всяких OSMных карт и проч. Ты ж не думал что я только хомячковыми кейсами ограничусь? > держи в курсе. Как впрочем и ты с твоим одним блоком. > (особенно смешно с учетом единственного озвученного тобой правдоподобного сценария, Лучше расскажи что ты такое по 1 блоку оптом записываешь, чтоб это еще и парило? Видишь, в эту игру могут играть и двое.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #249

261. Сообщение от Alladin (?), 11-Окт-26, 19:44	–1 +/–
да, большая часть данных в озу - всегда теряем данные так теряем, ни шагу назад
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #179

262. Сообщение от Аноним (262), 11-Окт-26, 20:08	–1 +/–
> Вот у этого анонима лучше получилось - на 30 процентов! > показатели достигли потолка, с которого и были взяты? Среднепотолочный десктоп перешедший с EXT4 на BTRFS на рутфс норм пример как по мне. Не, никакие в 64 раза не получается. При всяких там апдейтах системы, гамесах с ресурсами на эн гиг и проч файлами данных у софта - записей по 1 блоку за присест чтоб это в 64 раза раздуть - просто не бывает. Чтобы получить именно кучу мелких записей размером с блок, с синком между ними чтб реально 64x увидеть - надо убер нагруженный БД или сделать что-то откровенно глупое типа CoW виртуалки с CoW диском/фс. >> И конечно никаких 64х и рядом нет. > ты конечно - мерял? Статистика накопителя и ее эволюция. В общем сам по себе btrfs ничего ужасного не делает с SSD, чтоб трястись как кощею и юзать окаменелый кал мамонта, обув себя на рефлинки и снапшоты. Кстати, рефлинк вместо фактической записи - нехило объем записи урезает, но это видимо несчитово, раз в теории не вписывается. Как и сжатие. > И можешь сейчас продемонстрировать методику измерения? Пустить десктоп пахать месяцок и посмотреть "sectors written" при типичном использовании так и сяк. А накукуй мне шишкинфсская синтетика?! Я за инженерный подход - на реальной конфиге и прикинул порядки величин. У меня даже самый протертый SSD не сыграет в ящик за разумное время - ну и хренли я буду трястись? Моему скелету пофиг будет. Зато при жизни я смогу насладиться продвинутыми эксплуатационными свойствами вместо тряски как кощею над железкой у которой что так lifetime ломовой что сяк. > (единственное с чем соглашусь - при обычном чтении опеннета и просмотре прона > - современные носители как-нибудь справятся за приемлемое время, и выбор основан > на других факторах) Да и вообще при обычном юзеже десктопа, в общем то. Рисование в CAD или кодинг тоже диск не особо сильно грузит. Да даже редактипрвание фот, которые тоже зело поболее 1 блока.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #243

263. Сообщение от Аноним (-), 11-Окт-26, 20:29	–2 +/–
> Всё отлично, но было бы хорошо, не получить мне сюрприз в самый > неподходящий момент: С EXT4 лучше забыть про это желание. Я как-то скатался к ВНЕЗАПНОМУ кирпичу с EXT4 как рутфс. Failure analisys показал что на uSD вылез 1, сцуко, бэд. Зато как метко - под libc6! Система и стала тыквой - не работает софт без libc6 почему-то. А так все годами работало без сбоев. Но иногда теорвер - вот - прикалывается. Есть такая хрень, BER, он никогда не ноль, что бы ни вещали похи-нахи. Кто не верит, берет СПЕКИ накопителя (на которые оно есть, например девайсы для индустриала). И смотрит что кто кому на самом деле (не) обещал. На среднепотолочной дешевке будет еще хуже, ага. > И тут я понимаю, какой п#$%@ц тут происходит, когда у тебя система на ext4, > не может примонтировать ext4 Да вообще это с любым продвинутым фс словить можно в той или иной степени. Все фичи нового NTFS виндус XP никак не сжует. Старое ядро XFSv4 ничего не знает про XFSv5. А если я включу block group tree на btrfs, чтобы замаунтить read-write потребуется ядро 6.1 или новее. Хотя как readonly и более старые зацепят. Там целый механизм "incompat" спертый другими по моему у EXT4 на самом деле. Есть фичи которые допускают RO монтирование. Есть которые не допускают совсем. Хотя совсем-incompat btrfs вроде пока ни разу не юзал. Да черт, даже с FAT есть куча субдиалектов так то на самом деле.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161

264. Сообщение от Аноним (264), 11-Окт-26, 20:31	+/–
>>Полный журнал на классике - пишет данные два раза > Ты выдумываешь. Такой классики не бывает. Да вот же - сабж. Сперва в журнал, потом в основную область. Классика жанра. Отстойная по перфомансу - за что и не используется как правило.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157

265. Сообщение от Аноним (264), 11-Окт-26, 20:32	–1 +/–
>> Уже есть.Но костыльно - проверка только на чтение, есть специальная псевдо фс > г-ди... ну осильте ж вы уже md5sum , а?! Ага, и вот ща буду каждый проект KiCad после очередного сохранения md5sum гонять...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #250

266. Сообщение от Аноним (-), 11-Окт-26, 20:48	–1 +/–
> т.е. application-aware snapshots сами-знаете-откуда какбыда - а вот это вот - неа. Зелен виноград, yada-yada. Правда жизни проста. Это некромант-бсдшник или древний юниксоид с проприетарным бэкграундом, который аж кюшать не может что пингвин не только попер его фетиши на мороз но и по фичам уделал. Так что такие даже в винду подаются - но и там остаются - эникей эникеем. Что не мешает пытаться корчить из себя какую-то якобы-ценную якобы-экспертизу. Которая не сработала даже для ее обладателя. Что у поховнахов что у User.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #257

267. Сообщение от maximnik0 (?), 11-Окт-26, 22:02	+/–
>никакие специальные фс для этого не нужны, Тут куча народа писала- что у ext4 из за отсутствия контрольной суммы спокойно может уйти повреждённый файл в бэкап а ты и знать про это не будеш. В отличие от к примеру btrfs. Вот для этого и есть костыль : fs-verity — это функция ядра Linux, предназначенная для прозрачной проверки целостности и подлинности отдельных файлов.fs-verity защищает отдельные файлы на файловой системе, которая может быть read-write (например, ext4, f2fs, btrfs. Не совпадает хэш - выдаст функция ошибку чтения, админ узнает о повреждении файлов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #250 Ответы: #273, #276

268. Сообщение от Аноним (162), 11-Окт-26, 22:05	+/–
> abd я бы просто выпилил Сделать zfs_abd_scatter_enabled=0 религия не позволяет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #248 Ответы: #324

269. Сообщение от Аноним (162), 11-Окт-26, 22:47	+/–
> ты конечно - мерял? Ну я мерял. На реальном железе с ssd запускал как тесты из состава phoronix (blogbench, postmark etc.), так и с помощью самописного скрипта запускал запись и многократное копирование (с --reflink=never естественно) несжимаемыми блоками размером от 512B до 512MB. Статистику отслеживал с помощью iostat и du. Как и ожидалось -- никаких х30 нет и в помине. С отключённым сжатием или на несжимаемых данных WA сравним с таковым у ext4 и xfs (на разных тестах показатели плавали (условно, т.к. точных цифр уже не помню) примерно от +20% до -20%, т.е. плюс-минус то же самое). С включённым сжатием на сжимаемых данных WA так и вовсе много меньше единицы. ZFS кстати это касается в той же мере что и btrfs, у неё усиление записи как на сжимаемых данных, так и на несжимаемых вообще оказалось едва ли не самым низким. Тесты проводил давно и точных цифр уже не помню, но в целом можно сказать что усиление записи у ZFS, которой я пользуюсь, оказывается высоким (но никак не х64 и даже не х20) только на блоках очень маленького размера -- меньше 2KB. Уже при 4KB WA принимает вполне пренебрежимые значения, а после 16K WA вообще практически перестаёт расти. Все сказки о чудовищном усилении запии у zfs и btrfs так и остались сказками. Ещё запомнилось что у хвалёной в узких кругах f2fs УЗ оказалось даже выше чем у ext4. Как-то так.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #243 Ответы: #280

270. Сообщение от Аноним (-), 11-Окт-26, 22:49	+/–
> Оу. Так и я нет - decomission+deploy ноды в 2026 чуть-чуть не > так, как ты себе это представляешь делается. А мы возьмем и рассмотрим вот прям твой десктоп/ноут и проч. И как там decomission+deploy ноды поживает? В этот момент - окажется что сапожник у нас - как обычно - без сапог? А мне нафиг надо - быть подстилкой корпоративной, делая то что мне самому не упало, юзая системы для себя в режиме хомяка, уповая на добрых дядь. В этом мы бесконечно разные. Вы работаете с 9 до 17. А я вообще не работаю - я этим наслаждаюсь. И когда оно так, неизбежно учишься быть в этом - здорово выше среднего. В айти есть те кто "деньги зарабатывает" и есть те кому оно по кайфу. И вон те никогда не будут первым сортом в IT, вторые всегда будут смотреть на них как на ... то самое. И это импактит карьеру и возможности. > Можешь конечно же. Тут - верим. У тебя ж время-то забесплатновое, чего > б не экскрементировать то? Результат может разгонять мою эффективность или представлять коммерческую ценность или новые возможности. Те кто не инвестирует в R&D никогда не являются лидерами. Есть leaders, есть followers. Followers не далеко ушли от slaves, им другие навязывают правила игры. > Ну, тут самое главное условие - найти этот зачем-то нужный и еще > не виртуализованный bare-metal в 2026. Он у меня перед моим носом, дедуля. В конечном итоге я по его физической клавиатуре тут с тобой беседую. А хоть и в браузерной виртуалке. Которая на самом деле - он же самый, но только в VM и минимизированный. > Ну да. А перформанс шины данных - которая вот wal-лог - для > шинников. А block storage, который угадай как версионность обеспечивает - для > администраторов хранилища. О шине я могу не знать ничего - но она будет как-то работать. Но serviceable БД в таком режиме - таки не вариант. Разве что sqlite какой и простые key-value, но это врядли ghj нагруженные базы где CoW помешает. Остальное - требует явных знаний и скиллов DBA все же. И это мягко говоря не для всех. > А кому и зачем может понадобиться вот это вот "с ашотами" если > честно - не очень себе представляю. Мне вот - надобится. А вот DBA я себя не считаю. И не то чтоб мне это мешает жить. > "Снапшоты в правильном CoW - значительно "дешевле" бэкапов и фигачить их куда > ненапряжнее чем бэкапы."(Ц) > И немножко вот самоделкины-без-мотора путают. Капельку. Можно видите ли - сочетать одно и другое. Скажем у меня есть бэкапы. Например, на отключаемый внешний винч, так что хакеры, скачки питания и проч до него не доберутся. Но это довольно долго и интенсивно по ресурсам. Снапшоты я могу аплейтить многократно чаще. А бэкапы на случай "everything failed".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #258 Ответы: #285

273. Сообщение от пох.. (?), 11-Окт-26, 23:01	+/–
> Тут куча народа писала- что у ext4 из за отсутствия контрольной суммы спокойно может уйти > повреждённый файл в бэкап ну а ты свой мозг не мог включить и критично воспринять эту писанину? Поврежденный файл в бэкап может уйти и с контрольной суммой тоже. Потому что может повредиться в памяти после прочтения, может криво записаться в этот самый бэкап, может повредиться бэкап. И может криво восстановиться по той же куче причин. И контрольная сумма в фс сойдется, потому что посчитана либо по уже кривым данным либо проверена до повреждения. Причем _самая_ из них невероятная - это как раз повреждение данных при исправной фс непосредственно на диске. Поэтому если данные тебе на самом деле ценны, какой-то архив чего-то чего днем с огнем не найдешь на пару гигабайт (т.е. вероятность что сбой попадет внутрь не бесконечно мала) - таскай с ним контрольные суммы и проверяй на каждой или хотя бы на конечной остановке - точно ли ты тот самый файл притащил. Причем ты сразу же увидишь результат проверки в понятном виде. А городить косые этажерки нет ни малейшего смысла.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #267 Ответы: #278

274. Сообщение от Аноним (-), 11-Окт-26, 23:02	–1 +/–
> бывает, гугли про log structured fs. Ну по дороге нагуглишь, конечно, почему > бывает, но как динозавры примерно. В каких-то окаменелостях иногда находят. Log structured это по сути - диалект CoW технологии как таковой. Просто оно у тех кто пробовал - было еще более странными зверушками чем btrfs. Но в конечном итоге CoW все делают что-то наподобие по общему смыслу действа, для избегания двойной записи. Конкретные детали реализации интересны в основном - с точки зрения достигнутых параметров. А общая идея действа остается та же самая.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #165

275. Сообщение от Аноним (-), 11-Окт-26, 23:04	–1 +/–
>> ZFS? Тут все честно. > там нет именно журнала данных. > Там за счет структуры фс чуть лучше с гарантиями, но все зависит > от аккуратности автора приложения. (и немножко от везения) > Т.е. как раз читеры ;-) Проблема в том что с его околоблочной структурой все это ему очень мало поможет уже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #219

276. Сообщение от Аноним (-), 11-Окт-26, 23:08	–1 +/–
>>никакие специальные фс для этого не нужны, > Тут куча народа писала- что у ext4 из за отсутствия контрольной суммы > спокойно может уйти повреждённый файл в бэкап а ты и знать > про это не будеш. Еще веселее когда у тебя ВНЕЗАПНО - бабах - readonly filesystem! Бабах fsck - опа, а теперь совсем фаталити. А план на этот случай у тебя был вообще? Я то когда data recovery промышляю - fsck на рефлинкнутой "тонкой копии" гоняю. И если оно так - я могу и переиграть. А вот ты на своем bare metal сможешь так же? Ну вот и похонах так же! :-) А в чем прикол? У кого оператива глючит. У кого проц сбоит. А кому - вот - драйвер Nvidia память бил, прямо эпидемия падежа файлух (разных) была. Вычислили гада лишь когда какой-то btrfs'ник спросил "а чойта оно так орет про ошибки чексум, баг ФС?!". А ему и грят - не, баг - твоей конфиги, сыпется что-то. А кадр и заметь что ошибки начинаются - после инсталла драйвера нвидии. А без него тишь да гладь. Так вот и узнали кто народу файлухи резко и жестко в Linux выносил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #267 Ответы: #315

277. Сообщение от Аноним (-), 11-Окт-26, 23:10	+/–
> скажем ACID не будет работать на 100% если fs не гарантирует консистентность. Большинство если не все реализации БД и проч - таки умеют жить с ТОЙ семантикой. Правда это - ценой выоса половины механики журнала на уровень приложухи...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #224

278. Сообщение от maximnik0 (?), 11-Окт-26, 23:18	+/–
>Причем _самая_ из них невероятная - это как раз повреждение данных при исправной фс непосредственно на диске. Это как раз самая вероятная причина - сейчас идут черепичники.И у многих  есть алгоритм  для редко используемых файлов переместить эти файлы в зону черепиц+ идёт таблица замены адресации.И не чего с этим сделать не реально_ обычных дисков все меньше и меньше:-(
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #273 Ответы: #314

279. Сообщение от пох.. (?), 11-Окт-26, 23:23	–1 +/–
> Если не становиться в позу оскорблённой невинности, то простой запрос к ДипСику > даёт такой ответ: лоханулся твой дикпик. Налил ведро воды, а до вишенки так и не докопался. Если бы ты открыл файл (и умел конечно понимать несложный код) - ты бы увидел главную проблему _сразу_. (одну, там еще рядом вторая есть, чуть менее очевидная) User вот - увидел (полагаю, не вчера, конечно). > Это вызывало фрагментацию и проблемы с производительностью, особенно на 32-битных > системах это вот особенно смешно, да. sonnet, кстати, мгновенно вытащила суть. Скорее всего из pre-learned knowledge, а не анализом кода. И еще пару проблем в соседних местах, о которых я не знал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #244

280. Сообщение от пох.. (?), 12-Окт-26, 00:01	+/–
>> ты конечно - мерял? > Ну я мерял. На реальном железе с ssd запускал как тесты из > состава phoronix (blogbench, postmark etc.), так и с помощью самописного скрипта > запускал запись и многократное копирование (с --reflink=never естественно) несжимаемыми > блоками размером от 512B до 512MB. Статистику отслеживал с помощью iostat ну это что-то странное ты мерял. И чем-то странным. Я бы не очень доверял в этом месте - iostat,хрен его знает что он там меряет (это /sys/block/sd?/stat который считается странно). Наш местный эксперт, кажись, мерял внутренним счетчиком накопителя, что более интересно и ближе к подходу того исследователя, но у него к сожалению очень мутный use pattern. То какие-то двд, то мильены файлов. Непонятно, чему верить и степерь прямизны рук тоже вызывает сомнения. В тех тестах где намеряли x32-64 - меряли счетчиками реально записанных блоков (любая нормальная виртуалка такой имеет, насчет qemu вот не уверен), в обход ос. > и du. Как и ожидалось -- никаких х30 нет и в дальше инженер должен бы задаться вопросом -а почему и то ли он меряет ;-) (например, не отложена ли запись) > WA так и вовсе много меньше единицы. ZFS кстати это касается > в той же мере что и btrfs, у неё усиление записи c zfs все сложнее. У нее несколько совершенно разных write path и мерять стоит подходящий под применение. Боюсь что как бы в моем варианте не получилось даже больше чем у btrfs. (выключенный arc compress, и, главное - выключенное сжатие. Вместе с ним выключается variable block length, т.е. это вообще немного другая zfs чем та что ты мерял. Несжимаемые блоки не то же самое.) > ZFS, которой я пользуюсь, оказывается высоким (но никак не х64 и > даже не х20) только на блоках очень маленького размера -- меньше что тоже странно. Но может я не понимаю до конца как работают variable blocks, и в твоем случае получилось что файл пишется recordsize'ами. Но тогда у тебя на 4k блоках должно быть аж 32x. recordsize у нас - 128 если вручную не лезть куда не надо, такое не заметить надо суметь. Если оно писалось блоками (например ты закрывал файл после записи блока - так ТОЧНО запишет ровно 2k) - вообще не должно быть видимой разницы и опять же надо бы разобраться почему ты ее видишь и что же оно тогда такое пишет. Я в это не полезу потому что так ее не использую. > что у хвалёной в узких кругах f2fs УЗ оказалось даже выше ее надо настраивать под конкретную page size, которую взять неоткуда, и работать через интерфейс который не побьет ее на 4k блоки (т.е. только mmc из общедоступных). И не промазать со смещением, чтоб запись не угодила между страниц. местные определенные круги просто не читали документацию, которую самсунг вообще-то выкладывал, и не понимают как она работает. Это вообще не для простых смертных фс.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #269 Ответы: #282, #283

282. Сообщение от Аноним (162), 12-Окт-26, 04:09	+1 +/–
> ну это что-то странное ты мерял. И чем-то странным Ничего там странного нет. Вместо iostat можно было использовать 'nvme smart-log', инфу они выдают абсолютно идентичную, с той лишь разницей что iostat выдаёт данные в десятичных байтах, а smart-log в двоичных (или наоборот, не помню). du разумеется применялась с ключём --apparent-size, чтобы правильно учитывался эффект от сжатия. В любом случае меня интересовала общая картина, а не абсолютная точность, и для этих целей выбранные инструменты меня вполне устроили. > дальше инженер должен бы задаться вопросом -а почему и то ли он меряет Эти тесты я затеял как раз после того как начитался известных страшилок про огромное усиление записи у ФС с COW, ту нелепую статью на Хабре про btrfs я тоже конечно читал. На сами тесты убил не один день и перепробовал самые разные инструменты, так что можешь быть уверен, время подумать у меня было. Делалось всё на отдельной машине, никаких браузеров, ничего такого, что могло бы повлиять на результаты не было. В основном всё делал на Дебиане (разных версий и с разными ядрами), но пробовал и openSUSE. Версии zfs и btrfs тоже пробовал разные. Результаты слегка отличались, но незначительно, оставаясь скорее в рамках погрешности; openSUSE показалась немного быстрее даже несмотря на более старое ядро. Ты лучше прочти исходное "исследование", на которое ссылался как автор с Хабра, так и сетевые комментаторы, тогда тебе станет понятно откуда взялись те огромные цифры. Одно можно сказать совершенно определённо: к реальной эксплуатации они не имеют никакого отношения. Если ты не пишешь постоянно блоками по 512Б или не используешь какую-то иную специфическую нагрузку, то об усилении записи можно вообще забыть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #280

283. Сообщение от Аноним (162), 12-Окт-26, 06:10	+/–
Если интересно, то вот пример WA по результатам теста на основе blogbench (сжимаемые данные): ext4: 2.46 xfs: 1.91 btrfs: 1.66 btrfs (zstd): 0.52 zfs: 1.47 zfs (zstd): 0.11 Указанные цифры не нужно принимать за абсолют, т.к. в зависимости от версии ОС, ядра, ФС результаты отличаются, но не настолько чтобы придавать этому значение. Например в тесте с копированием несжимаемых файлов усиление записи у ext4 наоборот оказалось ниже чем у xfs (2.33 против 2.67), у zfs - 2.25 (как со сжатием, так и без), у btrfs - 1.7 (со сжатием и без).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #280 Ответы: #288

284. Сообщение от iPony128014 (?), 12-Окт-26, 06:49	+/–
> Странно, но когда то существовал такой термин как legasy-код, из которого состояло > 70++% всего софта и на протяжении примерно 30 лет разработчики каким > то образом умели с этим работать Ничего странного. И особо ничего не поменялось. Зависит от проекта, требований и всего прочего. Что единственное изменилось, что это вот подобные макисмалисты повылезали у которых всё просто, одинаково и ясно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123

285. Сообщение от User (??), 12-Окт-26, 07:50	+1 +/–
> А мы возьмем и рассмотрим вот прям твой десктоп/ноут и проч. Где ж я тебе тот "дысктоп"-то в 2026м найду? А с ноутом - ну давай. Как думаешь, сколько раз у меня были проблемы с w11 за последние два года? Из того, что могу вспомнить - docker desktop при обновлении WSL вот сказал "кря" и напрочь потерял интеграцию с WSL. И да, решилось сиё как раз таки удалением линуксовой (Кто бы сомневался-то, да?) виртуалочки с тем десктопом, которая совершенно автоматически перекачалась без потери данных. А с macos за три года как думаешь, сколько проблем было? Ну, угадай? А вот со всякими дебунтоидами до того таки да, случалось. Правда вот решалось примерно "все" без отката-на-снапшот, да. И все это патамучта комп у меня вот не твоя помойка и экспериментирую я по виртуалочкам, что - см. выше. > Результат может разгонять мою эффективность или представлять коммерческую ценность или новые возможности. Да-да, в два раза быстрее по заказам ездишь будешь. Верю. Так маме и говори. > Он у меня перед моим носом, дедуля. Ну извини - твой дысктоп вне моих профессиональных интересов. Меня и мой-то не особо в этом смысле интересует. > О шине я могу не знать ничего - но она будет как-то работать. Но serviceable БД в таком режиме - таки не вариант. Ну, то, что ни о шинах данных, ни о БД ты не знаешь вот совершенно ничего - установлено вполне себе достоверно. С тем, что ты "знаешь" определенности достичь не получилось - но мы все еще стараемся. Не может же это быть одно большое "ничего", правда? > Мне вот - надобится. Замечательно. А кому-нибудь чего-нибудь практически полезного сделать не пробовал? Ну, кроме тебя и твоих воображаемых друзей? "Работа" называется, знаешь? За неё еще деньги платят. > Можно видите ли - ... не путать одно с другим, но получается у поподвальных это вот через раз - обычно после того, как мордочкой понатыкают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #270 Ответы: #304

287. Сообщение от Sm0ke85 (ok), 12-Окт-26, 09:18	+/–
Прочитал новость, объяснения выпиливания - глупые абсолютно, смотрятся как детский сад... Там реально хоть одна проблема то есть...? ext4 - rip в ближайшем будущем?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #301

288. Сообщение от пох.. (?), 12-Окт-26, 10:02	+/–
ты тут - сжатие протестировал. собственно, с zfs/btrfs это очевидно. осталось только вытащить на свет алгоритмы сжатия и точные их параметры - размер блока и коэффициенты. Вангую что у zfs блок был самый большой - те самые 128k, btrfs жмет какими-то помельче. А на ext4 сжатия не было вовсе. логично, если сжать данные, допустим, вдвое, wa на cow упадет даже не вдвое а 2*wa раз. Кажется, поэтому местные эксперты проблему в zfs и не видят (там всегда включено, пока сам не выключишь. В btrfs, afaik, до сих пор по умолчанию off?) Собственно, забавного тут то что по ext4/xfs ты получил ровно те цифры что в исследовании десятилетней давности. (а выключишь журнал - получишь равные) т.е. механизм измеризмов иостатом можно в общих чертах принять за достоверный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #283 Ответы: #292

289. Сообщение от bx (?), 12-Окт-26, 10:11	+/–
Это ты что-то перепутал. journal=data это пипец.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

290. Сообщение от bx (?), 12-Окт-26, 10:12	+/–
Который за 100 рублей купили?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

291. Сообщение от bx (?), 12-Окт-26, 10:14	+/–
ДГУ - это не совсем батарейки )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #232

292. Сообщение от Аноним (162), 12-Окт-26, 11:03	+/–
> ты тут - сжатие протестировал. собственно, с zfs/btrfs это очевидно Нет, тут я протестировал усиление записи. Для zfs и btrfs результаты по WA представлены в двух вариантах -- для случая когда сжатие выключено (да, я знаю как это делается, представь себе) и для случая когда сжатие включено (zstd-1 в обоих случаях). Для ext4 и xfs результаты по очевидным причинам представлены в одном варианте. > а выключишь журнал - получишь равные По умолчанию ext4 журналирует только метаданные, так же как и xfs. И та, и другая ФС применялись с абсолютно дефолтными настройками, ничего дополнительно я не включал. Соответственно нечего и отключать. Если бы я на ext4 включил ещё и журналирование данных, то её результаты были бы в два раза хуже (я проверял). А разница в усилении записи на сжимаемых данных и несжимаемых видимо связана с тем, что ФС по-разному обрабатывают маленькие блоки. Дело в том что blogbench создаёт в ходе работы относительно крупные файлы, тогда как мой тест с несжимаемыми данными предполагает создание файлов от 512B до 512KB (хотя на самом деле можно было остановиться на 128KB, на результатах это не сказалось бы), по 4MB на каждый размер, с последующим десятикратным копированием всей этой кучи. Очевидно что доля мелких файлов в этом тесте гораздо больше, чем в тесте blogbench. Потому и цифры немного отличаются.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #288 Ответы: #317, #320, #321

293. Сообщение от Кирилл (??), 12-Окт-26, 11:40	+/–
> Фух, ну слава богу.. А то я уж подумал, что требования к > софту теперь не те, что 30 лет назад, как и сам > темп разработки, диктуемый другим темпом жизни. Мне даже интересно, это какие такие требования выдвинули пользователи андроида на митинге, угрожая гуглу бойкотом, и требуя выпускать по 1 версии системы ежегодно из за чего весь плэймаркет приходится переписывать практически с нуля каждые 2-3 года.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #213

294. Сообщение от Кирилл (??), 12-Окт-26, 11:42	+/–
> Фух, ну слава богу.. А то я уж подумал, что требования к > софту теперь не те, что 30 лет назад, как и сам > темп разработки, диктуемый другим темпом жизни.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #213

295. Сообщение от Кирилл (??), 12-Окт-26, 11:43	+/–
Мне даже интересно, это какие такие требования выдвинули пользователи андроида на митинге,
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #213

298. Сообщение от Кирилл (??), 12-Окт-26, 11:49	+/–
угрожая googлу boйkotom, и требуя выпускать по 1 версии системы ежегодно из за чего весь плэймаркет приходится переписывать практически с нуля каждые 2-3 года.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #213 Ответы: #300

299. Сообщение от Кирилл (??), 12-Окт-26, 11:59	+/–
>> "Нет! не надо нам новых фичей, пусть всё будет работать как работало ещё 15 лет!" Ты видел какие нибудь другие комментарии к какой нибудь новой и креативной версии приложения? Или может там есть эти самые новые фичи? в 99% случаев всё сводится к добавлению рекламы и переворачиванию неудобного, но хотя бы привычного интерфейса на какую нибудь хтоническую жесть. Ещё часто эти самые фичи ломают чтобы заставить пользоваться какой нибудь ненужной хренью. И ещё добавляют тормоза и анимации потому что где то появился новый, ещё более тормозной фремворк отрисовки, точно такой же как старый, только тормозной и жрущий больше памяти. >> Не ходят по форумам миллионы "а вот эту фичу почему не добавили?" Таки не ходят. Во первых потому что всё что нужно было уже лет 15 как добавлено, а во вторых потому что сейчас разработчикам насрать на то что пишут пользователи, им план спускают сверху. >> "а почему на вот этой моей железке без спецификаций и из говна и палок собранной работает не так?", "АА! Вы сделали фичу как Вася просил, а мне она не нужна, оставьте поддержку и старого поведения!" А вот это сплошь и рядом. И ещё никто ни разу не понизил системных требований, не сделал оптимизацй
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #245 Ответы: #302

300. Сообщение от derfenix (ok), 12-Окт-26, 12:01	+/–
> угрожая googлу boйkotom, и требуя выпускать по 1 версии системы ежегодно из > за чего весь плэймаркет приходится переписывать практически с нуля каждые 2-3 > года. Трындец тебя порвало, чувак. Иди поспи, что ли...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #298 Ответы: #311

301. Сообщение от пох.. (?), 12-Окт-26, 12:03	+/–
> Прочитал новость, объяснения выпиливания - глупые абсолютно, смотрятся как детский сад... > Там реально хоть одна проблема то есть...? ext4 - rip в > ближайшем будущем? а вот это ты узнаешь когда научишься кодить ;-) пока есть личное мнение дедушки на зарплате ibm (которой работающая ext4 вообще не нужна) который пять лет назад признавался что кодить давно разучился, и ни на каком инструменте не играет, он руководитель. (в основном причем погоняющий бесплатновую рабсилу)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #287 Ответы: #303

302. Сообщение от derfenix (ok), 12-Окт-26, 12:05	+/–
Жаль, что ты не понимаешь ещё, что твой взгляд на мир - не единственный. Если тебе не нужно, если тебя 15 летний софт устраивает всем, если тебе не нужен новый функционал, то это именно тебе это не нужно, ну и ещё нескольким сотням или тысячам. Но мир не крутится вокруг тебя и ему совершенно наплевать на твоё мнение о том, какой он должен быть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #299 Ответы: #312, #313

303. Сообщение от Sm0ke85 (ok), 12-Окт-26, 13:44	+/–
>а вот это ты узнаешь когда научишься кодить ;-) При чем тут "кодить" и конкретная реализация ФС...? >пока есть личное мнение дедушки на зарплате ibm (которой работающая ext4 вообще не нужна) который пять лет назад признавался что кодить давно разучился, и ни на каком инструменте не играет, он руководитель. >(в основном причем погоняющий бесплатновую рабсилу) Пока ничего не ясно. Конкретика есть?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #301 Ответы: #310

304. Сообщение от Аноним (-), 12-Окт-26, 17:56	+/–
> Где ж я тебе тот "дысктоп"-то в 2026м найду? В офисе например, у любой фирмы которая не хайпует а оптимизирует перфоманс-затраты. Ну или вот у меня - есть. Потому что я не е...й хомячок и норовлю... 1) Прогнать обработку фот и видео. 2) Компилять нехилого размера проекты. 3) Порисовать в CAD и проч. 4) Прогнать всякие нетривиальные "оптимизации дизайнов на параметры". 5) Процессинг больших объемов данных, типа общепланетарного OSM. Это все достаточно прожорливое по ресурсам. > А с ноутом - ну давай. Как думаешь, сколько раз у меня > были проблемы с w11 за последние два года? Из того, что > могу вспомнить - docker desktop при обновлении WSL вот сказал "кря" > и напрочь потерял интеграцию с WSL. А что - давай? У меня есть пару ноутов. Они в целом просто работают. И мне не надо их распадлоидизировать и они ведут себя так как надо - мне, а не майкрософту. Кроме того - ты уж извини, "экспертище", но w11 это не твоя заслуга. А результат работы oem, MS и проч. Ты к этому никакого отношения не имеешь. И аргументом за твою экспертизу это все не является от слова вообще. Простая логика - о которой ты подумать забыл. Типично. > И да, решилось сиё как раз таки удалением линуксовой (Кто бы сомневался-то, да?) > виртуалочки с тем десктопом, которая совершенно автоматически перекачалась без потери данных. О том что с линухом эффективнее всего работается из линуха - клиент Accenture ессно не в курсе. Он же аж кюшать не может что его фетишей ушел на мороз пингвин и потому - нормально освоить систему никогда не смог. Как и похинахи всякие. Что тут можно сказать? Вы обречены всегда быть вторым сортом, отработанным материалом, кой-как доживающим свой век, молясь чтобы не уволили. Потому что ваша собственная экспертиза на самом деле - превратилась в тыкву. Лошади на которых вы ставвили - сдохли. А попытки фигачить "по аналогии" играют с вами дурные шутки зачастую. > А с macos за три года как думаешь, сколько проблем было? Ну, угадай? Мне это не интересно. Я не ищу себе рабовладельцев, которые лучше меня знают как мне збс и каков мой путь. Это моя привилегия - определать пути и задачи. Стоять на этом пути не стоит. > А вот со всякими дебунтоидами до того таки да, случалось. Правда вот > решалось примерно "все" без отката-на-снапшот, да. В эппле блин - захочешь не откатишься. Особенно на iDevice. Видел я рожи фанов марки когда им вкатили супер-иконки добровольно-принудительно - и откатиться нельзя. А со мной так почему-то работать не будет. От таких фирм лично мне ничего не нужно. Как говорят, мягко стелят да жестко спать. А некоторые услуги идут в комплекте с слишком высокой ценой. > И все это патамучта комп у меня вот не твоя помойка и > экспериментирую я по виртуалочкам, что - см. выше. Ну уж не клиенту Accenture про помойки вещать :). А что он наэкспериментировал - прекрасно видно по тривиальному факту: ему и эта куча безблагодатной индусни - архитекты. И у него даже хватает (регресса) IQ козырнуть этим. Не понимая насколько зашквар :D > Да-да, в два раза быстрее по заказам ездишь будешь. Верю. Так маме и говори. Что если не "быстрее" а "денежнее"? :) Открыв новые горизонты и небедных клиентов. Всякие индустриалы - не бедствуют, например. И если я за полцены решу задачу, это то что называется "день год кормит". Я не буду произносить сколько я могу рубануть за забег, ты не поверишь. Но просто прими как факт: если мне повезет, я за несколько дней сделаю столько сколько ты будешь делать 1-2 месяца. Со всеми твоими Accenture которых я в гробу видал. А в чем разница? Я нарулив проект - свалю отдыхать куданить. А ты будешь в своем печальном офисном булшите, в рабском 5/2 c 9 до 17. И ты будешь учить меня кто тут не лох? :) >> Он у меня перед моим носом, дедуля. > Ну извини - твой дысктоп вне моих профессиональных интересов. Меня и мой-то > не особо в этом смысле интересует. Да я уже понял что твои профессиональные интересы это хомячить и загибать пальцы. Ничего другого ты все равно не умеешь. Козыряние эплом и виндой вот лично тебе - никаких заслуг не добавляет в послужной список. Это вообще не твои заслуги - а вон тех корпов. Примазатся к ним может и условная баба Клава, это и есть твой уровень в айти. > Ну, то, что ни о шинах данных, ни о БД ты не > знаешь вот совершенно ничего - установлено вполне себе достоверно. Вот тут вы совсем не угадали. Я могу знать о них достаточно много - если это становится зачем-то надо и что-то измеримое дает. А чисто по приколу грузить себе мозг - ну вот нет, в этом мире уже слишком дохрена знаний. И оптимизация того что и почему я вгружаю - в приоритете. AI кстати очень круто подыгрывают в этом - итеративно совместными усилиями можно быстро апгрейднуть экспертизу в энном топике где я был изначально слаб. И это расширяет мой ареал обитания. Все что надо - спросить правильные вещи. Но вы - не сможете даже это. > С тем, что ты "знаешь" определенности достичь не получилось - но мы все > еще стараемся. Не может же это быть одно большое "ничего", правда? Это может быть одно большое ЧСВ с попыткой видеть везде такие же никчемности как оно само. И это кажется не про меня. Когда у вас будут лично ваши проекты и вы сможете сказать ЗА СЕБЯ что вы из себя представляете - и чего лично ВЫ достигли - с вами можно будет о чем-то говорить на эту тему. >> Мне вот - надобится. > Замечательно. А кому-нибудь чего-нибудь практически полезного сделать не пробовал? Ну, > кроме тебя и твоих воображаемых друзей? "Работа" называется, знаешь? За неё > еще деньги платят. У меня есть целый свой бизнесок вокруг околоэмбедовки. Когда у вас будет своя фирмочка, пусть даже с одним вами как сотрудником - будет смысл с вами о чем-то говорить. А так вы в отрыве от ваших эплов, майкрософт и где вы там рабоатете - ничто. Пустое место. И я это отлично чувствую. Носители такого modus of operandi ощущают это отличие на уровне чуть ли не подсознания. И мы никогда не будем коллегами. Потому что таких как вы такие как я - презирают. >> Можно видите ли - > ... не путать одно с другим, но получается у поподвальных это вот > через раз - обычно после того, как мордочкой понатыкают. Ну вот я немного потыкал вас чтобы вы не зарывались. Вы сами по себе - не имеете ни единой заслуги где вы могли бы выйти и сказать "Я СДЕЛАЛ ЭТО!" - и показать ЭТО, конечно. В виде когда не будет возникать вопросов почему это было круто.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #285 Ответы: #328

305. Сообщение от Аноним (-), 12-Окт-26, 18:12	–2 +/–
> а чанки - размером с pagesize. Ага. И  Теперь представь, сколько > их даже на 1 гиг выходит и как там с поиском > нужного чанка дело обстоит ... Да, мне еше интеерсно - в Linux нынче в моде folios так то. Что они будут делать если апя без folios просто повыпилят нахрен? И конечно ворочание подшивками сильно более 4 кил за присест - снижает оверхед. И разгоняет всякие IOPS и GBPS на сверхскоростных девайсах. Даже у btrfs, ага. Который УЖЕ на однодисковом быстром ssd - ZFS'у в обычном незамороченном бенче мастеркласс дает буквально - везде. Чуть не в разы при том. Хотя его оптимизнули лишь местами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #246

307. Сообщение от Аноним (-), 12-Окт-26, 22:37	–1 +/–
> а когда они придут сломать тебе твою любовно построенную этажерку (потому что > могут!) - уже всем будет похрену. Может он к тому моменту три новые этажерки построит, намного лучше, так что ему останется разве что сказать "спасибо что прибрали тут мусор"? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #241 Ответы: #332

308. Сообщение от Аноним (-), 12-Окт-26, 22:48	–1 +/–
>> а в чем проблема сделать ext5? религия не позволяет? > гранты платиновых спонсоров не позволяют. > Те не собираются вносить двойную оплату, Согласно Теодору Тсо правда жизни немного иная. Дизайн просто выжат до предела и время таких дизайнов просто - закончилось. И нет никакого смысла убивать на него свои ресурсы. Если кто не заметил - даже этот ваш XFS - есть XFSv4 который - тадам - легаси! И который - тадам - будет задропан, в 2030 чтоли. И есть XFSv5 который умеет в какие-то урезанные, но все же диалекты cow и чексум, рефлинки, вот это все. В общем "кругом заговор" :) > а в виду шта6ле нонсенса - второй клон фс сам себя не поддержит. И именно поэтому на сверхскоростных SSD будет Linux - и будут все остальные со своим штабле крапом. Потому что да, линух - запилит folios, и там где остальные телепают гигазы по 4 кило страничке, эти будут воротить по целой подшивке за присест. С кратным снижением оверхеда. И при взгляде на бенчи ни у кого не будет вопроса почему Торвальдс - прав. А проблемы индейцев шерифа и правда не волнуют. Так что вы там сами поспевайте за актуальными апями. Вечно таскать легаси апи с кучей оверхеда при ограниченных ресурсах на майнтенанс никто конечно не будет. И вот вас даже тут - предупредили. > (на самом деле изрядно нае..лись с ext2 и потом ext3, это реально > было крайне хреновое решение, и, поскольку гугль не собирался делиться патчами > - проще было зак0пать, чем оживлять те трупики. А деду еще > не было и 50, он был еще полон сил и энтузазизьма.) Просто сейчас он заметил что на горизонте появились более перспективные дизайны и апя, так что бухать оптом ресурсы в гальванизацию трупа смысла мало. Это как раз превращение в синьора/PM'а. А к некоторым старость приходит одна - и они уверены что роялит только coding skill. Что и является - ацким факапом карьеры програмера. И это - закат карьеры. Позорный и безрадостный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #167 Ответы: #309

309. Сообщение от пох.. (?), 12-Окт-26, 22:59	+/–
> Согласно Теодору Тсо правда жизни немного иная. правда жизни согласно теодору: "but I haven't been able to find a customer willing to pay the development costs" это все что надо знать о Теодоре. Это человек получающий зарплату от IBM чтобы делать и говорить то что велит ему - IBM. И мешать всем остальным там где это противоречит интересам IBM. Никакого "just for fun" в его (и прочих клоунов-майнтейнеров) деятельности нет, даже если когда-то и было, и это не было просто прогревом гоев. А, хотя не все, вот еще: "These days most my time is spent doing code review and running tests and improving the {kvm,gce,qemu,android}-xfstests test appliance. And I very much rely on 2 or 3 other developers working at SuSE and IBM to help out with the code review." то есть дедушка даже code review переложил уже давно на других.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #308

310. Сообщение от пох.. (?), 12-Окт-26, 23:13	+/–
>>а вот это ты узнаешь когда научишься кодить ;-) > При чем тут "кодить" и конкретная реализация ФС...? ты спрашиваешь - > Там реально хоть одна проблема то есть...? я тебе отвечаю - научишься кодить - узнаешь, есть или не есть. А пока вот: >>пока есть личное мнение дедушки на зарплате ibm (которой работающая ext4 вообще не нужна) который пять лет назад признавался что кодить давно разучился, и ни на каком инструменте не играет, он руководитель. >>(в основном причем погоняющий бесплатновую рабсилу) > Пока ничего не ясно. Конкретика есть? если ты имеешь в виду что я за тебя полезу разбираться в коде и принесу тебе результат на блюдечке, или кто-то еще с подобной квалификацией это сделает - то нет, такой нету и вряд ли будет. К тому же не очень понимаю с чего ты готов поверить мне или какому-то другому васяну с опеннета, а не дедушке. дедушка, лет 25 назад, когда еще был всего лишь уже немолодым человеком - сам (вроде, я со свечкой не стоял) руками это все написал. Стоит ли верить его мнению - это уж сам решай. Своим глазам - верить, безусловно можно. Но надо кое-что знать и уметь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #303 Ответы: #329

311. Сообщение от Кирилл (??), 12-Окт-26, 23:19	+/–
Это не меня порвало, это местный автобан считает слово "гугл" матерным.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #300

312. Сообщение от Кирилл (??), 12-Окт-26, 23:25	+/–
Мне нужен работающий, не ломаемый, не выпиливаемый функционал. И да, я в упор не вижу никакого нового функционала в 2-3 последних ветках какого нибудь 2гис, хотя там полностью переломали интерфейс в сторону "хрен сделаешь", увеличили требования к памяти и процессору более чем раз в 20 (обрати внимание, число объектов на карте почти не увеличилось а картинка осталась прежней, просто её теперь рисуют через задницу). Реклама это не новый функционал. Поиск по всей россии того что ты ищешь в конкретном городе - не функционал а бага.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #302

313. Сообщение от Кирилл (??), 12-Окт-26, 23:31	+/–
Или какой нибудь vlc. Где там новый функционал? Ему просто 3 раза перерисовали интерфейс и под каждую новую версию андроида переписывают управление памятью, питанием и сном. В итоге с вероятностью в 75% текущий интерфейс является для тебя "хуже чем был", а чтобы плеер не убивался при паузе и блокировке экрана нужно лезть в репу и вручную подбирать версию под твой андроид. Ну ладно, это мелочи. А прогресс то где?! И это мы говорим о платформе с особенностями, под которую ОЧЕНЬ адекватная команда разработчиков ынуждена плить свой продукт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #302

314. Сообщение от пох.. (?), 12-Окт-26, 23:43	+/–
> Это как раз самая вероятная причина - сейчас идут черепичники.И у многих они ни в каких скрытых потерях данных не замечены. Они просто жутко медленные при произвольной записи. И иногда просто дохнут. Если у гибридных слетит таблица - они просто отыквятся, без всяких скрытых ходов, даже опознаваться перестанут как устройство. и обычные диски никуда не деваются, smr были и остаются в самом дешевом углу рынка. что wd gold, что exos'ы, что тошибы Nseries по прежнему где были там и остались. единственное исключение - позорная история барракуд, переименованных в про, чтобы дать место мусору с пола цеха под тем же именем. Через некоторое время сигейт спохватилась, про быстренько зак0пали, но все куды >8T снова cmr. (К покупке все равно настоятельно не рекомендую, но чудо-повреждений данных у них тоже не бывает.) Кстати, куды превращались в тыковку (тоже из-за повреждения некоторых внутренних данных) задолго до smr и нанд-схем. Опять же никакие контрольные суммы тут тебе не помогли бы - оно с негромким "чпок" становилось 0 байт емкости.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #278 Ответы: #318

315. Сообщение от пох.. (?), 12-Окт-26, 23:48    Скрыто ботом-модератором	+/–
> Еще веселее когда у тебя ВНЕЗАПНО - бабах - readonly filesystem! Бабах > fsck - опа, а теперь совсем фаталити. А план на этот опять врунишка выдает на гора какие-то свои фантазии и что-то прочитанное в интернетах. > А в чем прикол? У кого оператива глючит. У кого проц сбоит. > А кому - вот - драйвер Nvidia память бил, прямо эпидемия от этого точно помогут контрольные суммы фс, местный анонимный кексперт- восстановитель данных зуб дает. господи, ну как можно такую чушь нести?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #276

317. Сообщение от Аноним (-), 13-Окт-26, 00:02	–1 +/–
> Нет, тут я протестировал усиление записи. Для zfs и btrfs результаты по > WA представлены в двух вариантах -- для случая когда сжатие выключено > (да, я знаю как это делается, представь себе) и для случая > когда сжатие включено (zstd-1 в обоих случаях). Для ext4 и xfs > результаты по очевидным причинам представлены в одном варианте. Ну ты то тестировал наверное что-то более реалистичное, а не ультра-синтетику где господа вероятно писали - один 4K блок - с форсированным sync этого всего, чего доброго там еще какой-то dirty до них был - и вот так да, можно и 64x наверное получить. Вот только это - показуха а не крейсерское состояние дел. При том академик с своим пафосом вообще куда-то делся, и никакого ФС вообще на публику не зарелизил. А похонах в виндусях отвисает с NTFS позорным.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #292 Ответы: #327

318. Сообщение от maximnik0 (?), 13-Окт-26, 00:03	+/–
>они ни в каких скрытых потерях данных не замечены Повреждаются файлы ,если бы не BTRFS я бы про это дело хрен узнал бы.Может у 3,5 все и хорошо,а вот с ноутбучными так мне не везёт -2 года и наченяються байтики портиться.И при этом SMART щука молчит пока специально полную проверку не устроит, только тогда переназначенные сектора вылазят :-( Радует только одно -как чуял была возможность набрал дисков, сейчас цены улетели в космос.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #314 Ответы: #322

320. Сообщение от пох.. (?), 13-Окт-26, 00:25	+/–
> Нет, тут я протестировал усиление записи. Для zfs и btrfs результаты по > WA представлены в двух вариантах -- для случая когда сжатие выключено тогда что-то это странное. Не сходится с тем что я знаю о внутренних структурах. И подозрение падает таки на iostat как средство контроля. > (да, я знаю как это делается, представь себе) и для случая я бы на эту zfs пожалуй бы повнимательней посмотрел. насколько я знаю (это могло устареть, поскольку я не имею дел с zol) отключение сжатия (не несжимаемые файлы а compression=off) отключает заодно и variable blocks (и embedded туда же). Т.е. если ты ничего не трогал, она должна начать писать 128k блоками. > По умолчанию ext4 журналирует только метаданные, так же как и xfs. И вот попробуй выключить методом nojournal эти метаданные там очень недешево обходятся в некоторых случаях. ну и нет еще одного тестового паттерна во всем этом - а что происходит если мы в существующем файлике что-то пытаемся поменять (привет вон недавнему journald позорищу)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #292

321. Сообщение от пох.. (?), 13-Окт-26, 00:41	+/–
> данными предполагает создание файлов от 512B до 512KB (хотя на самом > деле можно было остановиться на 128KB, на результатах это не сказалось кстати, зря. И результат для Zfs должен быть очень заметен, и еще интереснее если добраться до двух мегабайт. в dnode помещаются только три указателя, и не спрашивайте как так ;-) Т.е. с 372k+1байт начинается магия. опять же если эту разницу будет видно в твоем тесте - это подтвердит что тест действительно меряет wa а не погоду на марсе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #292

322. Сообщение от пох.. (?), 13-Окт-26, 02:31	+/–
ноутбучные больше терабайта - все smr, чудес-то не бывает, не впихнуть в этот размер ничего больше. Последними cmr были терабайтные hgst. но я бы подозревал в порче байтиков все же не smr а память того ноутбука. ремапы это другая история, это сектор просто не читается/читается за неприемлемое время. пока не попытаешься прочитать - не узнаешь, smart о нем тоже не узнает, так что тут все со смартом в порядке. с любой фс результат будет совершенно одинаковый - повисание программы и сбои сектора в dmesg, когда ты наконец попытаешься его прочитать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #318 Ответы: #325

324. Сообщение от пох.. (?), 13-Окт-26, 02:44	+/–
это отключит scatter. но не сам ненужный механизм abd.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #268 Ответы: #326

325. Сообщение от maximnik0 (?), 13-Окт-26, 02:48	+/–
>но я бы подозревал в порче байтиков все же не smr а память того ноутбука. Сутки гонял тесты , нечего memtest не нашел.А ошибка у меня вообще прикольная была- каталог очень давно не лазил,решил удалить.Так байтики повреждённые оказались, но Btrfs поченил , там именно байты,crc коррекции хватило.Но я не мог каталог удалить-откат транзакции из за некорректных методанных,b-дерево инод.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #322

326. Сообщение от Аноним (162), 13-Окт-26, 05:01	+/–
Разве abd появился не вместе с zfs?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #324 Ответы: #331

327. Сообщение от Аноним (162), 13-Окт-26, 06:25	+/–
> подозрение падает таки на iostat как средство контроля iostat показывает то же самое что и nvme-cli или smartmontools. Если не доверять самрту ssd, то я не знаю чему тогда ещё доверять... > насколько я знаю отключение сжатия отключает заодно и variable blocks Впервые о таком слышу. Насколько знаю я эти механизмы никак не связаны, кроме того что эффективность сжатия зависит от размера блока. И полученные цифры это подтверждают. > вот попробуй выключить методом nojournal На ext4 я отключал журналирование. И не только его, но так же пробовал отключать барьеры и включать writeback. Данных не сохранилось, но насколько я помню ни в одном из вариантов (и их сочетаниях) я не получил какого-то заметного выигрыша ни по скорости, ни по усилению записи, поэтому я быстро отказался от этих экспериментов. Как отключение журнала действует на xfs не проверял, подозреваю что тоже незначительно, т.к. объём записываемых метаданных слишком мал чтобы оказывать какое-то заметно влияние. > нет еще одного тестового паттерна во всем этом - а что происходит если мы в существующем файлике что-то пытаемся поменять В blogbench это есть. В нём можно отдельно настраивать количество чтений, записей, перезаписей и коммитов. > можно было остановиться на 128KB, на результатах это не сказалось > кстати, зря. И результат для Zfs должен быть очень заметен, и еще интереснее если добраться до двух мегабайт А вот это по-моему абсолютно бессмысленно, т.к. по моим наблюдениям на WA больше всего влияет именно мелкоблочка (до 4КB). При записи таких крупных блоков zfs просто будет шинковать их по 128KB да и всё (если отдельно не настраивать recordsize). Кстати, пробовал менять ashift. Если установить ashifs=9 вместо стандартных сейчас ashift=12, то усиление записи действительно можно немного снизить. Не сильно, но заметно (как раз за счёт мелкоблочки видимо), причём без заметного падения производительности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #317

328. Сообщение от User (??), 13-Окт-26, 08:03	+/–
> В офисе например, у любой фирмы которая не хайпует а оптимизирует перфоманс-затраты. У них вот VDI или ноутбуки - 2026 год на дворе, Нео. > А что - давай? У меня есть пару ноутов. Они в целом просто работают. И мне не надо их       > распадлоидизировать и они ведут себя так как надо - мне, а не майкрософту. Так ты ж тут рассказывал, что снапшоты(ТМ) позволяют тебе факапиться не через раз, а вот через три и быстро подскакивать с "а и не было ничего!", нет? А у меня вот последние лет несколько зубов в этих труднодоступных местах немае, хвала-аллаху-милостивому-и-милосердному. > Кроме того - ты уж извини, "экспертище", но w11 это не твоя заслуга. А результат работы >oem, MS и проч. Ну конечно. Это же ж бытовая техника, а не предмет культа. Вон - в машине под задницей тоже моей заслуги ровно 0 - ездит, между гарантийным ТО моск не делает, гарантия пройдет - поменяю, и нет - не на раздолбаный жЫгуль "зато-каждый-болт-своими-руками-крутил!" > Что если не "быстрее" а "денежнее"? Ну можно и "денежно" - бабушек вот на "настройку компьютера с телефоном" разводить. Я ж особенности твоей бузинес-модели не знаю - ты от моссада-с-цру прячешься. > Козыряние эплом и виндой вот лично тебе - никаких заслуг не добавляет в послужной список. Нео - это просто "компьютер", он у каждой домохозяйки дома есть и она с ним прекрасно справляется. Твои АФИГЕННЫЕ "навыки работы с ПК" в резюме никого уже не впечатлят, забудь! > Я могу знать о них достаточно много Можешь. Но почему-то не знаешь. Чудеса прям какие-то, что не спроси - везде "сложный-пресложный для парсинга json который вот-никак-никак с хорошей производительностью не" оказывается. > У меня есть целый свой бизнесок вокруг околоэмбедовки. И развозка пиццы в перерывах между восстановлением фоточек - для души. Да, верю. > Ну вот я немного потыкал вас чтобы вы не зарывались. Ну, если ныряние лицом в лужу с криками "это не я!" так называется - то да, "потыкал".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #304

329. Сообщение от Sm0ke85 (ok), 13-Окт-26, 08:35	–1 +/–
>ты спрашиваешь - > Там реально хоть одна проблема то есть...? >я тебе отвечаю - научишься кодить - узнаешь, есть или не есть. Ты глупости пишешь несусветные... >если ты имеешь в виду что я за тебя полезу разбираться в коде и принесу тебе результат на блюдечке Т.е. Ты кодить не умеешь или что? И при этом рассказываешь другим, что кодить нужно уметь...? Как у тебя это все в голове работает...? Поясни...?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #310

330. Сообщение от Frestein (ok), 13-Окт-26, 12:41	+/–
А эти миллионы в курсе, что у них работает?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129

331. Сообщение от пох.. (?), 13-Окт-26, 13:01	+/–
нет. л@п4@тое гуано имени дельфикса. Как и большинство других современных проблем zfs. При этом им удалось протолкнуть его в апстрим, хрен уж его знает чем там думали. (но там ничем особо не думали, там в примерно том же интервале вообще сломали ARC, и сломавший просто перестал отвечать на письма. Пол-года всем было похрену.) Если браться make great again - надо выбросить _все_ что понаделано дельфиксами не разбираясь. А потом очень тщательно изучать оставшееся - потому что там тоже все очень и очень плохо. И только когда и если удастся это все зачистить и протестировать - можно вернуться к рассмотрению идей (но ни в коем случае не кода!) этих линуксолюбов. В общем, ... или сам Ходжа тут наиболее вероятный сценарий. p.s. да, тестов нормальных тоже нет. то что есть - выкрасить и выбросить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #326

332. Сообщение от _ (??), 13-Окт-26, 16:50	+/–
Так редко кто нонче __новые__ этажерки строит то, всё больше новые версии старой... :-\ Даже семантик версионирование отовсюду выпилили чтоб у немамонтов вопросов ненужных не возникло :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #307

333. Сообщение от Аноним (333), 14-Окт-26, 07:25	+/–
да, собственно не в курсе. как и о опициях metadata checksum и t10 dif/dix...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

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

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