forum.opennet.ru - "В ФС Ext4 намечен к удалению режим data=journal " (308)

"В ФС Ext4 намечен к удалению режим data=journal "

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

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

Оглавление

Хлебом не корми - дай да выпилить что-нибудь что не сломано и жить не мешает , Аноним (1), 09:51 , 09-Окт-26, (1) +26

приводит к значительному снижению производительности не сочетается с некоторы, A.Stahl (ok), 09:54 , 09-Окт-26, (2) +24

Если б мешает реализации новой функциональности было про мешает внедрению cop, Kilrathi (ok), 10:12 , 09-Окт-26, (8) +12

Бггг Ну вы ж по иному не возжелаете поработать для гугля и эй-би-эм б 821 е 82, Аноним (70), 14:31 , 09-Окт-26, (70) –6
Если в части отказоустойчивости вы полагаетесь на ФС - вы уже очень сильно обо, User (??), 19:38 , 09-Окт-26, (113)

О том что стратегии можно при наличии головы совмещать и оптимизировать - клиент, Аноним (132), 23:35 , 09-Окт-26, (132) +1

И натянул четвёртый слой резинотехнической защиты на свечку - ну, для НАДЁЖН, User (??), 06:47 , 10-Окт-26, (154)

Ты не понял Снапшоты в правильном CoW - значительно дешевле бэкапов и фигачит, Аноним (-), 00:12 , 11-Окт-26, (208)

Оу А для тех, кто считает снапшоты бэкапами в пятёрочке самая лагучая касса, User (??), 07:21 , 11-Окт-26, (216)

Этот тип начал о чем-то догадываться Эти технологии не заменяют друг друга а, Аноним (-), 11:10 , 11-Окт-26, (228)

и натянул вот еще четвёртый, ага Сыночка - эти вот твои аналоговнетные снап, User (??), 11:18 , 11-Окт-26, (229)

Про виртуализацию тут никто и не вспомнил, кроме тебя Так что, не пиши лишнего,, alexanderyt (ok), 17:36 , 11-Окт-26, (252)

Да не мешайте вы ему Клиентом Accenture становятся не от избытка экспертизы, та, Аноним (-), 17:43 , 11-Окт-26, (254)
Ну и зря так-то не вспомнил Мне вот еще один уровень снапшотов поверх того, что, User (??), 18:31 , 11-Окт-26, (257)
Зелен виноград, yada-yada Правда жизни проста Это некромант-бсдшник или древни, Аноним (-), 20:48 , 11-Окт-26, (266) –1

Дедуля, в отличие от тебя я не убиваю время на переустановку систем при факапе, , Аноним (-), 17:41 , 11-Окт-26, (253)

Оу Так и я нет - decomission deploy ноды в 2026 чуть-чуть не так, как ты себе э, User (??), 18:43 , 11-Окт-26, (258)
А мы возьмем и рассмотрим вот прям твой десктоп ноут и проч И как там decomissi, Аноним (-), 22:49 , 11-Окт-26, (270)
Где ж я тебе тот дысктоп -то в 2026м найду А с ноутом - ну давай Как думаешь,, User (??), 07:50 , 12-Окт-26, (285) +1
В офисе например, у любой фирмы которая не хайпует а оптимизирует перфоманс-затр, Аноним (-), 17:56 , 12-Окт-26, (304)
У них вот VDI или ноутбуки - 2026 год на дворе, Нео Так ты ж тут рассказывал, ч, User (??), 08:03 , 13-Окт-26, (328)

Если она не нужна Опция она для этого и существует Вот это уже политическая бор, Аноним (10), 10:13 , 09-Окт-26, (10) +1
обеспечивает высокую устойчивость в случае сбоев ПС Сам пользуюсь этой опци, Аноним (11), 10:15 , 09-Окт-26, (11) +4

Классика opensource либо брать на себя поддержку режима, либо переходить на cow, Kilrathi (ok), 10:30 , 09-Окт-26, (19) +1

Если вас XFS устраивал то EXT4 тоже так то наверное с теми неполными режимами жу, Аноним (-), 17:40 , 09-Окт-26, (97)

Если просто в лоб сравнивать ext4 и xfs в режиме сферического коня в вакууме , Kilrathi (ok), 18:38 , 09-Окт-26, (100)

Что еще за ffs бжд Это какой-то ископаемый, из древних юниксов Necromancy is , Аноним (132), 23:34 , 09-Окт-26, (131)

ты восстанавливал сломанную фс или оно удобно, пока проблем нет если да, то дав, черпало (?), 00:56 , 10-Окт-26, (146) +2

Я не занимаюсь восстановлением сломанных фс в общем случае Компьютеры должны , Аноним (-), 00:39 , 11-Окт-26, (210) –1

Под ряд сетевых задач крутятся OpenBSD более 10 лет и кушать не просят, просто, , Kilrathi (ok), 08:43 , 10-Окт-26, (163)

Будем считать что я предпочитаю более современные и простые в эксплуатации решен, Аноним (-), 00:44 , 11-Окт-26, (211) –1

А как COW обеспечивает лучшую сохранность данных Наоборот, если повредится блок, Аноним (189), 16:12 , 10-Окт-26, (189)

Если это важно - надо избыточность юзать При том если на обычном RAID1 у вас , Аноним (-), 10:53 , 11-Окт-26, (225) +1

Простое же решение, в данном случае Нужен максимум производительности - не вклю, Аноним (26), 10:55 , 09-Окт-26, (26) +1

Бери raid , ананим.orig (?), 05:28 , 10-Окт-26, (152) –4

Вот уж блеснул экспертизой на весь опеннет Raid у него журнал оказывается замен, Аноним (-), 10:54 , 11-Окт-26, (226)

решается реорганизацией кода с сохранением отдельной подверсии подрежима В к, Кирилл (??), 20:44 , 09-Окт-26, (122) +1
Для реализации новой функциональности следует пилить EXT5 или ещё какую-нибудь в, Аноним (126), 21:24 , 09-Окт-26, (126) +2

Отчего так думаешь она как раз самая быстрая настоявшаяся, отполированная , да, черпало (?), 01:00 , 10-Окт-26, (147)
Теодор Тсо прямым текстом сказал что никакого EXT5 делать не будет Этот дизайн , Аноним (-), 11:04 , 11-Окт-26, (227)

А оно включено по умолчанию , Аноним (149), 04:30 , 10-Окт-26, (149) +1

Нет Если включить на ext4 полное журналирование, то она по скорости приблизится, Аноним (162), 08:33 , 10-Окт-26, (162) +1

У диванных анонимов так всегда Для них код как шкаф, который стоит в углу и ни, iPony128014 (?), 09:57 , 09-Окт-26, (4) +7

у диванных проггеров так всегда Для них код как шкаф, в котором ничего нельзя , Аноним (34), 11:30 , 09-Окт-26, (34) +10
Странно, но когда то существовал такой термин как legasy-код, из которого состоя, Кирилл (??), 20:47 , 09-Окт-26, (123)

Интересно даже, что же изменилось за 30 лет, да , derfenix (ok), 01:48 , 10-Окт-26, (148)

Изменились разработчики Точнее их изменили менеджеры Теперь на первом месте ра, Кирилл (??), 13:16 , 10-Окт-26, (175) +1

Фух, ну слава богу А то я уж подумал, что требования к софту теперь не те, что, derfenix (ok), 01:16 , 11-Окт-26, (213)

А о каких таких требованиях к софту вы подумали Кто требует выпускать новой вер, Кирилл (??), 10:15 , 11-Окт-26, (221)

Да понял я уже, что во всём виноваты злобные менеджеры, которые спят и видят тол, derfenix (ok), 13:18 , 11-Окт-26, (245)

Ты видел какие нибудь другие комментарии к какой нибудь новой и креативной верси, Кирилл (??), 11:59 , 12-Окт-26, (299)

Жаль, что ты не понимаешь ещё, что твой взгляд на мир - не единственный Если те, derfenix (ok), 12:05 , 12-Окт-26, (302)

Мне нужен работающий, не ломаемый, не выпиливаемый функционал И да, я в упор не, Кирилл (??), 23:25 , 12-Окт-26, (312)
Или какой нибудь vlc Где там новый функционал Ему просто 3 раза перерисовали и, Кирилл (??), 23:31 , 12-Окт-26, (313)

Мне даже интересно, это какие такие требования выдвинули пользователи андроида н, Кирилл (??), 11:40 , 12-Окт-26, (293)
В ФС Ext4 намечен к удалению режим data=journal , Кирилл (??), 11:42 , 12-Окт-26, (294)
Мне даже интересно, это какие такие требования выдвинули пользователи андроида н, Кирилл (??), 11:43 , 12-Окт-26, (295)
угрожая googлу boйkotom, и требуя выпускать по 1 версии системы ежегодно из за ч, Кирилл (??), 11:49 , 12-Окт-26, (298)

Трындец тебя порвало, чувак Иди поспи, что ли , derfenix (ok), 12:01 , 12-Окт-26, (300)

Это не меня порвало, это местный автобан считает слово гугл матерным , Кирилл (??), 23:19 , 12-Окт-26, (311)

Ничего странного И особо ничего не поменялось Зависит от проекта, требований и , iPony128014 (?), 06:49 , 12-Окт-26, (284)

Если противников наберётся достаточно - форкнут ext4 и будут сами поддерживать , опеншлёпивпродакшн (?), 10:33 , 09-Окт-26, (20) +1

Люди и дистры просто будут массово сидеть на LTS вышедшем перед проблемной сборк, Аноним (42), 11:54 , 09-Окт-26, (42) –1

Нет не будут Они и не такое-на-лопате жрали, жрут и будут жрать К чему иллюзии , _ (??), 19:17 , 09-Окт-26, (106) +4

Ждите девуанный форк, ага , User (??), 19:43 , 09-Окт-26, (116)

Если код только добавлять, но никогда не удалять, то любой проект становится unm, q (ok), 11:09 , 09-Окт-26, (31) +5

главное задавать его с безопасной дистанции - чтоб тебе при этом не задали встре, пох.. (?), 13:27 , 09-Окт-26, (61)

Зачем Потому что т пого б дла аргументов нет и в ход пойдут кулаки Ну так да, л, Аноним (95), 17:24 , 09-Окт-26, (95) –3

Зачем вы вообще хотите с такими говорить Чтоб продемонстрировать им, что они та, Аноним (11), 17:52 , 09-Окт-26, (98)
Пишите ваш код так, словно его будет сопровождать после вас маньяк знающий где в, Аноним (103), 19:00 , 09-Окт-26, (103) +2
То есть линксоиды новой волны считают всех заранее б м с ск м И лучше знают , Аноним (159), 07:18 , 10-Окт-26, (159) +1

Тонна бесполезной словесной софистики Удалять нужно не рабочее, сломанное, а не , Аноним (149), 04:36 , 10-Окт-26, (150) +1

Тебе прямым текстом сказали что сломано и жить мешает , Аноним (74), 14:52 , 09-Окт-26, (74) +2

Навешали лапши на уши а ты и рад слушать , Аноним (103), 19:00 , 09-Окт-26, (104) –3

Мне обоснование для удаления кода вообще не нужно , Аноним (74), 20:11 , 09-Окт-26, (121)

Ну, writeback, вообще, опасная штука Такое себе решение дропать журналирование , Аноним (3), 09:56 , 09-Окт-26, (3)

Если прочитать получше - журналирование никто дропать не собирался Дропают толь, Другой аноним (?), 10:07 , 09-Окт-26, (5) +1

Да, не подумал, что дети на тех форуме под новостью о полном журналировании в ко, Аноним (3), 10:10 , 09-Окт-26, (6) –5

Не нравится - используй btrfs, которая для этого и создавалась, полная транзакци, Другой аноним (?), 10:43 , 09-Окт-26, (23) –2

На домашней машинке как раз это со снапшотами Хорошая вещь Но проды ведь бываю, Аноним (3), 11:09 , 09-Окт-26, (30) –1

А если б даже и имел - случаи бывают разные Скажем нагруженный БД на cow класть, Аноним (132), 23:39 , 09-Окт-26, (133)

У меня диск отвалился, сильно много писал, китайчатина, если бы не btrfs, хрен б, bx (?), 15:13 , 10-Окт-26, (181)

Я на нескольких особо сыпучих штуках по приколу btrfs разложил с DUP как данных , Аноним (-), 11:21 , 11-Окт-26, (230)

Это наоборот к счастью, что умные дяди не разрешают тебе на бэтер переходить А , Аноним (196), 17:37 , 10-Окт-26, (196) +1

И как часто в ваш прод попадает свежайшее ядро я кернел орг Не знаю такого дист, Аноним (35), 11:40 , 09-Окт-26, (35)
В продакшене для отказоустойчивости используют надежные СХД с поддержкой внезап, похнапоха (?), 12:27 , 09-Окт-26, (49)

лучше - сразу облачка, на которых восседает святой дух внезапно, чтобы твои дан, пох. (?), 16:24 , 09-Окт-26, (85)

Кроме вафли на ONTAP, чего они не скрывают и о чем гордятся, в остальных случаях, похнапоха (?), 17:03 , 09-Окт-26, (93)

А что же там Ну так, ради интереса , bx (?), 15:15 , 10-Окт-26, (182)

Ну, внезапно если тебе нужно надёжное хранение данных, то избыточность, ec и вот, User (??), 19:51 , 09-Окт-26, (118)

нет, потому что тогда тебе придется эти данные писать на raw носитель И то - ис, пох. (?), 23:40 , 09-Окт-26, (134)

Ну раз критично аж в проде, то пиши скорее в lkml, предлагай проспонсировать сох, Аноним (91), 16:58 , 09-Окт-26, (91) –1

тут ты жрешь с лопаты то что одобрили платиновые спонсоры, и ничего кроме и нет, пох. (?), 16:19 , 10-Окт-26, (190)

У него выбор - шире чем у тебя, внезапно ты то вообще выбираешь из 1 спонсора, Аноним (-), 11:26 , 11-Окт-26, (231) –1

Вообще-то полное журналирование есть в ufs через geom под фрёй , Kilrathi (ok), 10:17 , 09-Окт-26, (14) +1

c silent data corruption works as intended, не забывай уточнять потому что журна, пох.. (?), 11:40 , 09-Окт-26, (36) +1
В UFS кривейший механизм soft updates, который так и не сделали нормально, а жур, Аноним (74), 14:56 , 09-Окт-26, (75) –2

Вроде как проблемы были в ранних версиях su, а позже поправили но сам еще со вр, Kilrathi (ok), 17:11 , 09-Окт-26, (94)

Я другой аноним, но у меня кривейший SU ассоциируется лишь c режимом SU J Т, Аноним (70), 18:52 , 09-Окт-26, (101) +1

Вот только кому весь этот адский кластерфак сдастся и зачем , Аноним (132), 23:41 , 09-Окт-26, (135) –1

А Вам не доводилось сталкиваться с потерей данных на ФС из-за падения питания А, sabitov (ok), 10:29 , 09-Окт-26, (18) +2

приходилосьна райзерелет так 27 назад - , онанист (?), 10:53 , 09-Окт-26, (24) +1
Я думаю, все с этим сталкивались, кто более-менее с компами работает и имеет опы, Аноним (3), 11:05 , 09-Окт-26, (28) +1
Больше похоже на коррапшен данных по вине диска, не запарковавшего голову, чем н, Другой аноним (?), 11:07 , 09-Окт-26, (29) –2

ты вот, к примеру - кажется, не совсем понимаешь Что на то и журнал что половин, пох.. (?), 11:46 , 09-Окт-26, (38) +1

Ситуация, описываемая автором настолько странная, что там либо кривая писалка бы, Другой аноним (?), 12:43 , 09-Окт-26, (51) –1

не, ну можно ж вообще не фсинкать а я хрен знает как всякие dpkg принято было п, пох.. (?), 12:54 , 09-Окт-26, (52)

В Unix Linux любые обновления файлов делаются путём создания в том же каталоге , Аноним (40), 11:53 , 09-Окт-26, (40)

По хорошему - да, через rename И поэтому ситуация, как у автора вызывает больше, Другой аноним (?), 12:38 , 09-Окт-26, (50) –1
хачю - делаю, не хачю - не делаю И чо ты мне сделаешь, я вообще в другом городе, пох.. (?), 12:57 , 09-Окт-26, (53)

Ну не тебе ж пришлось, а агенту А ему вообще без разницы, он железный Ты там н, Аноним (91), 19:00 , 09-Окт-26, (102)

да он, сссскотина, вопросы какие-то задает а я ж не настоящий сварщик, я б во, пох.. (?), 19:21 , 09-Окт-26, (107) –1

Эта возможность опция, можно блокировку отключить А юзер файлы записать без блок, maximnik0 (?), 22:22 , 09-Окт-26, (128)

xfs действительно страдал всяческими пропажами при упавшем питании ядра тогда к, Аноним (35), 11:58 , 09-Окт-26, (44)
У меня была такая же проблема на ноуте, только там был NVMe от Samsung, Evo 970 , Аноним (71), 14:32 , 09-Окт-26, (71)

Xfs вообще интересная в плане багов, занулять рандомные файлы тоже любит и никак, Аноним (46), 12:10 , 09-Окт-26, (46) –2

Что значит исправят У них в FAQ написано что это бай дизайн, Аноним (74), 14:58 , 09-Окт-26, (77) +1

да это просто местный гений-самоучка без мотора очередной фуфел нашел и без конц, пох.. (?), 19:26 , 09-Окт-26, (108) +1

Ну а беда-то в чём Ну выпала нода из кластера, и Или то ЕДИНСТВЕННЫЙ сервер был, User (??), 19:56 , 09-Окт-26, (119)

Это называется резервным копированием так то, а журналирование это сохранение вс, Метрика (?), 13:49 , 09-Окт-26, (66)

Ничего там опасного нет вообще Но только, если в программе правильно расставлен, Аноним (127), 21:41 , 09-Окт-26, (127)

А может лучше оставить пользователю выбор Или новый функционал, или полная усто, Аноним (7), 10:12 , 09-Окт-26, (7) +3

Ну так не обновляй ядро, и тебе не будет нового функционала и сохранишь полную у, Скрудж (?), 11:12 , 09-Окт-26, (32) –3

Все новости про уязвимости ядра мимо тебя прошли, да , Аноним (7), 12:08 , 09-Окт-26, (45) +2

Свобода выбора, в свободном софте , Аноним (149), 04:41 , 10-Окт-26, (151)

Подождите в журнал записываются не только метаданные, но и сами данные разв, Аноним (9), 10:12 , 09-Окт-26, (9)

Может дублироваться, но только до момента подтверждения записи всей транзакции н, Кирилл (??), 10:16 , 09-Окт-26, (12) +4
приводит, Вацлав (?), 10:17 , 09-Окт-26, (13) +1

Ложь Размер журнала фиксирован, он не увеличивается и не уменьшается Увеличива, Аноним (11), 10:21 , 09-Окт-26, (15)

да вроде нет Ты с journal inode не перепутал , пох.. (?), 12:58 , 09-Окт-26, (54)

Это ты что-то перепутал journal data это пипец , bx (?), 10:11 , 12-Окт-26, (289)

Приводит Но обычно для этого используют отдельный SSD накопитель , Аноним (16), 10:29 , 09-Окт-26, (16)

Который за 100 рублей купили , bx (?), 10:12 , 12-Окт-26, (290)

Записать нужно два раза, да, но копию в журнале после подтверждения записи можно, Аноним (74), 14:59 , 09-Окт-26, (78)

Но ведь сейчас ИИ из всех утюгов с историями успеха по сопровождению кода, как э, Аноним (17), 10:29 , 09-Окт-26, (17) +1

Сопровождает Успешно Не бесплатно Крупные корпы сидят на xfs и btrfs судя по, Аноним (25), 10:55 , 09-Окт-26, (25) –1

ext4 замечательно работает поверх железных рейдов там все нормально и с тихими , Аноним (35), 11:54 , 09-Окт-26, (41) +3

ИБП Аккумуляторные И ДГУ И нахер с пляжа всех энергетиков, если дгу не заве, bx (?), 15:20 , 10-Окт-26, (184)

Ага, сейчас тебе пох еще расскажет как правильно нарулить упсу Чтоб заметить ч, Аноним (-), 11:29 , 11-Окт-26, (232) –1

ДГУ - это не совсем батарейки , bx (?), 10:14 , 12-Окт-26, (291)

да, собственно не в курсе как и о опициях metadata checksum и t10 dif dix , Аноним (333), 07:25 , 14-Окт-26, (333)

читая новость, приходит только одна мысль, про неосилили , RM (ok), 10:58 , 09-Окт-26, (27) +5

А у меня почему то про сахар в бензобак С яЪ - ну чё им бтрфс для опытов не, _ (??), 19:32 , 09-Окт-26, (110) +4

это кого надо нога И они дедулю в свой огород подкармливаться пускать не собира, пох.. (?), 12:16 , 10-Окт-26, (174)

Через 2 - морда не треснет Лет 5, если друзья не подключатся Ну или мы объяс, bx (?), 15:35 , 10-Окт-26, (186) –1

Печально что ядродевелоперы даже с помощью ИИ не могут осилить сопровождение соб, Аноним (34), 11:14 , 09-Окт-26, (33) +1

там как надо девелопер, старик а все сам делал Ну вот поэтому такие и пироги , пох.. (?), 11:47 , 09-Окт-26, (39) –1

Если это про Теодора - он уже давно всем объяснил что гальванизировать ЭТО - смы, Аноним (132), 23:44 , 09-Окт-26, (136)

ну так - складывай дедуля полномочия - и выметайся Устал - уходи Но нет Денежк, пох.. (?), 00:37 , 10-Окт-26, (144)

Ну так ты ж на замену не пришел если дедули уйдут - EXT4 совсем придется дроп, Аноним (234), 11:43 , 11-Окт-26, (234)

а что, кто-то звал Там дедуля на зарплате ibm, насколько я его мутные речи пон, пох.. (?), 13:04 , 11-Окт-26, (242)

Это немного не так работает В опенсорсе кому работа нужна тот ее и делает А на, Аноним (-), 18:00 , 11-Окт-26, (255) –1

Не не могут , а не хотят очевидно Почему - отдельный вопрос , Аноним (103), 19:02 , 09-Окт-26, (105)

Пыцаны btrfs же есть Зачем из ext4 делать btrfs, или я что-о путаю , Аноним (-), 11:55 , 09-Окт-26, (43)

Должен остаться только ntfs3g и fuse , Аноним (48), 12:14 , 09-Окт-26, (48) +1
Есть две работающие ФС это NTFS и ZFS, все остальное это попытка студентов в ФС,, Метрика (?), 13:44 , 09-Окт-26, (65) –3

одна, к сожалению ТОЙ zfs уже двадцать лет как тоже нет , пох.. (?), 19:28 , 09-Окт-26, (109) –1

Ну ежели так, то и XFS _той_ нет столько же , _ (??), 19:34 , 09-Окт-26, (111)

та была образцовым копропродуктом поздних 80х, в ней как раз ничего хорошего и н, пох.. (?), 19:43 , 09-Окт-26, (115)

А чего такого хорошего в блочнике-переростке с типа-переменными блоками для гало, Аноним (132), 23:54 , 09-Окт-26, (141)

Если не секрет, чем ТА zfs лучше ЭТОЙ , Аноним (162), 16:32 , 10-Окт-26, (191)

там статья на пять страниц неформат дляэтогосайта Если готов сам разбираться - , пох.. (?), 17:03 , 10-Окт-26, (193) +1

Т е претензий по существу нет Так и запишем , Аноним (162), 17:21 , 10-Окт-26, (194) –2

ты м-к, так и запишем нахрен вот ты спрашивал если тебя вообще не интересовал о, пох.. (?), 17:30 , 10-Окт-26, (195)

Свой палец ты сам знаешь куда можешь засунуть Своими словами ответь Или настол, Аноним (162), 17:38 , 10-Окт-26, (197)

на х-й пошел я не собираюсь общаться со свиньями Я отвечаю людям в предположении, пох.. (?), 17:45 , 10-Окт-26, (198) –1

Когда аргументов нет приходится переходить на оскорбления Понимаю Что ж, истер, Аноним (162), 18:18 , 10-Окт-26, (202) –1

Когда собеседник полный м-к и аргументы ему непонятны, и не за аргументами он пр, пох.. (?), 18:36 , 10-Окт-26, (204)

Если не становиться в позу оскорблённой невинности, то простой запрос к ДипСику , Neandertalets (ok), 13:17 , 11-Окт-26, (244) –1

лоханулся твой дикпик Налил ведро воды, а до вишенки так и не докопался Если бы, пох.. (?), 23:23 , 11-Окт-26, (279) –1

Не, на чо - зато с ним, родимым, ZFS на малинке причем, еще той самой заработа, Аноним (70), 01:43 , 11-Окт-26, (214)

Mem 25M Active, 101M Inact, 10M Laundry, 809M Wired, 34M FreeARC 383M Total, 9, пох.. (?), 09:24 , 11-Окт-26, (217) –1
Да как-то и жигули летают, особенно - ежели с высокого обрыва и почти вертикальн, Аноним (-), 18:04 , 11-Окт-26, (256) –2

Раньше солнце было зеленей, трава светила ярче, и ZFS - вот лучше был Ща, похон, Аноним (-), 11:48 , 11-Окт-26, (235)

А там нечего особо продолжать, abd c - каноничный пример улучшизьмов который , Аноним (70), 13:25 , 11-Окт-26, (246) –2

А ты неленивый, однако но зачем, тут некому это читать и понимать, а я и так з, пох.. (?), 13:34 , 11-Окт-26, (248) –1

Сделать zfs_abd_scatter_enabled 0 религия не позволяет , Аноним (162), 22:05 , 11-Окт-26, (268)

это отключит scatter но не сам ненужный механизм abd , пох.. (?), 02:44 , 13-Окт-26, (324)

Разве abd появился не вместе с zfs , Аноним (162), 05:01 , 13-Окт-26, (326)

нет л п4 тое гуано имени дельфикса Как и большинство других современных пробле, пох.. (?), 13:01 , 13-Окт-26, (331)

Да, мне еше интеерсно - в Linux нынче в моде folios так то Что они будут делать, Аноним (-), 18:12 , 12-Окт-26, (305) –2

Да, одна И это ext4 на raid6 , Аноним (196), 17:48 , 10-Окт-26, (199)

бльо ну откуда ж вы лезете , пох.. (?), 18:09 , 10-Окт-26, (201) –2

Btrfs не делает двойную запись при сохранении семантики примерно равной полному , Аноним (132), 23:46 , 09-Окт-26, (137) –1

У нее нет ничего похожего на полный журнал, и она делает не двойную а примерно 1, пох.. (?), 00:22 , 10-Окт-26, (143) –1

Это лишь вопрос точки зрения Т е механику commit rollback можно видеть и экспл, Аноним (-), 12:03 , 11-Окт-26, (237)

причем бы здесь - журнал данных Журнал не про комиты Журнал про линейность за, пох.. (?), 13:58 , 11-Окт-26, (249)

В конечном итоге цель всей этой возни - получение того или иного диалекта ACID-п, Аноним (-), 19:42 , 11-Окт-26, (260) –1

Btrfs имеет просто огромный оверхед Нам просторах интернета даже исследование н, Аноним (-), 14:08 , 10-Окт-26, (178)

Нет там никакого оверхеда, по крайней мере не при обычном повседневном использов, Аноним (162), 14:41 , 10-Окт-26, (180) –2

При обычном десктопном юзеже рост sectors written за скажем месяц - на btrfs vs , Аноним (-), 12:05 , 11-Окт-26, (238) +2

Вот у этого анонима лучше получилось - на 30 процентов показатели достигли потол, пох.. (?), 13:12 , 11-Окт-26, (243) –1

Среднепотолочный десктоп перешедший с EXT4 на BTRFS на рутфс норм пример как по , Аноним (262), 20:08 , 11-Окт-26, (262) –1
Ну я мерял На реальном железе с ssd запускал как тесты из состава phoronix blo, Аноним (162), 22:47 , 11-Окт-26, (269)

ну это что-то странное ты мерял И чем-то странным Я бы не очень доверял в этом, пох.. (?), 00:01 , 12-Окт-26, (280)

Ничего там странного нет Вместо iostat можно было использовать nvme smart-log , Аноним (162), 04:09 , 12-Окт-26, (282) +1
Если интересно, то вот пример WA по результатам теста на основе blogbench сжима, Аноним (162), 06:10 , 12-Окт-26, (283)

ты тут - сжатие протестировал собственно, с zfs btrfs это очевидно осталось тол, пох.. (?), 10:02 , 12-Окт-26, (288)

Нет, тут я протестировал усиление записи Для zfs и btrfs результаты по WA предс, Аноним (162), 11:03 , 12-Окт-26, (292)

Ну ты то тестировал наверное что-то более реалистичное, а не ультра-синтетику гд, Аноним (-), 00:02 , 13-Окт-26, (317) –1
iostat показывает то же самое что и nvme-cli или smartmontools Если не доверять, Аноним (162), 06:25 , 13-Окт-26, (327)
тогда что-то это странное Не сходится с тем что я знаю о внутренних структурах , пох.. (?), 00:25 , 13-Окт-26, (320)
кстати, зря И результат для Zfs должен быть очень заметен, и еще интереснее есл, пох.. (?), 00:41 , 13-Окт-26, (321)

Скорее всего это чатботы шалят опять Ну конечно, будто в ext4 всё остальное раб, Аноним (46), 12:13 , 09-Окт-26, (47)
интересно какой процент возмущающихся и почему использует журналирование содержи, pfg21 (ok), 13:03 , 09-Окт-26, (56) +2

ну мы когда-то давно обсуждали перспективу хранилки с быстрым ssd сейчас бы это, пох.. (?), 13:33 , 09-Окт-26, (62)

bcachefs но аффтЫрь чего то того , _ (??), 19:36 , 09-Окт-26, (112)

я показывал ссылку на статью 12го года про bcache без fs Все плохо С этим автор, пох.. (?), 19:45 , 09-Окт-26, (117)

Да вот как будто бы и пофиг уже Вона, даже в postgresql чексуммы на уровне стра, User (??), 20:11 , 09-Окт-26, (120)

И что будем делать если чексума не совпала - встанем колом и будем ждать бэкап т, пох.. (?), 00:46 , 10-Окт-26, (145)

Ээээ Ну вот pgpro автоматически данные с реплики запрашивает, что не так это , User (??), 06:46 , 10-Окт-26, (153)

нет parity - на случай отказа _носителя_ и только для этого При внезапном отказ, пох.. (?), 09:43 , 10-Окт-26, (164)

Эээээ там отдельно - highway hash для обнаружения и кодирование с избыточност, User (??), 10:17 , 10-Окт-26, (170)

ты неправильно проверял Положи вместо чанка - другой чанк Контрольная сумма - с, пох.. (?), 11:08 , 10-Окт-26, (172)

Ну, те-о-ре-ти-чес-ки возможность, что тебе отгрузят вот правильный datadir, пра, User (??), 14:04 , 10-Окт-26, (177)

в смысле Это и есть то что гарантирует data orderedХватит одного случайно восст, пох.. (?), 15:40 , 10-Окт-26, (188)

Поигрался Забавно, да На single-node instance все data-shards объекта доступн, User (??), 09:57 , 11-Окт-26, (220)

такая же вот фигня Поэтому надеемся на xfs, на которой такая подмена _вроде_бы_, пох.. (?), 11:32 , 11-Окт-26, (233)

Выкапывайте стюардессу JFS всмысле , Аноним (57), 13:06 , 09-Окт-26, (57) +1

Что-то, помню, она ломалась при любом нештатном выключении питания, требуя ручн, Аноним (59), 13:21 , 09-Окт-26, (59)
NILFS , Аноним (60), 13:24 , 09-Окт-26, (60)

devnullfs, Tron is Whistling (?), 15:01 , 09-Окт-26, (79)

Ее корпораст пилил, она работает Только фсчек надо из чрут запускать, а то ридо, Аноним (48), 16:10 , 09-Окт-26, (82) +1

Арчеводы не согласны https wiki archlinux org title Ext4 Disabling_journaling, Аноним (34), 13:34 , 09-Окт-26, (63)

Сколько не замерял, то, что они предлагают только снижает общую производительнос, Аноним (46), 13:50 , 09-Окт-26, (67) +1
Во-первых, Use the journal to optimize performance - это следующий пункт, сраз, Аноним (71), 14:40 , 09-Окт-26, (73)

Почему не сделаю ext5 если ломают обратную совместимость Что за идиотизм , EuPhobos (ok), 14:03 , 09-Окт-26, (68) +3

Почему - почему по - плану С , _ (??), 19:39 , 09-Окт-26, (114) +1
Теодор Тсо предельно ясно высказался по этому поводу Если ты святее папы римско, Аноним (132), 23:47 , 09-Окт-26, (138) –2

Всё отлично, но было бы хорошо, не получить мне сюрприз в самый неподходящий мом, EuPhobos (ok), 08:21 , 10-Окт-26, (161) +1

МВАХАХХАХАХХА и этот поц еще не в курсах про block size page sizeА вот приеха, пох.. (?), 09:58 , 10-Окт-26, (168)

Враньё NTFS вечно меняет версию ФС втихую И при подключении диска с новой NTFS, Аноним (189), 16:48 , 10-Окт-26, (192) –1

Только вот диски, отформатированные ещё в XP, почему-то работают в десятке , Аноним (207), 21:29 , 10-Окт-26, (207)

и наоборот работают, повторяю - каждая первая флэшка больше 4 гигабайт с 12 по 1, пох.. (?), 09:39 , 11-Окт-26, (218)

ну это же было достаточно давно, хотя неприятно посему у мну для хомяка ext3, а , Аноним (176), 13:20 , 10-Окт-26, (176) –1
С EXT4 лучше забыть про это желание Я как-то скатался к ВНЕЗАПНОМУ кирпичу с EX, Аноним (-), 20:29 , 11-Окт-26, (263) –2

Теодор Тцо, разработчик ext4, рекомендует переходить на Btrfs, как на более прод, DEF (?), 14:23 , 09-Окт-26, (69)

Значит теперь будут искусственно кастрировать другие файловые системы , Аноним (72), 14:36 , 09-Окт-26, (72)

Именно, в этом и смысл , Аноним (89), 16:36 , 09-Окт-26, (89) –1

Но где APFS не загнулась, NTFS тоже Хотя, не о тех вспомнил Начинаем NILFS, Q, yylloc (-), 23:14 , 09-Окт-26, (130) –1

Всё это сторонние фс в линксе не являются конкурентами btrfs https lkml org lk, Аноним (72), 00:01 , 10-Окт-26, (142) –2

Сведения 16-летней давности Какая милота И главное - все эти говорящие голо, Аноним (-), 12:07 , 11-Окт-26, (239)

Потом выйдет EvenBetterFS и все дружно на неё переходить будем , Аноним (76), 14:57 , 09-Окт-26, (76)

Есть же bacachefs Лучшая ФС Жаль только выпилили побоявшись конкуренции , Аноним (86), 16:26 , 09-Окт-26, (86)
А почему бы и нет Вам цифорка 4 в Ext4 ни на что не намекает Если будет лучше, Аноним (95), 17:30 , 09-Окт-26, (96)

Но на неё забил редкат , Аноним (42), 15:51 , 09-Окт-26, (80)
На СистемД перевели и тут никуда не денуться Организация одна и та же , Аноним (48), 16:13 , 09-Окт-26, (84) +1
А на ней система за 2 секунды загружается А файлы там сами себя пишут, сами пров, Аноним (57), 16:35 , 09-Окт-26, (88)

Не важно Не тебе решать что в линуксе юзать И не мне Да и с ним C , ну что, _ (??), 20:54 , 09-Окт-26, (125)
Две не две а одноплатник с 1ГГЦ 1 ядерным 32 бит процом секунд за 5 подымается , Аноним (132), 23:51 , 09-Окт-26, (139) –5

Получается журналирования данных не будет или есть какая-то другая опция , Инопланетянин (?), 16:13 , 09-Окт-26, (83)

Да, не будет Чтобы клиенты начали покупать специализированные средства , Аноним (92), 17:02 , 09-Окт-26, (92) –1
Журналирование никуда не делась Просто убрали не нужный функционал , Аноним (158), 07:15 , 10-Окт-26, (158) –2

удалить журналирование, которое каждый по желанию мог отключать сам это гипер, Cyber100 (ok), 16:32 , 09-Окт-26, (87) +2

тормоза как раз на медленных устройствах - буквально вот 8x write amplification , пох.. (?), 18:28 , 09-Окт-26, (99) –2

Ext4 - журналируемая файловая система Начиная с ядра 7 3 не журналируемая Как , Аноним (124), 20:48 , 09-Окт-26, (124) +2

Вообще XFS тоже такой полунедожурналируемый Как и JFS какой Полный журнал на к, Аноним (132), 23:52 , 09-Окт-26, (140) –1

Ты выдумываешь Такой классики не бывает , Аноним (158), 07:13 , 10-Окт-26, (157)

бывает, гугли про log structured fs Ну по дороге нагуглишь, конечно, почему быв, пох.. (?), 09:46 , 10-Окт-26, (165) –1

Log structured это по сути - диалект CoW технологии как таковой Просто оно у те, Аноним (-), 23:02 , 11-Окт-26, (274) –1

Да вот же - сабж Сперва в журнал, потом в основную область Классика жанра Отс, Аноним (264), 20:31 , 11-Окт-26, (264)

ZFS Тут все честно , Аноним (-), 14:20 , 10-Окт-26, (179) –1

там нет именно журнала данных Там за счет структуры фс чуть лучше с гарантиями,, пох.. (?), 09:43 , 11-Окт-26, (219) –1

Проблема в том что с его околоблочной структурой все это ему очень мало поможет , Аноним (-), 23:04 , 11-Окт-26, (275) –1

да, большая часть данных в озу - всегдатеряем данные так теряем, ни шагу назад, Alladin (?), 19:44 , 11-Окт-26, (261) –1

а в чем проблема сделать ext5 религия не позволяет нужно сломать то, что уже р, ятупойтролль (ok), 22:40 , 09-Окт-26, (129) +1

гранты платиновых спонсоров не позволяют Те не собираются вносить двойную оплату, пох.. (?), 09:55 , 10-Окт-26, (167) –2

Согласно Теодору Тсо правда жизни немного иная Дизайн просто выжат до предела и, Аноним (-), 22:48 , 12-Окт-26, (308) –1

правда жизни согласно теодору but I haven t been able to find a customer willi, пох.. (?), 22:59 , 12-Окт-26, (309)

А эти миллионы в курсе, что у них работает , Frestein (ok), 12:41 , 13-Окт-26, (330)

Этот древний хлам вообще давно пора выбросить из ядра Что заставляет людей при , Аноним (162), 06:48 , 10-Окт-26, (155) –5

Толсто Ext4 самая надёжная ФС , Аноним (158), 07:10 , 10-Окт-26, (156) +4

Это пока у тебя при обновлении что-нибудь не сломалось, и толку тогда от этой на, Аноним (162), 07:51 , 10-Окт-26, (160) –2

ну нет Ладно б еще ntfs3g, скажем Самая надежная - fat32 Максимальная избыточ, пох.. (?), 09:51 , 10-Окт-26, (166) –1
Уже есть Но костыльно - проверка только на чтение, есть специальная псевдо фс ,з, maximnik0 (?), 01:14 , 11-Окт-26, (212)

г-ди ну осильте ж вы уже md5sum , а я уж молчу про mtree, если ценность име, пох.. (?), 14:04 , 11-Окт-26, (250)

Ага, и вот ща буду каждый проект KiCad после очередного сохранения md5sum гонять, Аноним (264), 20:32 , 11-Окт-26, (265) –1
Тут куча народа писала- что у ext4 из за отсутствия контрольной суммы спокойно м, maximnik0 (?), 22:02 , 11-Окт-26, (267)

ну а ты свой мозг не мог включить и критично воспринять эту писанину Поврежденны, пох.. (?), 23:01 , 11-Окт-26, (273)

Это как раз самая вероятная причина - сейчас идут черепичники И у многих есть а, maximnik0 (?), 23:18 , 11-Окт-26, (278)

они ни в каких скрытых потерях данных не замечены Они просто жутко медленные пр, пох.. (?), 23:43 , 12-Окт-26, (314)

Повреждаются файлы ,если бы не BTRFS я бы про это дело хрен узнал бы Может у 3,5, maximnik0 (?), 00:03 , 13-Окт-26, (318)

ноутбучные больше терабайта - все smr, чудес-то не бывает, не впихнуть в этот ра, пох.. (?), 02:31 , 13-Окт-26, (322)

Сутки гонял тесты , нечего memtest не нашел А ошибка у меня вообще прикольная бы, maximnik0 (?), 02:48 , 13-Окт-26, (325)

Еще веселее когда у тебя ВНЕЗАПНО - бабах - readonly filesystem Бабах fsck - оп, Аноним (-), 23:08 , 11-Окт-26, (276) –1

Скрыто модератором, пох.. (?), 23:48 , 12-Окт-26, (315)

Подскажите, какая файловая система Linux лучше всего подойдёт для хранения данны, Аноним (173), 11:48 , 10-Окт-26, (173)

размер дисков-то какой И в чем цель хранения А то в диапазоне от ntfs3g до fat3, пох.. (?), 15:31 , 10-Окт-26, (185) –2
Скрыто модератором, Аноним (207), 21:27 , 10-Окт-26, (206)

Скрыто модератором, пох.. (?), 12:33 , 11-Окт-26, (240)

до дропа слегка барахлящих жёстких дисков на всяких там пульсирующих аэрокулах 3, Аноним (205), 20:48 , 10-Окт-26, (205)
Господи, разговоров-то Будто каждый второй использует data journal возможно, э, Аноним (209), 00:23 , 11-Окт-26, (209) –1

когда они пришли за коммунистами а когда они придут сломать тебе твою любовн, пох.. (?), 12:39 , 11-Окт-26, (241)

Может он к тому моменту три новые этажерки построит, намного лучше, так что ему , Аноним (-), 22:37 , 12-Окт-26, (307) –1

Так редко кто нонче __новые__ этажерки строит то, всё больше новые версии старой, _ (??), 16:50 , 13-Окт-26, (332)

В плане устойчивости к внезапным выключениям ничего лучше NTFS не встречал А Bt, Аноним (215), 06:37 , 11-Окт-26, (215)

а ты с винды-то слезать - пробовал У меня есть вот такое -rw-r--r-- 1 root root, пох.. (?), 13:25 , 11-Окт-26, (247)

использую data journal всегда и везде, производительность устраивает они там о , Аноним (222), 10:29 , 11-Окт-26, (222)
безумие какое-то с data journal ext4 действительно надежная и быстрая fs на что, Аноним (222), 10:32 , 11-Окт-26, (223)
скажем ACID не будет работать на 100 если fs не гарантирует консистентность ex, Аноним (222), 10:34 , 11-Окт-26, (224)

если твой acid пишет транзакции printf ом не проверяя возвращаемое значение - не, пох.. (?), 11:59 , 11-Окт-26, (236)
Большинство если не все реализации БД и проч - таки умеют жить с ТОЙ семантикой , Аноним (-), 23:10 , 11-Окт-26, (277)

ext4 надежная система, никогда на ней данных не терял но и никакого data journa, Alladin (?), 19:41 , 11-Окт-26, (259)
Прочитал новость, объяснения выпиливания - глупые абсолютно, смотрятся как детск, Sm0ke85 (ok), 09:18 , 12-Окт-26, (287)

а вот это ты узнаешь когда научишься кодить - пока есть личное мнение дедушки н, пох.. (?), 12:03 , 12-Окт-26, (301)

При чем тут кодить и конкретная реализация ФС Пока ничего не ясно Конкрети, Sm0ke85 (ok), 13:44 , 12-Окт-26, (303)

ты спрашиваешь - Там реально хоть одна проблема то есть я тебе отвечаю - на, пох.. (?), 23:13 , 12-Окт-26, (310)

Ты глупости пишешь несусветные Т е Ты кодить не умеешь или что И при этом ра, Sm0ke85 (ok), 08:35 , 13-Окт-26, (329) –1

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

1. "В ФС Ext4 намечен к удалению режим data=journal " +26 +/–

Сообщение от Аноним (1), 09-Окт-26, 09:51

Хлебом не корми - дай да выпилить что-нибудь что не сломано и жить не мешает.

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

2. "В ФС Ext4 намечен к удалению режим data=journal " +24 +/–

Сообщение от A.Stahl (ok), 09-Окт-26, 09:54

>жить не мешает
приводит к значительному снижению производительности... не сочетается с некоторыми возможностями...и мешает реализации новой функциональности

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

8. "В ФС Ext4 намечен к удалению режим data=journal " +12 +/–

Сообщение от Kilrathi (ok), 09-Окт-26, 10:12

Если б "мешает реализации новой функциональности" было про "мешает внедрению copy-on-write" - это одно, а вырезать у фс единственный отказоустойчивый режим до/без внедрения альтернативы...

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

70. "В ФС Ext4 намечен к удалению режим data=journal " –6 +/–

Сообщение от Аноним (70), 09-Окт-26, 14:31

> а вырезать у фс единственный отказоустойчивый режим до/без внедрения альтернативы...
Бггг.
Ну вы ж по иному не возжелаете поработать для гугля и эй-би-эм б̵е̵с̵п̵л̵а̵т̵н̵ы̵м̵и̵ ̵т̵е̵с̵т̵и̵р̵о̵в̵щ̵и̵ка̵м̵и̵ для (более экзотических) сценариев бтрфс, будете на своем замшелом ext4 сидеть до посинения!
А так вроде бы и причин больше не останется особо луддитствовать - шо там, шо там данные при жестком сбое могут помахать ручкой, так пусть хотя бы на более современной файлухе!
Ведь режим data=journal гуглу, фейсбуку и прочим платиновым спонсорам никуда не сдался, у них надежность сохранения данных либо на другом уровне обеспечивается, либо "да и крен с этими данными, еще раз своих котиков загрузят".

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

113. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от User (??), 09-Окт-26, 19:38

Если в части "отказоустойчивости" вы полагаетесь на ФС - вы уже очень сильно обо...клались, вот

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

132. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от Аноним (132), 09-Окт-26, 23:35

>  Если в части "отказоустойчивости" вы полагаетесь на ФС - вы уже очень
> сильно обо...клались, вот
О том что стратегии можно при наличии головы совмещать и оптимизировать - клиенту Accenture никто разумеется не рассказал. И правильно, не гоже себе и коллегам бизнеса портить, немамонт должен - доиться.

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

154. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от User (??), 10-Окт-26, 06:47

... И натянул четвёртый слой резинотехнической защиты на свечку - ну, для НАДЁЖНОСТИ.

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

208. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (-), 11-Окт-26, 00:12

> ... И натянул четвёртый слой резинотехнической защиты на свечку - ну, для НАДЁЖНОСТИ.
Ты не понял. Снапшоты в правильном CoW - значительно "дешевле" бэкапов и фигачить их куда ненапряжнее чем бэкапы. И времена восстановления - более другие.

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

216. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от User (??), 11-Окт-26, 07:21

Оу. А для тех, кто считает "снапшоты" "бэкапами" в пятёрочке самая лагучая касса припасена.

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

228. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (-), 11-Окт-26, 11:10

> Оу. А для тех, кто считает "снапшоты" "бэкапами" в пятёрочке самая лагучая
> касса припасена.
Этот тип начал о чем-то догадываться :). Эти технологии не заменяют друг друга а дополняют.
Если у меня при апгрейде ОС/софта или сильной смене конфигурации что-то пойдет не так, я отыграю это за 2 минуты в вид как было 5 минут назад.
А если у меня совсем железо разволилось, ФС в вермишель и проч - тогда я уже пойду доставать бэкапы, разумется.
В чем профит? Я экономлю прилично времени и сил в первом варианте развития ситуации :)

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

229. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от User (??), 11-Окт-26, 11:18

... и натянул вот еще четвёртый, ага.
Сыночка - эти вот твои аналоговнетные снапшоты перед выполнением потенциально проблемных операций обслуживания обеспечивает среда виртуализации - и да, при этом не приходится ронять в днину перформанс работы с БД, как в случае с "неимеющими аналогов в мире ФыСы".
и нет, "бэкапами" это все еще не называют.

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

252. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от alexanderyt (ok), 11-Окт-26, 17:36

Про виртуализацию тут никто и не вспомнил, кроме тебя. Так что, не пиши лишнего, за умного сойдешь.

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

254. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (-), 11-Окт-26, 17:43

> Про виртуализацию тут никто и не вспомнил, кроме тебя. Так что, не
> пиши лишнего, за умного сойдешь.
Да не мешайте вы ему. Клиентом Accenture становятся не от избытка экспертизы, так что дедуля видимо очень плохо представляет себе насколько именно он с своим пафосом промахнулся с адресатом своих лекций и "экспертизы".

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

257. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от User (??), 11-Окт-26, 18:31

> Про виртуализацию тут никто и не вспомнил, кроме тебя.
Ну и зря так-то не вспомнил. Мне вот еще один уровень снапшотов поверх того, что и так обеспечивают схд и система виртуализации нужен вот ээээ... а ни для чего примерно не нужен, да. Ну, т.е. application-aware snapshots сами-знаете-откуда какбыда - а вот это вот - неа.

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

266. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Аноним (-), 11-Окт-26, 20:48

> т.е. application-aware snapshots сами-знаете-откуда какбыда - а вот это вот - неа.
Зелен виноград, yada-yada. Правда жизни проста. Это некромант-бсдшник или древний юниксоид с проприетарным бэкграундом, который аж кюшать не может что пингвин не только попер его фетиши на мороз но и по фичам уделал. Так что такие даже в винду подаются - но и там остаются - эникей эникеем. Что не мешает пытаться корчить из себя какую-то якобы-ценную якобы-экспертизу. Которая не сработала даже для ее обладателя. Что у поховнахов что у User.

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

253. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (-), 11-Окт-26, 17:41

> ... и натянул вот еще четвёртый, ага.
Дедуля, в отличие от тебя я не убиваю время на переустановку систем при факапе, с реинсталом софта, настройкой и проч. Мне время пригодится для других дел. И я смогу позволить себе эксперименты даже и с bare metal, если оно надо.
> Сыночка - эти вот твои аналоговнетные снапшоты перед выполнением потенциально проблемных
> операций обслуживания обеспечивает среда виртуализации -
Дедушка, мне - удобно и bare metal менеджить в том же стиле. А зачем рулить по разному? Этим займешься ты, загатив голову бОльшим объемом ритуалов, а в результате будучи эникеем и в том и в другом. А потом ты идешь сдаваться Accenture, ибо все что ты смог - быть кормовой базой для кучи индусни. Это - твой уровень экспертизы в айти, как он есть.
> и да, при этом не приходится ронять в днину перформанс работы с БД,
Все твои перфомансы БД актуальны - очень сильно некоторым, в очень сильно некоторых задачах. Да и менеджить жирные бд лучше ее средствами и прочим узкоспециализированным добром. Но это интересно довольно узкой касте всяких DBA на которых мир не заканчивается.
> как в случае с "неимеющими аналогов в мире ФыСы".
> и нет, "бэкапами" это все еще не называют.
Назвать снапшот бэкапом может только клиент Accenture. Поэтому и клиент собственно, даже индусы вероятно могут разницу усвоить, если их хорошенько отдрессирует манагер.

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

258. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от User (??), 11-Окт-26, 18:43

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

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

270. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (-), 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ообщить модератору

285. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от User (??), 12-Окт-26, 07:50

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

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

304. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (-), 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 ощущают это отличие на уровне чуть ли не подсознания. И мы никогда не будем коллегами. Потому что таких как вы такие как я - презирают.
>> Можно видите ли -
> ... не путать одно с другим, но получается у поподвальных это вот
> через раз - обычно после того, как мордочкой понатыкают.
Ну вот я немного потыкал вас чтобы вы не зарывались. Вы сами по себе - не имеете ни единой заслуги где вы могли бы выйти и сказать "Я СДЕЛАЛ ЭТО!" - и показать ЭТО, конечно. В виде когда не будет возникать вопросов почему это было круто.

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

328. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от User (??), 13-Окт-26, 08:03

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

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

10. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от Аноним (10), 09-Окт-26, 10:13

>приводит к значительному снижению производительности
Если она не нужна. Опция она для этого и существует.
>не сочетается с некоторыми возможностями
Вот это уже политическая борьба внутри системы. Потребителя не спрашивают. Либо круг потребителей противоречивый.
>мешает реализации новой функциональности
Ну сейчас модно новое ради нового. План по новому - новое по плану.

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

11. "В ФС Ext4 намечен к удалению режим data=journal " +4 +/–

Сообщение от Аноним (11), 09-Окт-26, 10:15

> приводит к значительному снижению производительности... не сочетается с некоторыми возможностями... и
... обеспечивает высокую устойчивость в случае сбоев.
ПС. Сам пользуюсь этой опцией чуть ли не с самого начала. Жаль :(

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

19. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от Kilrathi (ok), 09-Окт-26, 10:30

Классика opensource: либо брать на себя поддержку режима, либо переходить на cow в zfs/btrfs (если производительность позволяет), либо компромиссить на xfs

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

97. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (-), 09-Окт-26, 17:40

> Классика opensource: либо брать на себя поддержку режима, либо переходить на cow
> в zfs/btrfs (если производительность позволяет), либо компромиссить на xfs
Если вас XFS устраивал то EXT4 тоже так то наверное с теми неполными режимами журнала - пойдет?

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

100. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Kilrathi (ok), 09-Окт-26, 18:38

> Если вас XFS устраивал то EXT4 тоже так то наверное с теми
> неполными режимами журнала - пойдет?
Если просто в лоб сравнивать ext4 и xfs в режиме "сферического коня в вакууме": для меня, субъективно, xfs "интереснее".
Если же подбирать не в режиме "ок-по-дефолту", а смотреть по платформе и задачам - уже большая вариативность, не ограничивающаяся этими двумя.
На большинстве используемых мною сейчас систем руты на ext4 и ffs, данные на btrfs и zfs.
В частности/конкретных примерах: на домашнем бюджетном бесшумном минипк под микросервисы система на ext4, виртуалки на xfs, а флешка с бакапами на exfat; на основном пк calibre с зеркалом Флибусты в f2fs, а хостинг служебных ro демо-баз, вообще, в tmpfs...

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

131. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (132), 09-Окт-26, 23:34

> На большинстве используемых мною сейчас систем руты на ext4 и ffs, данные на btrfs и zfs.
Что еще за ffs бжд?! Это какой-то ископаемый, из древних юниксов? Necromancy is a forbidden art!
И так то система на btrfs - весьма удобна. Нормальными снапшотами, а заодно и проверкой целостности что в случае глюков хардвара хотя-бы подхайлайтит с фиги ли тут глюкало ором в логи задолго до этого.

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

146. "В ФС Ext4 намечен к удалению режим data=journal " +2 +/–

Сообщение от черпало (?), 10-Окт-26, 00:56

>  btrfs - весьма удобна
ты восстанавливал сломанную фс? или оно удобно, пока проблем нет?
если да, то давай встретимся, принесу тебе мертвый ссд с этой заячьей лупой удобной, запишу подкаст про тебя, как ты там все поправил и восстановил?

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

210. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Аноним (-), 11-Окт-26, 00:39

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

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

163. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Kilrathi (ok), 10-Окт-26, 08:43

> Что еще за ffs бжд?! Это какой-то ископаемый, из древних юниксов?
Под ряд сетевых задач крутятся OpenBSD более 10 лет и кушать не просят, просто, предсказуемо, стабильно и надежно. Все обслуживание сводится лишь к накатке обновлений и замене выходящего из строя железа.

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

211. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Аноним (-), 11-Окт-26, 00:44

>> Что еще за ffs бжд?! Это какой-то ископаемый, из древних юниксов?
> Под ряд сетевых задач крутятся OpenBSD более 10 лет и кушать не
> просят, просто, предсказуемо, стабильно и надежно. Все обслуживание сводится лишь к
> накатке обновлений и замене выходящего из строя железа.
Будем считать что я предпочитаю более современные и простые в эксплуатации решения с более хорошими параметрами чем вон то. И почему-то это не мешает реализации примерно тех же паттернов и пожеланий.

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

189. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (189), 10-Окт-26, 16:12

А как COW обеспечивает лучшую сохранность данных? Наоборот, если повредится блок - он может принадлежать нескольким файлам, значит можно одним повреждением запороть несколько файлов. Значит с COW сохранность данных как раз хуже.

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

225. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от Аноним (-), 11-Окт-26, 10:53

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

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

26. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от Аноним (26), 09-Окт-26, 10:55

Простое же решение, в данном случае. Нужен максимум производительности - не включай data=journal, нужна повышенная надёжность - включай.

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

152. "В ФС Ext4 намечен к удалению режим data=journal " –4 +/–

Сообщение от ананим.orig (?), 10-Окт-26, 05:28

>нужна повышенная надёжность -
Бери raid.

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

226. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (-), 11-Окт-26, 10:54

>>нужна повышенная надёжность -
> Бери raid.
Вот уж блеснул экспертизой на весь опеннет! Raid у него журнал оказывается заменяет :D

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

122. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от Кирилл (??), 09-Окт-26, 20:44

...решается реорганизацией кода с сохранением отдельной подверсии/подрежима. В котором все конкурирующие опции отключены. Очевидно режим максимальной надёжности это не про ускорение с отложенными операциями.

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

126. "В ФС Ext4 намечен к удалению режим data=journal " +2 +/–

Сообщение от Аноним (126), 09-Окт-26, 21:24

>>жить не мешает
> приводит к значительному снижению производительности... не сочетается с некоторыми возможностями...и
> мешает реализации новой функциональности
Для реализации новой функциональности следует пилить EXT5 или ещё какую-нибудь вундервафлю!
А EXT4 как раз и выбирают, среди прочего, в том числе и потому, что она уже устоялась, настоялась и никакие грязные ручонки там ничего "прорывного и фичастого" не пилят, в том числе потому, что "Опция "data=journal" включает режим полного журналирования, при котором в журнал записываются не только метаданные, но и сами данные, что обеспечивает высокую устойчивость в случае сбоев".
EXT4 не выбирают, потому что она более быстрая и фичастая, а как раз за то, что она надёжная и консерватиная - читай её никакой оболтус не шатает и не ломает.
А если надеть шапочку из фольги, то данная инициатива вообще больше похожа на саботаж, типа: "А давайте мы зacpём EXT4, авось на наши альтернативы охотнее будут переходить, потому что на фоне новой фичастой EXT4 они будут уже получше выглядеть!"

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

147. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от черпало (?), 10-Окт-26, 01:00

> EXT4 не выбирают, потому что она более быстрая
Отчего так думаешь? она как раз самая быстрая (настоявшаяся, отполированная), даже если смотреть по количеству инструкций/цпу тайм, я (и не только) замерял и выбирал. Это тебе и простой гуглёж скажет.

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

227. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (-), 11-Окт-26, 11:04

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

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

149. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от Аноним (149), 10-Окт-26, 04:30

> приводит к значительному снижению производительности...
А оно включено по умолчанию?

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

162. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от Аноним (162), 10-Окт-26, 08:33

Нет. Если включить на ext4 полное журналирование, то она по скорости приблизится к zfs. И усиление записи вырастет в 2 раза.

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

4. "В ФС Ext4 намечен к удалению режим data=journal " +7 +/–

Сообщение от iPony128014 (?), 09-Окт-26, 09:57

У диванных анонимов так всегда...
Для них код как шкаф, который стоит в углу и никому не мешает.
Но такое не так часто.

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

34. "В ФС Ext4 намечен к удалению режим data=journal " +10 +/–

Сообщение от Аноним (34), 09-Окт-26, 11:30

у диванных проггеров так всегда...
Для них код как шкаф, в котором ничего нельзя найти т.к. полки устарели.
Но такое довольно часто.

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

123. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Кирилл (??), 09-Окт-26, 20:47

Странно, но когда то существовал такой термин как legasy-код, из которого состояло 70++% всего софта и на протяжении примерно 30 лет разработчики каким то образом умели с этим работать, получалось быстро, надёжно, дёшево и функционально. Потом ещё научились делать это безопастно.
Ну а потом пришли новые "разработчики" и решили исправить "быстро, дёшнво, надёжно" да и собственно "работать".

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

148. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от derfenix (ok), 10-Окт-26, 01:48

Интересно даже, что же изменилось за 30 лет, да....

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

175. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от Кирилл (??), 10-Окт-26, 13:16

Изменились разработчики. Точнее их изменили менеджеры. Теперь на первом месте разработка ради разработки и график написания строк кода.

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

213. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от derfenix (ok), 11-Окт-26, 01:16

> Изменились разработчики. Точнее их изменили менеджеры. Теперь на первом месте разработка
> ради разработки и график написания строк кода.
Фух, ну слава богу.. А то я уж подумал, что требования к софту теперь не те, что 30 лет назад, как и сам темп разработки, диктуемый другим темпом жизни.

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

221. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Кирилл (??), 11-Окт-26, 10:15

А о каких таких требованиях к софту вы подумали? Кто требует выпускать новой версии андроида каждый год? Наверное это пользователи устроили митинг и под угрозой бойкота требуют переписывать весь плэймаркет по сути заново каждые 1,5-2 года? И вероятно это они же потребовали чтобы обновления андроида на устройствах приходили только на 20-30% устройств и в половине случаев приносили больше проблем чем затыкали дыр в безопастности, а о новом функционале речи в принципе не идёт уже давно.

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

245. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от derfenix (ok), 11-Окт-26, 13:18

> А о каких таких требованиях к софту вы подумали? Кто требует выпускать
> новой версии андроида каждый год? Наверное это пользователи устроили митинг и
> под угрозой бойкота требуют переписывать весь плэймаркет по сути заново каждые
> 1,5-2 года? И вероятно это они же потребовали чтобы обновления андроида
> на устройствах приходили только на 20-30% устройств и в половине случаев
> приносили больше проблем чем затыкали дыр в безопастности, а о новом
> функционале речи в принципе не идёт уже давно.
Да понял я уже, что во всём виноваты злобные менеджеры, которые спят и видят только, как бы простому пользователю подгадить, а пользователи такие "Нет! не надо нам новых фичей, пусть всё будет работать как работало ещё 15 лет!". Не ходят по форумам миллионы "а вот эту фичу почему не добавили?", "а почему на вот этой моей железке без спецификаций и из говна и палок собранной работает не так?", "АА! Вы сделали фичу как Вася просил, а мне она не нужна, оставьте поддержку и старого поведения!". Ну да, чего это я...

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

299. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Кирилл (??), 12-Окт-26, 11:59

>> "Нет! не надо нам новых фичей, пусть всё будет работать как работало ещё 15 лет!"
Ты видел какие нибудь другие комментарии к какой нибудь новой и креативной версии приложения? Или может там есть эти самые новые фичи? в 99% случаев всё сводится к добавлению рекламы и переворачиванию неудобного, но хотя бы привычного интерфейса на какую нибудь хтоническую жесть. Ещё часто эти самые фичи ломают чтобы заставить пользоваться какой нибудь ненужной хренью. И ещё добавляют тормоза и анимации потому что где то появился новый, ещё более тормозной фремворк отрисовки, точно такой же как старый, только тормозной и жрущий больше памяти.
>> Не ходят по форумам миллионы "а вот эту фичу почему не добавили?"
Таки не ходят. Во первых потому что всё что нужно было уже лет 15 как добавлено, а во вторых потому что сейчас разработчикам насрать на то что пишут пользователи, им план спускают сверху.
>> "а почему на вот этой моей железке без спецификаций и из говна и палок собранной работает не так?", "АА! Вы сделали фичу как Вася просил, а мне она не нужна, оставьте поддержку и старого поведения!"
А вот это сплошь и рядом. И ещё никто ни разу не понизил системных требований, не сделал оптимизацй

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

302. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от derfenix (ok), 12-Окт-26, 12:05

Жаль, что ты не понимаешь ещё, что твой взгляд на мир - не единственный. Если тебе не нужно, если тебя 15 летний софт устраивает всем, если тебе не нужен новый функционал, то это именно тебе это не нужно, ну и ещё нескольким сотням или тысячам. Но мир не крутится вокруг тебя и ему совершенно наплевать на твоё мнение о том, какой он должен быть.

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

312. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Кирилл (??), 12-Окт-26, 23:25

Мне нужен работающий, не ломаемый, не выпиливаемый функционал. И да, я в упор не вижу никакого нового функционала в 2-3 последних ветках какого нибудь 2гис, хотя там полностью переломали интерфейс в сторону "хрен сделаешь", увеличили требования к памяти и процессору более чем раз в 20 (обрати внимание, число объектов на карте почти не увеличилось а картинка осталась прежней, просто её теперь рисуют через задницу). Реклама это не новый функционал. Поиск по всей россии того что ты ищешь в конкретном городе - не функционал а бага.

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

313. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Кирилл (??), 12-Окт-26, 23:31

Или какой нибудь vlc. Где там новый функционал? Ему просто 3 раза перерисовали интерфейс и под каждую новую версию андроида переписывают управление памятью, питанием и сном. В итоге с вероятностью в 75% текущий интерфейс является для тебя "хуже чем был", а чтобы плеер не убивался при паузе и блокировке экрана нужно лезть в репу и вручную подбирать версию под твой андроид.
Ну ладно, это мелочи. А прогресс то где?! И это мы говорим о платформе с особенностями, под которую ОЧЕНЬ адекватная команда разработчиков ынуждена плить свой продукт.

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

293. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Кирилл (??), 12-Окт-26, 11:40

> Фух, ну слава богу.. А то я уж подумал, что требования к
> софту теперь не те, что 30 лет назад, как и сам
> темп разработки, диктуемый другим темпом жизни.
Мне даже интересно, это какие такие требования выдвинули пользователи андроида на митинге, угрожая гуглу бойкотом, и требуя выпускать по 1 версии системы ежегодно из за чего весь плэймаркет приходится переписывать практически с нуля каждые 2-3 года.

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

294. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Кирилл (??), 12-Окт-26, 11:42

> Фух, ну слава богу.. А то я уж подумал, что требования к
> софту теперь не те, что 30 лет назад, как и сам
> темп разработки, диктуемый другим темпом жизни.

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

295. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Кирилл (??), 12-Окт-26, 11:43

Мне даже интересно, это какие такие требования выдвинули пользователи андроида на митинге,

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

298. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Кирилл (??), 12-Окт-26, 11:49

угрожая googлу boйkotom, и требуя выпускать по 1 версии системы ежегодно из за чего весь плэймаркет приходится переписывать практически с нуля каждые 2-3 года.

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

300. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от derfenix (ok), 12-Окт-26, 12:01

> угрожая googлу boйkotom, и требуя выпускать по 1 версии системы ежегодно из
> за чего весь плэймаркет приходится переписывать практически с нуля каждые 2-3
> года.
Трындец тебя порвало, чувак. Иди поспи, что ли...

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

311. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Кирилл (??), 12-Окт-26, 23:19

Это не меня порвало, это местный автобан считает слово "гугл" матерным.

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

284. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от iPony128014 (?), 12-Окт-26, 06:49

> Странно, но когда то существовал такой термин как legasy-код, из которого состояло
> 70++% всего софта и на протяжении примерно 30 лет разработчики каким
> то образом умели с этим работать
Ничего странного. И особо ничего не поменялось.
Зависит от проекта, требований и всего прочего.
Что единственное изменилось, что это вот подобные макисмалисты повылезали у которых всё просто, одинаково и ясно.

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

20. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от опеншлёпивпродакшн (?), 09-Окт-26, 10:33

Если противников наберётся достаточно - форкнут ext4 и будут сами поддерживать. А если не наберётся, то это ты один такой особенный.

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

42. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Аноним (42), 09-Окт-26, 11:54

> Поддержку данной опции монтирования намерены прекратить в 2028
Люди и дистры просто будут массово сидеть на LTS вышедшем перед проблемной сборкой 2028, пока окончательно не прижмёт. Т.е. аж до самого 19 января 2038, а то и дольше

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

106. "В ФС Ext4 намечен к удалению режим data=journal " +4 +/–

Сообщение от _ (??), 09-Окт-26, 19:17

Нет не будут!
Они и не такое-на-лопате жрали, жрут и будут жрать. К чему иллюзии то?

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

116. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от User (??), 09-Окт-26, 19:43

Ждите девуанный форк, ага!

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

31. "В ФС Ext4 намечен к удалению режим data=journal " +5 +/–

Сообщение от q (ok), 09-Окт-26, 11:09

> дай да выпилить что-нибудь что не сломано и жить не мешает
Если код только добавлять, но никогда не удалять, то любой проект становится unmaintainable, подумай об этом. Как говорил Хемингуэй (или кто там), "идеал -- это не когда больше нечего добавить, а когда больше нечего удалить".
Добавлять код легко. Удалять крайне сложно: тут же выскакивают возмущенные пользователи, которые этим не пользовались, но выскочить и возмутиться хочется. За ними следуют разъяренные начальники, которые настроили метрики КПД по кол-ву добавленных строк, но не удаленных. Также обижаются разрабы оригинального кода: "э, слыш, я в одна тысяча девятьсот лохматом году этот код месяц писал. Целый месяц писал! А ты его щас так просто удаляешь? Пойдем выйдем, раз-на-раз побормочем."
Добавлять код -- это бездумно идти за стадом, сохранять статус-кво, моя хата с краю, "я тут фичу сделяль, влейте". Удалять код -- это по-настоящему смелый мужской поступок, на который решится "не только лишь все". Чтобы удалить код, требуется качество, отсутствующее у многих: умение задавать вопрос "а нахрен нам эта хрень вообще упала?"

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

61. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 09-Окт-26, 13:27

> Чтобы удалить код, требуется качество, отсутствующее у многих: умение задавать вопрос "а
> нахрен нам эта хрень вообще упала?"
главное задавать его с безопасной дистанции - чтоб тебе при этом не задали встречный - а нахер ТЫ нам, отважный удаляльщик, упал?!
И да, в эпоху ыы безопасной дистанции "вообще в другом городе" может неожиданно перестать хватать.

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

95. "В ФС Ext4 намечен к удалению режим data=journal " –3 +/–

Сообщение от Аноним (95), 09-Окт-26, 17:24

> главное задавать его с безопасной дистанции
Зачем? Потому что т#пого б@дла аргументов нет и в ход пойдут кулаки?
Ну так да, лучше с такими говорить с безопасной дистанции.

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

98. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (11), 09-Окт-26, 17:52

> лучше с такими говорить с безопасной дистанции.
Зачем вы вообще хотите с такими говорить? Чтоб продемонстрировать им, что они такие а вы не такой?

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

103. "В ФС Ext4 намечен к удалению режим data=journal " +2 +/–

Сообщение от Аноним (103), 09-Окт-26, 19:00

Пишите ваш код так, словно его будет сопровождать после вас маньяк знающий где вы живете (с) дейкстра.
Дебилов-удаляльщиков "я не пользуюсь - значит никто не пользуется" только так и можно учить не лезть своими ручонками туда, куда не просят.

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

159. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от Аноним (159), 10-Окт-26, 07:18

То есть линксоиды новой волны считают всех заранее б...м с ск..м. И лучше знают что всем нужно методом запретов и удалений. Когда тоже самое делает госмашина они подпискивают и орут что они не такие снежинки, и так делать нельзя.
Удивительное разложение мозга. Хотя чему тут удивляться.

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

150. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от Аноним (149), 10-Окт-26, 04:36

Тонна бесполезной словесной софистики.
Удалять нужно не рабочее, сломанное, а не то что работает и даже полезно но ты в это не можешь поэтому это тебе не нужно, а так как ты это подавляющее меньшинство то ты решаешь за всех и делаешь.
Остановите этот мир на минуту, я сойду.

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

74. "В ФС Ext4 намечен к удалению режим data=journal " +2 +/–

Сообщение от Аноним (74), 09-Окт-26, 14:52

Тебе прямым текстом сказали что сломано и жить мешает.

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

104. "В ФС Ext4 намечен к удалению режим data=journal " –3 +/–

Сообщение от Аноним (103), 09-Окт-26, 19:00

Навешали лапши на уши а ты и рад слушать?

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

121. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (74), 09-Окт-26, 20:11

Мне обоснование для удаления кода вообще не нужно.

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

3. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (3), 09-Окт-26, 09:56

>по сравнению с режимами "data=ordered" и "data=writeback"
Ну, writeback, вообще, опасная штука. Такое себе решение дропать журналирование... Сами себе палки в колеса. Я хз, какая там доля ext4 на серверах, но теперь вообще будет 0.

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

5. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от Другой аноним (?), 09-Окт-26, 10:07

Если прочитать получше - журналирование никто дропать не собирался. Дропают только режим полного журналирования вместе с данными, а не только метаданными - так никто не делает, ни на NTFS, ни на ext4.

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

6. "В ФС Ext4 намечен к удалению режим data=journal " –5 +/–

Сообщение от Аноним (3), 09-Окт-26, 10:10

Да, не подумал, что дети на тех.форуме под новостью о полном журналировании в коменте смогут увидеть что-то другое кроме полного журналирования. Именно это и имелось в виду: полное журналирование. Внезапно. Прости, что дропнул это слово. Ведь речь именно об этом в новости. Рукалицо бл.
У меня в проде это критично ибо есть некоторые технические нюансы и требования.

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

23. "В ФС Ext4 намечен к удалению режим data=journal " –2 +/–

Сообщение от Другой аноним (?), 09-Окт-26, 10:43

Не нравится - используй btrfs, которая для этого и создавалась, полная транзакционность за счёт copy-on-write. Данные гарантированно или записаны целиком, или не записаны совсем.

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

30. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Аноним (3), 09-Окт-26, 11:09

>btrfs
На домашней машинке как раз это со снапшотами. Хорошая вещь. Но проды ведь бывают разные. И такие, где ты не можешь просто так взять и перевести всю инфру. Да и не имеешь привелегий принимать подобные решения, к сожалению.

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

133. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (132), 09-Окт-26, 23:39

> На домашней машинке как раз это со снапшотами. Хорошая вещь. Но проды ведь
> бывают разные. И такие, где ты не можешь просто так взять и перевести всю инфру.
> Да и не имеешь привелегий принимать подобные решения, к сожалению.
А если б даже и имел - случаи бывают разные. Скажем нагруженный БД на cow класть ну такое себе. Можно nocow на ее файлах врубить но тогда большая часть фишек отвалится. И если это был основной сценарий появится вопрос - а за что мы собссно боролись? Перфоманс - просадили, ибо оверхеда все же больше. А взамен с nocow в комплекте ... что?
В общем серебряных пуль все же не бывает. Если кто утверждает обратное, обойдите его стороной - пули у него из другого материала.

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

181. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от bx (?), 10-Окт-26, 15:13

У меня диск отвалился, сильно много писал, китайчатина, если бы не btrfs, хрен бы чего поднял. 13 лет примерно самому старому снапшоту. Но пару раз сдыхал, да. Лечилось, без потерь пока.

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

230. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (-), 11-Окт-26, 11:21

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

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

196. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от Аноним (196), 10-Окт-26, 17:37

Это наоборот к счастью, что умные дяди не разрешают тебе на бэтер переходить. А то еще чужие данные просохатишь

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

35. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (35), 09-Окт-26, 11:40

И как часто в ваш прод попадает свежайшее ядро я кернел орг? Не знаю такого дистра для прода в котором будет 7.3 и выше раньше чем через 2-3 года.

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

49. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от похнапоха (?), 09-Окт-26, 12:27

В продакшене для отказоустойчивости используют надежные СХД с поддержкой (внезапно?) соответствующих потребностям уровней RAID, а так же в дополнение к этому используют метро-кластеры, если данные действительно важные. ext4 в продакшене с опцией data=journal для хранение данных - это баловство, можешь просто использовать пяти дюймовые дискеты для таких данных.

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

85. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох. (?), 09-Окт-26, 16:24

> В продакшене для отказоустойчивости используют надежные СХД
лучше - сразу облачка, на которых восседает святой дух!
(внезапно, чтобы твои данные добрались до супернадежной [тоже нет] схд - они проходят даже не через одну, а иногда аж через 3 fs - включая и обычную ext4. И да, на КАЖДОМ из этих этапов неуклюжее обращение с данными может что-то испортить.)
главное ж веровать.

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

93. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от похнапоха (?), 09-Окт-26, 17:03

Кроме вафли на ONTAP, чего они не скрывают и о чем гордятся, в остальных случаях корпоративные СХД - это простое блочное устройство, с собственной реализацией структур метаданных (конечно ведь снимки как-то должны работать) и тд, но называть это ФС - глупо. А ext4 на СХД - это для iSCSI, что в корпоративном секторе редкость, либо какой-нибудь NAS, что достаточно популярно.

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

182. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от bx (?), 10-Окт-26, 15:15

А что же там? Ну так, ради интереса.

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

118. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от User (??), 09-Окт-26, 19:51

Ну, внезапно если тебе нужно надёжное хранение данных, то избыточность, ec и вот это всё ты закладываешь вот - на уровне данных, нет?

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

134. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох. (?), 09-Окт-26, 23:40

нет, потому что тогда тебе придется эти данные писать на raw носитель. И то - исключительно в надежде что ну хоть вот фирмварь для самого ссд все же написана нормально.
А то ты избыточность, ec, вот ето все - а там подтверждение записи до самой записи.
И твои избыточные данные - прикрытая несходящимся ec тыковка.
В схд замногоденях тоже нет никакого прямого канала между памятью твоего докера в докере и носителем. А есть та самая ext4 где-то под слоем оверлейфсов, возможно поверх виртуального диска какой-нибудь вмвари, поверх фс уже самой вмвари, которая создана вон там на схд (у которой хотя и не "настоящая" но тоже фс а не прямой доступ к накопителю). Отдельные уровни этой этажерки можно пропускать, но надо хорошо понимать зачем и чем это грозит, а в целом - не рекомендовано.
И _каждый_ из этих уровней должен гарантировать тебе что записанное с fsync - доехало до носителя и будет оттуда прочитано.
(и в идеале бы - что записанное без fsync все равно доедет до носителя хотя бы в большинстве случаев. Потому что fsync стоит дорого. Поэтому вот существуют barriers, тоже по всей этой иерархии.)

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

91. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Аноним (91), 09-Окт-26, 16:58

> У меня в проде это критично ибо есть некоторые технические нюансы и требования.
Ну раз критично аж в проде, то пиши скорее в lkml, предлагай проспонсировать сохранение опции. Это опенсорс, детка, тут никто никому ничего не должен, тут либо сам пишешь что надо, либо ешь что дают.

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

190. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох. (?), 10-Окт-26, 16:19

> Это опенсорс, детка
тут ты жрешь с лопаты то что одобрили платиновые спонсоры, и ничего кроме!
(и нет, твои копейки тут ничего не изменят, их с радостью возьмут и подотрутся твоими хотелками)

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

231. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Аноним (-), 11-Окт-26, 11:26

> тут ты жрешь с лопаты то что одобрили платиновые спонсоры, и ничего кроме!
У него выбор - шире чем у тебя, внезапно... ты то вообще выбираешь из 1 спонсора в лице муласофта который и сам не знает уже чего хочет. Кажется они доигрались до точки когда даже сами для себя не прочь на линух свалить, как минимум на своих же серверах.
Потому что маркетинговый BS это прекрасно, но когда он начинает дурить своих же топов и стоить денег прям самому майкрософту - акционеры чем-то недовольны. И вот уже всякие баллмеры и гейтсы отправлены в почетную отставку. Конечно с золотым парашютом, если не всем самолетом, иначе остальные топы не поймут. Но - теперь дедушки все же будут -  развлекаться на своих островах или что там у них. И не будут влиять на решения компании.
> и подотрутся твоими хотелками)
Как ты с своим юниксвеем, приведшим тебя на виндузи? Так что ты эникей и в том и в другом оказался? Вот это я понимаю - фэйсом об тэйбл в своей IT карьере, поставив не на тех лошадей.

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

14. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от Kilrathi (ok), 09-Окт-26, 10:17

Вообще-то полное журналирование есть в ufs через geom под "фрёй"

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

36. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от пох.. (?), 09-Окт-26, 11:40

c silent data corruption works as intended, не забывай уточнять.
потому что журналирование в обход фс и невидимое для нее - всегда вот этим и заканчивается.

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

75. "В ФС Ext4 намечен к удалению режим data=journal " –2 +/–

Сообщение от Аноним (74), 09-Окт-26, 14:56

В UFS кривейший механизм soft updates, который так и не сделали нормально, а журналирование в geom отдельное от ФС разваливается при первом попадении питания, да так что fsck падает на unexpected soft update inconsistency и файловой системы считай что больше нет.
Но какой идиот будет под FreeBSD использовать не ZFS.

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

94. "В ФС Ext4 намечен к удалению режим data=journal " +/–

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

101. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от Аноним (70), 09-Окт-26, 18:52

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

135. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Аноним (132), 09-Окт-26, 23:41

> Вообще-то полное журналирование есть в ufs через geom под "фрёй"
Вот только кому весь этот адский кластерфак сдастся и зачем?...

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

18. "В ФС Ext4 намечен к удалению режим data=journal " +2 +/–

Сообщение от sabitov (ok), 09-Окт-26, 10:29

А Вам не доводилось сталкиваться с потерей данных на ФС из-за падения питания? А у меня такое былО, когда в либцэшных .so файлах оказался мусор, а система не бутилась. Я с тех пор XFS не использую :) ХЗ, что там за прошедшие 25 лет поменялось :)  И мне пофиг, будет у меня сервер писать 300Мб/с или 250, главное, чтобы при любых раскладах данные не корёжились

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

24. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от онанист (?), 09-Окт-26, 10:53

приходилось
на райзере
лет так 27 назад :-)

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

28. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от Аноним (3), 09-Окт-26, 11:05

>сталкиваться с потерей данных
Я думаю, все с этим сталкивались, кто более-менее с компами работает и имеет опыт.

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

29. "В ФС Ext4 намечен к удалению режим data=journal " –2 +/–

Сообщение от Другой аноним (?), 09-Окт-26, 11:07

> либцэшных .so файлах оказался мусор
Больше похоже на коррапшен данных по вине диска, не запарковавшего голову, чем на последствие (не)журналирования. Если, конечно, падение питания не произошло в аккурат во время обновления пакета libc, но тут даже журналирование не даст никаких гарантий, потому что если файл наполовину записался - то журнал откатит только половину блоков и получится всё равно битый файл.
В итоге, печально, но судя по всему, большинство присутствующих даже не понимают, как именно работает механизм журналирования ФС.

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

38. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от пох.. (?), 09-Окт-26, 11:46

> В итоге, печально, но судя по всему, большинство присутствующих даже не понимают, как
> именно работает механизм журналирования ФС.
ты вот, к примеру - кажется, не совсем понимаешь. Что на то и журнал что половина блоков не может записаться. Транзакция либо закрыта, либо нет (и будут заново записаны и те блоки что уже один раз записались и все остальные, либо ничего).
(Ну, в предположении что автор писалки тоже не совсем дол... и дергает fsync/dsync прежде чем рапортовать об успешном успехе - журналу тоже откуда-то нужно узнать, *что* именно тут - транзакция. Держать целиком все данные до закрытия файла он не сможет, потому что файл может закрыться и через пару лет.)

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

51. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Другой аноним (?), 09-Окт-26, 12:43

Ситуация, описываемая автором настолько странная, что там либо кривая писалка была, которая после каждого блока fsync'ала, либо (что вероятнее) это было повреждение данных на уровне HDD, от которого журнал никак бы не спас, ибо оно не для этого.

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

52. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 09-Окт-26, 12:54

не, ну можно ж вообще не фсинкать? а я хрен знает как всякие dpkg принято было писать в том самом ламповом 93м.
Файл открываем сразу тот который обновляем, никаких этих вам mkstemp/rename, читаем откуда-то пишем куда-то вперемешку, чтоб шибкоумная фс не могла предугадать наших действий, надо быть непредсказуемым для противника, где-нибудь по дороге еще тупим (например потому что чтение подзависло на фоне записи), прилетает внезапное отключение электричества - проооофит!
с повреждениями на hdd у нас все плохо с тех пор как секторные метки начали записывать вместе с данными - будет сбойный сектор, а это слишком заметно.

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

40. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (40), 09-Окт-26, 11:53

В Unix/Linux любые обновления файлов делаются путём создания в том же каталоге (или в той же ФС) нового файла, а далее - атомарной операции rename.
Никто не открывает на запись действующую .so-шку (да это и невозможно просто так, файл залочен операционкой).
Вот удалить его можно, и переименование с удалением тоже возможно.

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

50. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Другой аноним (?), 09-Окт-26, 12:38

По хорошему - да, через rename. И поэтому ситуация, как у автора вызывает больше вопросов, чем ответов. rename - это операция с метой, которая идёт через журнал, даже если data=journal нет. При этом оно /должно/ было случиться уже когда данные в новый .so уже записаны. И уж точно, даже без журнала на ext4 не мог побиться файл, в который не писали. Поэтому либо автор рукоспинствовал, и сделал rename перед записью, после чего писал .so в чистый файл, либо (намного вероятнее) это data corrupt на уровне диска, от которого всё равно никакой журнал не спасёт.

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

53. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 09-Окт-26, 12:57

> В Unix/Linux любые обновления файлов делаются путём создания в том же каталоге
хачю - делаю, не хачю - не делаю! И чо ты мне сделаешь, я вообще в другом городе!
Вот за такими нехачухами тут надысь километр кода пришлось перебирать, потому что система которая должна была гарантировать надежность данных - внезапно, как оказалось, вообще ничего не гарантирует да еще и в упор не видит потери. Вот то самое хрестоматийное - "а зачем нам коды возврата printf?" вишенкой на тортике.
(хенд мейт между прочим, трю органик, не нейрослоп какой! Вполне вероятно у кого-то до сих пор в проде.)

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

102. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (91), 09-Окт-26, 19:00

> за такими нехачухами тут надысь километр кода пришлось перебирать
Ну не тебе ж пришлось, а агенту. А ему вообще без разницы, он железный. Ты там небось сидел и лениво пальчиком тыкал в ответы: это хочу, это не хочу, и вообще работай на другом хосте, не шуми мне тут вентилляторами.
> "а зачем нам коды возврата printf?" вишенкой на тортике.
Всегда ли должна функция что-то возвращать, и всегда ли нужно это проверять -- классика, академики ещё в 70х не одну пивную кружку об голову собеседника расхерачили в пылу спора на эти темы. И только потом переключились на algol или lisp, emacs или vim, unix или cp/m.

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

107. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от пох.. (?), 09-Окт-26, 19:21

> Ну не тебе ж пришлось, а агенту.
да он, сссскотина, вопросы какие-то задает... а я ж не настоящий сварщик, я б вообще рад это развидеть нахрен!
но printf он красиво объехал, я не уверен что сам бы сообразил а не стал бы просто все переделывать заново.
(про printf нифига не фигура речи - там реально был printf)

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

128. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от maximnik0 (?), 09-Окт-26, 22:22

>Никто не открывает на запись действующую .so-шку (да это и невозможно просто так, файл залочен операционкой).
Эта возможность опция, можно блокировку отключить.А юзер файлы записать без блокировки - вообще штатная возможность (root превелегии) .Да и samba тоже может писать без losk файла если это нужно.Механизм простой : записываться новый файл - старый файл помечается как удаленный- но пока дескрипторы заняты, не удаляется.Поэтому через отладку возможно файл восстановить - где то даже howto было на примере видиофайла который проигрывает mplayer  ,а каталог удалили.

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

44. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (35), 09-Окт-26, 11:58

xfs действительно страдал всяческими пропажами при упавшем питании (ядра тогда крэшились тоже частенько, но не про это речь). в нулевых xfs можно было использовать только строго с ибп, это было само собой разумеющимся.

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

71. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (71), 09-Окт-26, 14:32

У меня была такая же проблема на ноуте, только там был NVMe от Samsung, Evo 970 вроде бы. Так же поставил ноут обновляться, всё скачалось, началось распаковываться, но происходило это очень медленно. Никаких ошибок в dmesg не было. После ребута нихрена не запустилось, потому что все файлы, в бут разделе в том числе (FAT32), оказались размером 0. Я грешу на фейл проца либо чего-то на материнке, что создаёт коррапт памяти (такое в ноутах делл было со сломанной клавиатурой, а на моём финке как раз у клавы кнопки коротить начали на мембранке), потому что потом с ноутом были такие же проблемы из разряда "чё этот прид*рок делает" и замена диска и плашек оперативки не помогла.

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

46. "В ФС Ext4 намечен к удалению режим data=journal " –2 +/–

Сообщение от Аноним (46), 09-Окт-26, 12:10

Xfs вообще интересная в плане багов, занулять рандомные файлы тоже любит и никак это не исправят до конца. Ext4 может повредить открытый на запись файл при data=writeback, но это надо, чтобы звёзды сошлись. После того, как она сотни внезапных отключений энергии подряд переживала без заметных последствий (худшее кэши браузера повреждаются и пару раз экстеншены браузера пришлось обнулить), у меня нет сомнений в её надёжности. Главное, fast_commit не включать, или придётся ждать часами пока убитый журнал регенерирует.

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

77. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от Аноним (74), 09-Окт-26, 14:58

> тоже любит и никак это не исправят до конца
Что значит "исправят"? У них в FAQ написано что это бай дизайн

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

108. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от пох.. (?), 09-Окт-26, 19:26

>> тоже любит и никак это не исправят до конца
> Что значит "исправят"? У них в FAQ написано что это бай дизайн
да это просто местный гений-самоучка без мотора очередной фуфел нашел и без конца про него вспоминает. Наверное бэкап не делал и ценный ридмитхт потерял.
На ext4 в этом файле просто окажется мусор или не окажется самого файла если до барьера попал. Первое гораздо хуже чем очевидно обнуленный файл.
И лечится это правильным написанием кода - вот с теми самыми fsync ДО делания действий которые этот файл считают достоверным, а не чудесами фс.

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

119. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от User (??), 09-Окт-26, 19:56

Ну а беда-то в чём? Ну выпала нода из кластера, и?
Или то ЕДИНСТВЕННЫЙ сервер был, второй под кровать не влез?

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

66. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Метрика (?), 09-Окт-26, 13:49

Это называется резервным копированием так то, а журналирование это сохранение всех inode файла, чтобы можно было найти его данные на диске, если их не затерли конечно

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

127. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (127), 09-Окт-26, 21:41

> Ну, writeback, вообще, опасная штука.
Ничего там опасного нет вообще! Но только, если в программе правильно расставлены write и fsync.
Во времена внедрения режима writeback оказалось, что мало кто вообще знает как надо использовать fsync правильно. И вот тут повылезали ошибки с "обнулением файлов", появилась инфа про небезопасность режима writeback и костыль от Теодора для быстрого детекта опасный ситуаций и отключения delayed allocation (которое не будет так часто приводить к появлению битых файлов).
Проблема действительно была проблемой, т.к. вылезло в kde3 (уже после последнего релиза kde3), откуда она пришла из Qt3 (а в то время уже вовсю был Qt4 и Qt3 патчить никто не собирался). В torrent-клиентах разных тоже вылезало и ещё много где (в основном редакторы, кажется даже в StarOffice 1.x было).

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

7. "В ФС Ext4 намечен к удалению режим data=journal " +3 +/–

Сообщение от Аноним (7), 09-Окт-26, 10:12

>Кроме того данная опция не сочетается с некоторыми возможностями, такими как отложенное выделение блоков (delalloc) и прямой ввод/вывод
А может лучше оставить пользователю выбор? Или новый функционал, или полная устойчивость системы?
>мешает реализации новой функциональности в Ext4
Зачем нужно менять именно Ext4? Пускай новый функционал реализуют на уровне VFS.

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

32. "В ФС Ext4 намечен к удалению режим data=journal " –3 +/–

Сообщение от Скрудж (?), 09-Окт-26, 11:12

> Или новый функционал, или полная устойчивость системы?
Ну так не обновляй ядро, и тебе не будет нового функционала и сохранишь полную устойчивость систему

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

45. "В ФС Ext4 намечен к удалению режим data=journal " +2 +/–

Сообщение от Аноним (7), 09-Окт-26, 12:08

Все новости про уязвимости ядра мимо тебя прошли, да?

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

151. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (149), 10-Окт-26, 04:41

Свобода выбора, в свободном софте?!

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

9. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (9), 09-Окт-26, 10:12

Подождите... "в журнал записываются не только метаданные, но и сами данные" разве не приведет к дублированию всех данных на диске и занимаемого места?

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

12. "В ФС Ext4 намечен к удалению режим data=journal " +4 +/–

Сообщение от Кирилл (??), 09-Окт-26, 10:16

Может дублироваться, но только до момента подтверждения записи всей транзакции на диск (т.е. данных), после этого блоки журнала переиспользуются

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

13. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от Вацлав (?), 09-Окт-26, 10:17

приводит

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

15. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (11), 09-Окт-26, 10:21

Ложь. Размер журнала фиксирован, он не увеличивается и не уменьшается. Увеличивается только количество записей на диск.

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

54. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 09-Окт-26, 12:58

> Ложь. Размер журнала фиксирован
да вроде нет? Ты с journal inode не перепутал?

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

289. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от bx (?), 12-Окт-26, 10:11

Это ты что-то перепутал. journal=data это пипец.

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

16. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (16), 09-Окт-26, 10:29

Приводит. Но обычно для этого используют отдельный SSD накопитель.

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

290. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от bx (?), 12-Окт-26, 10:12

Который за 100 рублей купили?

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

78. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (74), 09-Окт-26, 14:59

Записать нужно два раза, да, но копию в журнале после подтверждения записи можно больше не хранить.

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

17. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от Аноним (17), 09-Окт-26, 10:29

>но усложняет сопровождение кода
Но ведь сейчас ИИ из всех утюгов с историями успеха по сопровождению кода, как это может быть аргументов в 2026 году ?

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

25. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Аноним (25), 09-Окт-26, 10:55

Сопровождает. Успешно. Не бесплатно. Крупные корпы сидят на xfs и btrfs (судя по rhel и suse). Ну, возможно, кто-то ещё на zfs.
А ext4 - удел подкроватных сисадминов с mdadm raid, которые даже не в курсе что такое тихие ошибки и data-integrity.

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

41. "В ФС Ext4 намечен к удалению режим data=journal " +3 +/–

Сообщение от Аноним (35), 09-Окт-26, 11:54

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

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

184. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от bx (?), 10-Окт-26, 15:20

ИБП )) Аккумуляторные. И ДГУ. И нахер с пляжа всех энергетиков, если дгу не завелся в установленное время. РКН не двет булки расслаблять.

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

232. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Аноним (-), 11-Окт-26, 11:29

> ИБП )) Аккумуляторные. И ДГУ. И нахер с пляжа всех энергетиков, если
> дгу не завелся в установленное время. РКН не двет булки расслаблять.
Ага, сейчас тебе пох. еще расскажет как правильно нарулить упсу. Чтоб заметить что АКБ сдох - когда свет пропал. Вместе с ФС по закону подлости :).

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

291. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от bx (?), 12-Окт-26, 10:14

ДГУ - это не совсем батарейки )

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

333. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (333), 14-Окт-26, 07:25

да, собственно не в курсе. как и о опициях metadata checksum и t10 dif/dix...

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

27. "В ФС Ext4 намечен к удалению режим data=journal " +5 +/–

Сообщение от RM (ok), 09-Окт-26, 10:58

читая новость, приходит только одна мысль, про "неосилили".

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

110. "В ФС Ext4 намечен к удалению режим data=journal " +4 +/–

Сообщение от _ (??), 09-Окт-26, 19:32

А у меня почему то про "сахар в бензобак"(С) :(
яЪ - ну чё им бтрфс для опытов не хватало? :(

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

174. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 10-Окт-26, 12:16

> яЪ - ну чё им бтрфс для опытов не хватало?
это кого надо нога. И они дедулю в свой огород подкармливаться пускать не собирались.
А дедуле тоже ж хочется подачек от спонсоров и не вылететь в early retirement с невыплаченным моргиджем. Приходится изображать бурную деятельность там, где ему позволяют.
Одна только надежда - что ыы поставит жырную точку на всей этой камарилье года через два.

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

186. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от bx (?), 10-Окт-26, 15:35

Через 2 - морда не треснет? Лет 5, если "друзья" не подключатся. Ну или мы объясним, что не стоит.

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

33. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от Аноним (34), 09-Окт-26, 11:14

> но усложняет сопровождение кода
Печально что ядродевелоперы даже с помощью ИИ не могут осилить сопровождение собственного кода.

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

39. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от пох.. (?), 09-Окт-26, 11:47

там как надо девелопер, старик а все сам делал.
Ну вот поэтому такие и пироги.

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

136. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (132), 09-Окт-26, 23:44

> там как надо девелопер, старик а все сам делал.
> Ну вот поэтому такие и пироги.
Если это про Теодора - он уже давно всем объяснил что гальванизировать ЭТО - смысла вообще осталось довольно мало. А уж сильно развивать или там EXT5 какое - забудьте про это.
Если кому next gen хочется, это не ext5 а скорее структуры как в bcachefs и проч. И Тсо об этом уже тоже догадывается. Как и разработчики btrfs с своими новыми деревьями и проч.

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

144. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 10-Окт-26, 00:37

> Если это про Теодора - он уже давно всем объяснил что гальванизировать ЭТО - смысла
> вообще осталось довольно мало.
ну так - складывай дедуля полномочия - и выметайся. Устал - уходи.
Но нет. Денежки платиновых спонсоров будет тянуть до могилы.
А разработчики btrfs рабы другого хозяина, и делают то что велит тот хозяин (и ничего не собираются чинить за что тот не платит). А ему твои данные нафиг не упали, новых еще быстрее накачаешь, заодно будет куда новую рекламу насовать.
> Если кому next gen хочется,
то пусть сам его прдлит как умеет. Получится что-то съедобное - приходит, нет - следом за бкэшем строем на йух.
А пока неплохо было бы не ломать то что _работает_ (пусть и не у миллионов, тут аноним лоханулся, у миллионов работает совершенно дурацкий data=ordered, гарантирующий ровно ничего и при этом тормоз. А, прастити - быстрый fsck он гарантирует, да. С неконсистентыми данными. Но быстро!)

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

234. "В ФС Ext4 намечен к удалению режим data=journal " +/–

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

242. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 11-Окт-26, 13:04

> Ну так ты ж на замену не пришел...
а что, кто-то звал? Там дедуля (на зарплате ibm, насколько я его мутные речи понял) был недоволен что ему неполиткорректно распугивают бесплатных тестировщиков и настройщиков интеграций. (Комитеры таки на зарплате тоже)
> если дедули уйдут
думаешь, зарплату поделят менеджеры звена повыше, и никому новому не передадут?
В принципе, могут, конечно.
> А со своими данными я разберусь без "благодетелей" типа тебя. Тем более что разработчики
> btrfs у меня "at my fingertips" и если что - я скажу правильные волшебные слова
"дам миллион"?
Да откуда у тебя, фантазер. Да и тоже в общем ни о чем, у них одних долгов за недвигу на пять у каждого, им шта6ильные оклады подавай.
Волшебный пендель им даст работодатель, и они с радостью и энтузиазмом разрушат то на чем ты построил свои системы. Потому что могут, а ты им никто и звать тебя никак.
А ты все продолжаешь раздувать щечки и рассказывать как ты жрешь с лопаты и тебя все устраивает.

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

255. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Аноним (-), 11-Окт-26, 18:00

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

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

105. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (103), 09-Окт-26, 19:02

Не "не могут", а "не хотят" очевидно. Почему - отдельный вопрос.

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

43. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (-), 09-Окт-26, 11:55

>Опция "data=journal" включает режим полного журналирования, при котором в журнал записываются не только метаданные, но и сами данные, что обеспечивает высокую устойчивость в случае сбоев, но усложняет сопровождение кода
Пыцаны btrfs же есть. Зачем из ext4 делать btrfs, или я что-о путаю?

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

48. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от Аноним (48), 09-Окт-26, 12:14

Должен остаться только ntfs3g и fuse.

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

65. "В ФС Ext4 намечен к удалению режим data=journal " –3 +/–

Сообщение от Метрика (?), 09-Окт-26, 13:44

Есть две работающие ФС это NTFS и ZFS, все остальное это попытка студентов в ФС, не более чем

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

109. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от пох.. (?), 09-Окт-26, 19:28

> Есть две работающие ФС это NTFS и ZFS, все остальное это попытка
> студентов в ФС, не более чем
одна, к сожалению. ТОЙ zfs уже двадцать лет как тоже нет.

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

111. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от _ (??), 09-Окт-26, 19:34

Ну ежели так, то и XFS _той_ нет столько же :(

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

115. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 09-Окт-26, 19:43

та была образцовым копропродуктом поздних 80х, в ней как раз ничего хорошего и не было, ну может кроме идей чуть лучше чем идей extfs из 70х.
насколько хороша та что есть сейчас, существенно переписанная рабами ibm в 2010-2014м - не уверен, поскольку в уже переписанной видел те же глюки что видел в 2009м.

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

141. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (132), 09-Окт-26, 23:54

А чего такого хорошего в блочнике-переростке с типа-переменными блоками для галочки? Сделанным ТАК по причине "мы так привыкли и этот паттерн нас не подводил"? Перфоманс таких структур и оверхед всего этого на современных SSD с зиллионами iops и gbps вызывает у энтерпрайзников только печальку. И никак это особо не починится уже.
Этот мир просто изменился. Сети и IO приблизились к процам по скорости.

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

191. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (162), 10-Окт-26, 16:32

Если не секрет, чем ТА zfs лучше ЭТОЙ?

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

193. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от пох.. (?), 10-Окт-26, 17:03

там статья на пять страниц. неформат дляэтогосайта.
Если готов сам разбираться - посмотри для начала вокруг abd.c
вот ничего подобного в "той" - не было. И это вершина айсберга, под водой скрыты чудовищных размеров п-цы.

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

194. "В ФС Ext4 намечен к удалению режим data=journal " –2 +/–

Сообщение от Аноним (162), 10-Окт-26, 17:21

Т.е. претензий по существу нет. Так и запишем...

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

195. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 10-Окт-26, 17:30

> Т.е. претензий по существу нет. Так и запишем...
ты м-к, так и запишем. нахрен вот ты спрашивал если тебя вообще не интересовал ответ?
Я тебе буквально ткнул пальцем в код, в самую его простую и обезьянами понимаемую часть. Но ты - т-пой м-к, и ты не умеешь читать и понимать код.

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

197. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (162), 10-Окт-26, 17:38

Свой палец ты сам знаешь куда можешь засунуть. Своими словами ответь. Или настолько бухой что не можешь буквы на клавиатуре найти?

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

198. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от пох.. (?), 10-Окт-26, 17:45

> Свой палец ты сам знаешь куда можешь засунуть. Своими словами ответь.
на х-й пошел!
я не собираюсь общаться со свиньями.
Я отвечаю людям в предположении что они - люди. Поэтому мой первый и последний ответ тебе был по делу. Если бы тебя действительно интересовало, что не так с современной zfs. И если бы ты даже не справился, но задал уточняющие вопросы - я бы подсказал.
Но ты - т-пой м-к и тебе вовсе не это было интересно. И идешь на-й, ничего я м-кам объяснять не буду.

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

202. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Аноним (162), 10-Окт-26, 18:18

Когда аргументов нет приходится переходить на оскорбления. Понимаю. Что ж, истерикой очередного пустозвона удовлетворён ))

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

204. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 10-Окт-26, 18:36

> Когда аргументов нет
Когда собеседник полный м-к и аргументы ему непонятны, и не за аргументами он приходил.
Ему показывают где проблема - он хамит в ответ.
Поэтому - пшел на-й!

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

244. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Neandertalets (ok), 11-Окт-26, 13:17

Если не становиться в позу оскорблённой невинности, то простой запрос к ДипСику даёт такой ответ:
---
Сам по себе файл 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) и т.д.

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

279. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от пох.. (?), 11-Окт-26, 23:23

> Если не становиться в позу оскорблённой невинности, то простой запрос к ДипСику
> даёт такой ответ:
лоханулся твой дикпик. Налил ведро воды, а до вишенки так и не докопался.
Если бы ты открыл файл (и умел конечно понимать несложный код) - ты бы увидел главную проблему _сразу_. (одну, там еще рядом вторая есть, чуть менее очевидная) User вот - увидел (полагаю, не вчера, конечно).
> Это вызывало фрагментацию и проблемы с производительностью, особенно на 32-битных
> системах
это вот особенно смешно, да.
sonnet, кстати, мгновенно вытащила суть. Скорее всего из pre-learned knowledge, а не анализом кода. И еще пару проблем в соседних местах, о которых я не знал.

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

214. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (70), 11-Окт-26, 01:43

> abd.c
> вот ничего подобного в "той" - не было. И это вершина айсберга,
Не, на чо - зато с ним, родимым, ZFS на малинке (причем, еще той самой) заработает! Не уверен, проверял ли кто-то, включая авторов этого драндулета.

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

217. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от пох.. (?), 11-Окт-26, 09:24

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

256. "В ФС Ext4 намечен к удалению режим data=journal " –2 +/–

Сообщение от Аноним (-), 11-Окт-26, 18:04

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

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

235. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (-), 11-Окт-26, 11:48

> Если не секрет, чем ТА zfs лучше ЭТОЙ?
Раньше солнце было зеленей, трава светила ярче, и ZFS - вот лучше был. Ща, похонах протрезвеет и продолжит мыслю. Я попытался в его стиль на первых двух, но для ZFS пусть он сам опишет.

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

246. "В ФС Ext4 намечен к удалению режим data=journal " –2 +/–

Сообщение от Аноним (70), 11-Окт-26, 13:25

> Раньше солнце было зеленей, трава светила ярче, и 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ообщить модератору

248. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от пох.. (?), 11-Окт-26, 13:34

А ты неленивый, однако. (но зачем, тут некому это читать и понимать, а я и так знаю)
> "И вот так у них - все"(с).
вот это ключевое, к сожалению. abd я бы просто выпилил, это с ыышной помощью - несложно.
Просто это хрестоматийный пример, не требующий глубоко лазить в сложные материи, все прямо там в файлике видно. Но не местному контингенту.
"Все" остальное починить - ну... когда-нибудь... на пенсии... непременно возьмусь. (... или сам Ходжа...)
P.S. prefetch БЕЗ abd - меряли, не опрашивали. Не надо его выключать. Даже на виртуалках с гигом - не надо. Это, кстати, кажется от тех, титанов еще, не новодел. В общем, титаны тоже были так себе, но их костыль - работает.

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

268. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (162), 11-Окт-26, 22:05

> abd я бы просто выпилил
Сделать zfs_abd_scatter_enabled=0 религия не позволяет?

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

324. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 13-Окт-26, 02:44

это отключит scatter. но не сам ненужный механизм abd.

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

326. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (162), 13-Окт-26, 05:01

Разве abd появился не вместе с zfs?

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

331. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 13-Окт-26, 13:01

нет.
л@п4@тое гуано имени дельфикса. Как и большинство других современных проблем zfs.
При этом им удалось протолкнуть его в апстрим, хрен уж его знает чем там думали. (но там ничем особо не думали, там в примерно том же интервале вообще сломали ARC, и сломавший просто перестал отвечать на письма. Пол-года всем было похрену.)
Если браться make great again - надо выбросить _все_ что понаделано дельфиксами не разбираясь. А потом очень тщательно изучать оставшееся - потому что там тоже все очень и очень плохо.
И только когда и если удастся это все зачистить и протестировать - можно вернуться к рассмотрению идей (но ни в коем случае не кода!) этих линуксолюбов.
В общем, ... или сам Ходжа тут наиболее вероятный сценарий.
p.s. да, тестов нормальных тоже нет. то что есть - выкрасить и выбросить.

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

305. "В ФС Ext4 намечен к удалению режим data=journal " –2 +/–

Сообщение от Аноним (-), 12-Окт-26, 18:12

> а чанки - размером с pagesize. Ага. И  Теперь представь, сколько
> их даже на 1 гиг выходит и как там с поиском
> нужного чанка дело обстоит ...
Да, мне еше интеерсно - в Linux нынче в моде folios так то. Что они будут делать если апя без folios просто повыпилят нахрен?
И конечно ворочание подшивками сильно более 4 кил за присест - снижает оверхед. И разгоняет всякие IOPS и GBPS на сверхскоростных девайсах. Даже у btrfs, ага. Который УЖЕ на однодисковом быстром ssd - ZFS'у в обычном незамороченном бенче мастеркласс дает буквально - везде. Чуть не в разы при том. Хотя его оптимизнули лишь местами.

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

199. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (196), 10-Окт-26, 17:48

Да, одна! И это ext4 на raid6.

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

201. "В ФС Ext4 намечен к удалению режим data=journal " –2 +/–

Сообщение от пох.. (?), 10-Окт-26, 18:09

> Да, одна! И это ext4 на raid6.
бльо... ну откуда ж вы лезете...

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

137. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Аноним (132), 09-Окт-26, 23:46

> Пыцаны btrfs же есть. Зачем из ext4 делать btrfs, или я что-о путаю?
Btrfs не делает двойную запись при сохранении семантики примерно равной полному журналу. А вот EXT4 очень даже - поэтому сабжевой фичой мало кто пользуется: больно уж это тормозит.
В случае настоящих CoW фокус в первом приближении в том чтобы журналом сделать всю площадь вообще. Тогда комитить в основную область не придется за ее отсутствием. Такой вот нахальный чит. Даже работает в целом.

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

143. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от пох.. (?), 10-Окт-26, 00:22

>> Пыцаны btrfs же есть. Зачем из ext4 делать btrfs, или я что-о путаю?
> Btrfs не делает двойную запись при сохранении семантики примерно равной полному журналу.
У нее нет ничего похожего на полный журнал, и она делает не двойную а примерно 16рную.
> В случае настоящих CoW фокус в первом приближении в том чтобы журналом
> сделать всю площадь вообще. Тогда комитить в основную область не придется
> за ее отсутствием. Такой вот нахальный чит. Даже работает в целом.
нет.
журнал либо есть либо его нет вообще. У btrfs его, можно считать, что нет. Зато есть 32-64x оверхед на запись единичного блока.  И конечной точкой являются стопиццот копий суперблока, каждую из которых надо обновить чтобы запись одного байтика можно было считать подтвержденной. У ext4 даже с data=journal оверхед минимум вдвое меньше, потому что данные обновляются в том же месте где были, поэтому не надо корректировать указатели на эти данные и указатели на указатели.

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

237. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (-), 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ообщить модератору

249. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 11-Окт-26, 13:58

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

> и чего там в граммах было под МОИМИ сценариями. Что там
> твой сферический блок в вакууме делает - мне малоинтересно. Потому что
> это не мой сценарий.
держи в курсе.
(особенно смешно с учетом единственного озвученного тобой правдоподобного сценария, хотя и в его правдоподобие верится с большим трудом. И тем более в то что ты проверял сколько и чего там пишется в этом случае.)

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

260. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Аноним (-), 11-Окт-26, 19:42

> причем бы здесь - журнал (данных)? Журнал не про комиты.
В конечном итоге цель всей этой возни - получение того или иного диалекта 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ообщить модератору

178. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (-), 10-Окт-26, 14:08

Btrfs имеет просто огромный оверхед. Нам просторах интернета даже исследование на эту тему встречалось... сравнение с ext4, xfs, zfs. Если мне не изменяет память, все очень плохо.

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

180. "В ФС Ext4 намечен к удалению режим data=journal " –2 +/–

Сообщение от Аноним (162), 10-Окт-26, 14:41

Нет там никакого оверхеда, по крайней мере не при обычном повседневном использовании.

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

238. "В ФС Ext4 намечен к удалению режим data=journal " +2 +/–

Сообщение от Аноним (-), 11-Окт-26, 12:05

> Нет там никакого оверхеда, по крайней мере не при обычном повседневном использовании.
При обычном десктопном юзеже рост sectors written за скажем месяц - на btrfs vs ext4 ну может на 20-30% отличается в крейсерском режиме. И конечно никаких 64х и рядом нет.
Так что если он проживет не 100 лет а "всего" 70 - я, наверное, переживу...

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

243. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от пох.. (?), 11-Окт-26, 13:12

>> Нет там никакого оверхеда, по крайней мере не при обычном повседневном использовании.
Вот у этого анонима лучше получилось - на 30 процентов!
> При обычном десктопном юзеже рост sectors written за скажем месяц - на
> btrfs vs ext4 ну может на 20-30% отличается в крейсерском режиме.
показатели достигли потолка, с которого и были взяты?
> И конечно никаких 64х и рядом нет.
ты конечно - мерял?
И можешь сейчас продемонстрировать методику измерения?
(единственное с чем соглашусь - при обычном чтении опеннета и просмотре прона - современные носители как-нибудь справятся за приемлемое время, и выбор основан на других факторах)

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

262. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Аноним (262), 11-Окт-26, 20:08

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

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

269. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (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. Как-то так.

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

280. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 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ообщить модератору

282. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от Аноним (162), 12-Окт-26, 04:09

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

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

283. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (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 (со сжатием и без).

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

288. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 12-Окт-26, 10:02

ты тут - сжатие протестировал. собственно, с zfs/btrfs это очевидно.
осталось только вытащить на свет алгоритмы сжатия и точные их параметры - размер блока и коэффициенты. Вангую что у zfs блок был самый большой - те самые 128k, btrfs жмет какими-то помельче.
А на ext4 сжатия не было вовсе.
логично, если сжать данные, допустим, вдвое, wa на cow упадет даже не вдвое а 2*wa раз.
Кажется, поэтому местные эксперты проблему в zfs и не видят (там всегда включено, пока сам не выключишь. В btrfs, afaik, до сих пор по умолчанию off?)
Собственно, забавного тут то что по ext4/xfs ты получил ровно те цифры что в исследовании десятилетней давности. (а выключишь журнал - получишь равные)
т.е. механизм измеризмов иостатом можно в общих чертах принять за достоверный.

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

292. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (162), 12-Окт-26, 11:03

> ты тут - сжатие протестировал. собственно, с zfs/btrfs это очевидно
Нет, тут я протестировал усиление записи. Для zfs и btrfs результаты по WA представлены в двух вариантах -- для случая когда сжатие выключено (да, я знаю как это делается, представь себе) и для случая когда сжатие включено (zstd-1 в обоих случаях). Для ext4 и xfs результаты по очевидным причинам представлены в одном варианте.
> а выключишь журнал - получишь равные
По умолчанию ext4 журналирует только метаданные, так же как и xfs. И та, и другая ФС применялись с абсолютно дефолтными настройками, ничего дополнительно я не включал. Соответственно нечего и отключать. Если бы я на ext4 включил ещё и журналирование данных, то её результаты были бы в два раза хуже (я проверял). А разница в усилении записи на сжимаемых данных и несжимаемых видимо связана с тем, что ФС по-разному обрабатывают маленькие блоки. Дело в том что blogbench создаёт в ходе работы относительно крупные файлы, тогда как мой тест с несжимаемыми данными предполагает создание файлов от 512B до 512KB (хотя на самом деле можно было остановиться на 128KB, на результатах это не сказалось бы), по 4MB на каждый размер, с последующим десятикратным копированием всей этой кучи. Очевидно что доля мелких файлов в этом тесте гораздо больше, чем в тесте blogbench. Потому и цифры немного отличаются.

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

317. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Аноним (-), 13-Окт-26, 00:02

> Нет, тут я протестировал усиление записи. Для zfs и btrfs результаты по
> WA представлены в двух вариантах -- для случая когда сжатие выключено
> (да, я знаю как это делается, представь себе) и для случая
> когда сжатие включено (zstd-1 в обоих случаях). Для ext4 и xfs
> результаты по очевидным причинам представлены в одном варианте.
Ну ты то тестировал наверное что-то более реалистичное, а не ультра-синтетику где господа вероятно писали - один 4K блок - с форсированным sync этого всего, чего доброго там еще какой-то dirty до них был - и вот так да, можно и 64x наверное получить.
Вот только это - показуха а не крейсерское состояние дел. При том академик с своим пафосом вообще куда-то делся, и никакого ФС вообще на публику не зарелизил. А похонах в виндусях отвисает с NTFS позорным.

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

327. "В ФС Ext4 намечен к удалению режим data=journal " +/–

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

320. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 13-Окт-26, 00:25

> Нет, тут я протестировал усиление записи. Для zfs и btrfs результаты по
> WA представлены в двух вариантах -- для случая когда сжатие выключено
тогда что-то это странное. Не сходится с тем что я знаю о внутренних структурах.
И подозрение падает таки на iostat как средство контроля.
> (да, я знаю как это делается, представь себе) и для случая
я бы на эту zfs пожалуй бы повнимательней посмотрел. насколько я знаю (это могло устареть, поскольку я не имею дел с zol) отключение сжатия (не несжимаемые файлы а compression=off) отключает заодно и variable blocks (и embedded туда же). Т.е. если ты ничего не трогал, она должна начать писать 128k блоками.
> По умолчанию ext4 журналирует только метаданные, так же как и xfs. И
вот попробуй выключить методом nojournal
эти метаданные там очень недешево обходятся в некоторых случаях.
ну и нет еще одного тестового паттерна во всем этом - а что происходит если мы в существующем файлике что-то пытаемся поменять (привет вон недавнему journald позорищу)

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

321. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 13-Окт-26, 00:41

> данными предполагает создание файлов от 512B до 512KB (хотя на самом
> деле можно было остановиться на 128KB, на результатах это не сказалось
кстати, зря. И результат для Zfs должен быть очень заметен, и еще интереснее если добраться до двух мегабайт.
в dnode помещаются только три указателя, и не спрашивайте как так ;-) Т.е. с 372k+1байт начинается магия.
опять же если эту разницу будет видно в твоем тесте - это подтвердит что тест действительно меряет wa а не погоду на марсе.

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

47. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (46), 09-Окт-26, 12:13

Скорее всего это чатботы шалят опять. Ну конечно, будто в ext4 всё остальное работает. У неё куча ограничений и ограничения data=journal не самые худшие (особенно, если они задокументированы).

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

56. "В ФС Ext4 намечен к удалению режим data=journal " +2 +/–

Сообщение от pfg21 (ok), 09-Окт-26, 13:03

интересно какой процент возмущающихся и почему использует журналирование содержимого в своей практике ??

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

62. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 09-Окт-26, 13:33

ну мы когда-то давно обсуждали перспективу хранилки с быстрым ssd (сейчас бы это был наверное dm mirror поверх nvme) для журнала. Т.е. синхронная запись почти мгновенно приземляется в журнале, и возвращает ок, а переписыванием на медленную основную фс мы занимаемся асинхронно и никому не мешаем, данные уже один раз сохранены.
Но по факту разумеется все выбрали готовые промышленные схд.
А поверх ext4 nojournal.

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

112. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от _ (??), 09-Окт-26, 19:36

bcachefs ... но аффтЫрь чего то того ... :(

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

117. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 09-Окт-26, 19:45

> bcachefs ... но аффтЫрь чего то того ... :(
я показывал ссылку на статью 12го года про bcache без fs. Все плохо.
С этим автором каши не сваришь.
только storage space direct спасет мир. Может быть.
(но говорят что как раз это место в ней лучше обходить горными тропами)

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

120. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от User (??), 09-Окт-26, 20:11

Да вот как будто бы и пофиг уже. Вона, даже в postgresql чексуммы на уровне страниц в 18 версии по дефолту включили.
Во всяких block storage навроде недоброй памяти minio erasure coding И избыточность по дефолту, в кафке crc аж в двух местах (но надо знать нюансы), в nosql consistency level На чтение/запись почитай с самого начала - и примерно пофиг, что там под седалищем лежит - нижний слой по определению не надежен.

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

145. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 10-Окт-26, 00:46

> Да вот как будто бы и пофиг уже. Вона, даже в postgresql
> чексуммы на уровне страниц в 18 версии по дефолту включили.
И что будем делать если чексума не совпала - встанем колом и будем ждать бэкап?
> Во всяких block storage навроде недоброй памяти minio erasure coding И избыточность
тоже не для этого.
это дублирование данных на случай отказа носителя. А не потери управления в момент записи. В этом минио точно так же полагается на xfs.
Попытки все слепить в одного монстра - это недоброй памяти ceph. Вот там все в одном, и база данных на raw части носителя, и block storage прямо в физические блоки диска. И неотвратимый п-ц всему, потому что сделать надежно там даже и не думали, да и было им нечем.

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

153. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от User (??), 10-Окт-26, 06:46

> И что будем делать если чексума не совпала - встанем колом и будем ждать бэкап?
Ээээ... Ну вот pgpro автоматически данные с реплики запрашивает, что не так?

> тоже не для этого.
это дублирование данных на случай отказа носителя.
И для этого тоже. Он так-то data shards и parity shards разбрасывавет и из этой "parity" их вполне себе восстанавливает что "налету", что при ручном heal. Это не "n-копий файла" В общем-то.

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

164. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 10-Окт-26, 09:43

> И для этого тоже.
нет. parity - на случай отказа _носителя_ и только для этого.
При внезапном отказе питания/сбое ноды - оно полностью полагается на позикс семантику и надежность файловой системы, это принципиальное решение самого Бабу еще времен гластера. Что если fscync вернул управление - данные ТОЧНО уже на диске и ими можно пользоваться (поэтому не выделывайтесь, и пользуйтесь только xfs, только с ним они на самом деле тестируют и только для него будут подкладывать костылики и подпорочки).
Иначе восстанавливать будет просто нечего. В том числе потому что метаданные тоже должны писаться гарантированно и до ответа ок в приложение.
И так - по _всей_ иерархии хранения - во всяком случае, должно быть. Приложение-база или блокстор-диск под ним-диск под виртуализацией или что там тот диск имитирует-хранилка-диски самой хранилки. У тех у кого данные представляют хоть какую-то ценность. Потому что если ты все синкнул, а шибкоумный дисковод решил проигнорировать flush cache - результат тот же как если бы ты вообще все асинхронно писал, только еще и медленнее в разы.
И проверки могут потом не сработать, потому что crc блока совпадет - потому что это другой какой-то блок либо уже удаленный сто лет назад, либо не туда записавшийся, но crc-то в нем ему соответствует.

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

170. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от User (??), 10-Окт-26, 10:17

>> И для этого тоже.
> нет. parity - на случай отказа _носителя_ и только для этого.
Эээээ... там отдельно - highway hash для обнаружения и кодирование с избыточностью в рамках erasure set (Который у тебя вот не одна нода) для восстановления если что. _И_ обнаружение, _И_ самовосстановление. И нет, на надежность ФС под ней примерно пофиг
И да, сценарий с "а теперь я чего-нибудь в данных на ноде ручками попорчу" я лично проверял - работает )

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

172. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 10-Окт-26, 11:08

ты неправильно проверял. Положи вместо чанка - другой чанк.
Контрольная сумма - совпадет.
ecc не совпадет но восстановить ничего все равно нельзя. И даже обнаружить проблему сложно.
А именно это происходит если после крэша у тебя произвольный мусор вместо даных (потому что произвольный мусор на диске забитом блокстором - будет в основном из бывших блоков и состоять - а у них все суммы сойдутся)
Еще хуже будет - если что-то произойдет с xl.meta

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

177. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от User (??), 10-Окт-26, 14:04

> ты неправильно проверял. Положи вместо чанка - другой чанк.
> Контрольная сумма - совпадет.
> ecc не совпадет но восстановить ничего все равно нельзя. И даже обнаружить
> проблему сложно.
> А именно это происходит если после крэша у тебя произвольный мусор вместо
> даных (потому что произвольный мусор на диске забитом блокстором - будет
> в основном из бывших блоков и состоять - а у них
> все суммы сойдутся)
> Еще хуже будет - если что-то произойдет с xl.meta
Ну, те-о-ре-ти-чес-ки возможность, что тебе отгрузят вот правильный datadir, правильный part правильного размера и даже набор блоков в нем с правильными контрольными суммами - но не все они вот именно от этого объекта/версии есть - но это скорее из разряда "если в слове хлеб сделать четыре ошибки - получишь слово пиво". И нет, с восстановлением-то как раз никаких проблем нет (да вот хоть бы и через пересоздание проблемной ноды) - а вот насчет своевременного обнаружения вопросики.
Но тут уж если тебе _настолько_ важны не те данные, чтобы события с такой вот вероятностью обрабатывать - ты, наверное, контрольную сумму объекта перед записью в стор и сам посчитаешь с хоронением её куда-нибудь в диапазоне от S3'шных метаданных до отдельной базюли включительно, да? За одним и часть сценариев с повреждением-до-записи отсечёшь.
А вот делать под этим всем бырбырбыр или там ext4 с тем вот журнальчиком ты не будешь, ибо производитель не рекомендует, а в случае с ext4 так и явно запрещает - minio записью сам управляет и O_DIRECT во всю использует.
Ну и с xl.meta тоже не беда - там так-то кворум, эти типовые сценарии я тоже проверял ).

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

188. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 10-Окт-26, 15:40

> Ну, те-о-ре-ти-чес-ки возможность, что тебе отгрузят вот правильный datadir,
в смысле? Это и есть то что гарантирует data=ordered
Хватит одного случайно восстановившегося/смотрящего не на нужную иноду файлика.
> И нет, с восстановлением-то как раз никаких проблем нет
есть, потому что мы теперь не знаем на каком именно узле файл неправильный. ec на этот вопрос либо не отвечает вовсе, либо отвечает странным образом при n>=2 - декодировать _все_ возможные варианты, сравнить и выбрать единственный несовпадающий - это и есть правильный, а в остальные попал битый блок.
Поэтому пользуйтесь xfs при всех ее минусах - да, ее фишка с обнулением сомнительных инод - именно для этого и затевалась. Теперь ты ТОЧНО знаешь какая копия битая и никак не сможешь незаметно использовать оттуда данные.

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

220. "В ФС Ext4 намечен к удалению режим data=journal " +/–

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

233. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 11-Окт-26, 11:32

такая же вот фигня. Поэтому надеемся на xfs, на которой такая подмена _вроде_бы_ невозможна, файл либо нулевой, либо правильный, либо предыдущей версии (чего быть не должно при правильной конструкции хранилки)
А ее глюки на моем конкретном железе под хранилкой - пока - не всплывали.
> Ну так и пользовались же ж - пока тот minio жив был.
ща нам тут прибегут рассказывать как код с гитхаба никуда не испарился ;-)
на самом деле он и теперь живее всех живых, а дядиных денег-то мне ничуть и не жаль. (импортозамечателям вот не повезло, их деньгов никто даже и не возьмет. придется самим.)

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

57. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от Аноним (57), 09-Окт-26, 13:06

Выкапывайте стюардессу! JFS всмысле.

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

59. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (59), 09-Окт-26, 13:21

Что-то,. помню, она ломалась при любом нештатном выключении питания, требуя ручного запуска fsck после.

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

60. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (60), 09-Окт-26, 13:24

NILFS!

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

79. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Tron is Whistling (?), 09-Окт-26, 15:01

devnullfs

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

82. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от Аноним (48), 09-Окт-26, 16:10

Ее корпораст пилил, она работает. Только фсчек надо из чрут запускать, а то ридонли станет.

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

63. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (34), 09-Окт-26, 13:34

Арчеводы не согласны!
https://wiki.archlinux.org/title/Ext4#Disabling_journaling
> Use the journal to optimize performance

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

67. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от Аноним (46), 09-Окт-26, 13:50

Сколько не замерял, то, что они предлагают только снижает общую производительность раз в 10. Больше слушайте этих домохозяек.

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

73. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (71), 09-Окт-26, 14:40

Во-первых, "Use the journal to optimize performance" - это следующий пункт, сразу после того на который ты ссылку скинул. Во-вторых прочитай что ты скинул. Там сравнение идёт между "data=journal" и дефолтным "data=ordered".

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

68. "В ФС Ext4 намечен к удалению режим data=journal " +3 +/–

Сообщение от EuPhobos (ok), 09-Окт-26, 14:03

Почему не сделаю ext5 если ломают обратную совместимость?! Что за идиотизм..

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

114. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от _ (??), 09-Окт-26, 19:39

Почему - почему ... по - плану!(С) :(

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

138. "В ФС Ext4 намечен к удалению режим data=journal " –2 +/–

Сообщение от Аноним (132), 09-Окт-26, 23:47

> Почему не сделаю ext5 если ломают обратную совместимость?! Что за идиотизм..
Теодор Тсо предельно ясно высказался по этому поводу. Если ты святее папы римского - сам и девелопай.

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

161. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от EuPhobos (ok), 10-Окт-26, 08:21

Всё отлично, но было бы хорошо, не получить мне сюрприз в самый неподходящий момент:
В надежде, что у меня всё сработает, я записал кучу информации на HDD на ext4, и поехал с этим HDD к другому ПК, и при попытке смонтировать его там - получаю ошибку.
А потом погуглив понимаю, что создал я ext4 на более новой версии, а более старая система, у которой rootfs тоже на ext4, она которая не может примонтировать мой HDD, потому что на нём ext4 созданная более свежими тулзами.
И тут я понимаю, какой п#$%@ц тут происходит, когда у тебя система на ext4, не может примонтировать ext4

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

168. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 10-Окт-26, 09:58

> И тут я понимаю, какой п#$%@ц тут происходит, когда у тебя система
> на ext4, не может примонтировать ext4
МВАХАХХАХАХХА!
и этот поц еще не в курсах про block size != page size
А вот приехал бы ты к другу с ntfs - если у того не 98я конечно винда - все бы прочиталось.

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

192. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Аноним (189), 10-Окт-26, 16:48

Враньё. NTFS вечно меняет версию ФС втихую. И при подключении диска с новой NTFS в комп со старой виндой, ФС либо не читается, либо вообще весь комп выпадает в синий экран.

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

207. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (207), 10-Окт-26, 21:29

Только вот диски, отформатированные ещё в XP, "почему-то" работают в "десятке" 🤦

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

218. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 11-Окт-26, 09:39

> Только вот диски, отформатированные ещё в XP, "почему-то" работают в "десятке" 🤦
и наоборот работают, повторяю - каждая первая флэшка больше 4 гигабайт с 12 по 18й годы.
xp уже давно была антиквариатом (что не отменяло и даже увеличивало шансы что придется таки тащить на нее что-то на флэшке)
И вероятно по сей день - каждый первый внешний жесткий диск на рынке. (давно не покупал новых, но вряд ли там exfat)
Откуда, откуда они тут берутся да еще в таком количестве? Ну это ж в каком пузыре надо существовать, чтоб такое нести уверенным тоном?

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

176. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Аноним (176), 10-Окт-26, 13:20

> ext4, не может примонтировать ext4
ну это же было достаточно давно, хотя неприятно.
посему у мну для хомяка ext3, а ext4 для системы...

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

263. "В ФС Ext4 намечен к удалению режим data=journal " –2 +/–

Сообщение от Аноним (-), 11-Окт-26, 20:29

> Всё отлично, но было бы хорошо, не получить мне сюрприз в самый
> неподходящий момент:
С 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 есть куча субдиалектов так то на самом деле.

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

69. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от DEF (?), 09-Окт-26, 14:23

Теодор Тцо, разработчик ext4, рекомендует переходить на Btrfs, как на более продвинутую и современную ФС.

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

72. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (72), 09-Окт-26, 14:36

Значит теперь будут искусственно кастрировать другие файловые системы.

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

89. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Аноним (89), 09-Окт-26, 16:36

Именно, в этом и смысл

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

130. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от yylloc (-), 09-Окт-26, 23:14

> Именно, в этом и смысл
Но где?
APFS не загнулась, NTFS тоже. Хотя, не о тех вспомнил. Начинаем: NILFS, QIC, 9fs, NFS, eroFS, exFAT, F2FS, ZFS. Да даже FAT32. Продолжать можно долго, это ещё BSD не упоминаю. btrfs чем так ужасна?
Насчёт слишком раннего выпиливания - полностью согласен. ext4 должна умереть в январе 2038, как и огромное количества не критической legacy инфраструктуры.

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

142. "В ФС Ext4 намечен к удалению режим data=journal " –2 +/–

Сообщение от Аноним (72), 10-Окт-26, 00:01

>Начинаем
Всё это сторонние фс в линксе не являются конкурентами btrfs.
>btrfs чем так ужасна?
https://lkml.org/lkml/2010/6/3/313

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

239. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (-), 11-Окт-26, 12:07

>>Начинаем
> Всё это сторонние фс в линксе не являются конкурентами btrfs.
>>btrfs чем так ужасна?
> https://lkml.org/lkml/2010/6/3/313
Сведения 16-летней давности. Какая милота :). И главное - все эти говорящие головы забыли решения лучше выкатить. Так что могут идти обратно в свой телевизор.

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

76. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (76), 09-Окт-26, 14:57

Потом выйдет EvenBetterFS и все дружно на неё переходить будем?

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

86. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (86), 09-Окт-26, 16:26

Есть же bacachefs. Лучшая ФС. Жаль только выпилили побоявшись конкуренции.

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

96. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (95), 09-Окт-26, 17:30

> Потом выйдет EvenBetterFS и все дружно на неё переходить будем?
А почему бы и нет?
Вам цифорка 4 в Ext4 ни на что не намекает?))
Если будет лучше - то разумеется перейдем.

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

80. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (42), 09-Окт-26, 15:51

Но на неё забил редкат?

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

84. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от Аноним (48), 09-Окт-26, 16:13

На СистемД перевели и тут никуда не денуться. Организация одна и та же.

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

88. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (57), 09-Окт-26, 16:35

А на ней система за 2 секунды загружается?
А файлы там сами себя пишут, сами проверяют контрольные суммы, а фс это типа композитор?

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

125. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от _ (??), 09-Окт-26, 20:54

Не важно.
Не тебе решать что в линуксе юзать. И не мне. Да и * с ним! (C), ну что ж поделаешь?

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

139. "В ФС Ext4 намечен к удалению режим data=journal " –5 +/–

Сообщение от Аноним (132), 09-Окт-26, 23:51

>  А на ней система за 2 секунды загружается?
Две не две а одноплатник с 1ГГЦ 1 ядерным 32 бит процом секунд за 5 подымается. С системдой, ога. При том половину занимает декомпресс ядра и проч.
Если скорость монтирования btrfs важна - его надо делать с block group tree. Можно его потом отрастить, требует ядро 6.1 или новее. Так он маунтится... чуть не быстрее сабжа. А если сабж еще и крешнулся и там fsck... ух... ну запустите это на винче терабайт на 5 забитом, посмотреть как вам идея fsck такой шляпы вообще.

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

83. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Инопланетянин (?), 09-Окт-26, 16:13

> Опция "data=journal" включает режим полного журналирования, при котором в журнал записываются не только метаданные, но и сами данные, что обеспечивает высокую устойчивость в случае сбоев
Получается журналирования данных не будет или есть какая-то другая опция?

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

92. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Аноним (92), 09-Окт-26, 17:02

Да, не будет. Чтобы клиенты начали покупать специализированные средства.

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

158. "В ФС Ext4 намечен к удалению режим data=journal " –2 +/–

Сообщение от Аноним (158), 10-Окт-26, 07:15

Журналирование никуда не делась. Просто убрали не нужный функционал.

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

87. "В ФС Ext4 намечен к удалению режим data=journal " +2 +/–

Сообщение от Cyber100 (ok), 09-Окт-26, 16:32

удалить журналирование, которое каждый по желанию мог отключать сам == это гипер-сильно. и на каких таких скоростных устройствах кто-то там заметил якобы тормоза от создания записей транзакций...

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

99. "В ФС Ext4 намечен к удалению режим data=journal " –2 +/–

Сообщение от пох.. (?), 09-Окт-26, 18:28

тормоза как раз на медленных устройствах - буквально вот 8x write amplification вместо 4x у обычной ext4.
И решалось это выносом лога на сверхбыстрый носитель. Но, кстати, верю что там тоже код тяпляпаный и скорость nvme используется только на треть.

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

124. "В ФС Ext4 намечен к удалению режим data=journal " +2 +/–

Сообщение от Аноним (124), 09-Окт-26, 20:48

Ext4 - журналируемая файловая система. Начиная с ядра 7.3 не журналируемая. Как теперь её описывать - Ext4 - журналируемая файловая система до ядра 7.2 включительно. Полужурналируемая система. Недожурналируемая система. Все кто против - старые пердуны, луддиты ретрограды. Главное первым начать громко и чётко стигматизировать тех кто против. Часто вспоминаю времена, когда перешли на Ext4 после Ext2... эх.

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

140. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Аноним (132), 09-Окт-26, 23:52

Вообще XFS тоже такой полунедожурналируемый. Как и JFS какой. Полный журнал на классике - пишет данные два раза и это комбо посему тормозит как апокалиптец.

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

157. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (158), 10-Окт-26, 07:13

>Полный журнал на классике - пишет данные два раза
Ты выдумываешь. Такой классики не бывает.

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

165. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от пох.. (?), 10-Окт-26, 09:46

>>Полный журнал на классике - пишет данные два раза
> Ты выдумываешь. Такой классики не бывает.
бывает, гугли про log structured fs. Ну по дороге нагуглишь, конечно, почему бывает, но как динозавры примерно. В каких-то окаменелостях иногда находят.

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

274. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Аноним (-), 11-Окт-26, 23:02

> бывает, гугли про log structured fs. Ну по дороге нагуглишь, конечно, почему
> бывает, но как динозавры примерно. В каких-то окаменелостях иногда находят.
Log structured это по сути - диалект CoW технологии как таковой. Просто оно у тех кто пробовал - было еще более странными зверушками чем btrfs. Но в конечном итоге CoW все делают что-то наподобие по общему смыслу действа, для избегания двойной записи. Конкретные детали реализации интересны в основном - с точки зрения достигнутых параметров. А общая идея действа остается та же самая.

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

264. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (264), 11-Окт-26, 20:31

>>Полный журнал на классике - пишет данные два раза
> Ты выдумываешь. Такой классики не бывает.
Да вот же - сабж. Сперва в журнал, потом в основную область. Классика жанра. Отстойная по перфомансу - за что и не используется как правило.

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

179. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Аноним (-), 10-Окт-26, 14:20

ZFS? Тут все честно.

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

219. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от пох.. (?), 11-Окт-26, 09:43

> ZFS? Тут все честно.
там нет именно журнала данных.
Там за счет структуры фс чуть лучше с гарантиями, но все зависит от аккуратности автора приложения. (и немножко от везения)
Т.е. как раз читеры ;-)

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

275. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Аноним (-), 11-Окт-26, 23:04

>> ZFS? Тут все честно.
> там нет именно журнала данных.
> Там за счет структуры фс чуть лучше с гарантиями, но все зависит
> от аккуратности автора приложения. (и немножко от везения)
> Т.е. как раз читеры ;-)
Проблема в том что с его околоблочной структурой все это ему очень мало поможет уже.

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

261. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Alladin (?), 11-Окт-26, 19:44

да, большая часть данных в озу - всегда
теряем данные так теряем, ни шагу назад

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

129. "В ФС Ext4 намечен к удалению режим data=journal " +1 +/–

Сообщение от ятупойтролль (ok), 09-Окт-26, 22:40

а в чем проблема сделать ext5? религия не позволяет? нужно сломать то, что уже работает у миллионов людей?

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

167. "В ФС Ext4 намечен к удалению режим data=journal " –2 +/–

Сообщение от пох.. (?), 10-Окт-26, 09:55

> а в чем проблема сделать ext5? религия не позволяет?
гранты платиновых спонсоров не позволяют.
Те не собираются вносить двойную оплату, а в виду шта6ле нонсенса - второй клон фс сам себя не поддержит. А дедушка стар и устал, он желает - в сортир.
(на самом деле изрядно нае..лись с ext2 и потом ext3, это реально было крайне хреновое решение, и, поскольку гугль не собирался делиться патчами - проще было зак0пать, чем оживлять те трупики. А деду еще не было и 50, он был еще полон сил и энтузазизьма.)

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

308. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Аноним (-), 12-Окт-26, 22:48

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

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

309. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 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ообщить модератору

330. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Frestein (ok), 13-Окт-26, 12:41

А эти миллионы в курсе, что у них работает?

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

155. "В ФС Ext4 намечен к удалению режим data=journal " –5 +/–

Сообщение от Аноним (162), 10-Окт-26, 06:48

Этот древний хлам вообще давно пора выбросить из ядра. Что заставляет людей при наличии таких фс как btrfs и zfs продолжать пользоваться откровенно отсталой ext4 одному богу известно.

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

156. "В ФС Ext4 намечен к удалению режим data=journal " +4 +/–

Сообщение от Аноним (158), 10-Окт-26, 07:10

Толсто. Ext4 самая надёжная ФС.

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

160. "В ФС Ext4 намечен к удалению режим data=journal " –2 +/–

Сообщение от Аноним (162), 10-Окт-26, 07:51

> Толсто. Ext4 самая надёжная ФС.
Это пока у тебя при обновлении что-нибудь не сломалось, и толку тогда от этой надёжности? Снимков нет, контрольных сумм данных нет, возможности хранить чувствительные данные в нескольких образцах нет, возможности создания рейд-массива (хотя бы зеркала) нет. Хочешь рейд и контрольные суммы -- будь добр, городи многоэтажные костыли из кучи малосвязанных инструментов. Зато быстрая, ага.

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

166. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от пох.. (?), 10-Окт-26, 09:51

>> Толсто. Ext4 самая надёжная ФС.
ну нет. Ладно б еще ntfs3g, скажем. Самая надежная - fat32. Максимальная избыточность метаданных, максимальная простота восстановления, обычно линейная запись. Ну есть и недостатки но они не в ненадежности.
> Это пока у тебя при обновлении что-нибудь не сломалось, и толку тогда
Как тебе удается при обновлении что-нибудь сломать и что ты там блин обновляешь?!
> от этой надёжности? Снимков нет, контрольных сумм данных нет, возможности хранить
опять эти свидетели контрольных сумм... да где вы берете такие проблемы, и почему ни один не смог ни разу хотя бы лог предъявить? (я уж молчу - провести _инженерное_ расследование инцидента)
> чувствительные данные в нескольких образцах нет, возможности создания рейд-массива (хотя
> бы зеркала) нет. Хочешь рейд и контрольные суммы -- будь добр,
> городи многоэтажные костыли из кучи малосвязанных инструментов. Зато быстрая, ага.
А рейд и контрольные суммы вообще нужны не всегда и частенько куча малосвязных инструментов в том и или ином виде и так в наличии.

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

212. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от maximnik0 (?), 11-Окт-26, 01:14

>контрольных сумм данных нет
Уже есть.Но костыльно - проверка только на чтение, есть специальная псевдо фс ,записывает методанные с контрольной суммой в скрытые файлы на существующию фс.Теоретически позволяет создавать КС для данных даже для фат.Костыли для снимков делали ,в основное ядро не пошло,аж два независимых проекта,лень вспоминать названия.

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

250. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 11-Окт-26, 14:04

> Уже есть.Но костыльно - проверка только на чтение, есть специальная псевдо фс
г-ди... ну осильте ж вы уже md5sum , а?!
(я уж молчу про mtree, если ценность имеют не только отдельные файлики а то как они лежат при этом)
никакие специальные фс для этого не нужны, и перепроверить что вы имеете дело с неповрежденными файлами можно хоть на винде потом.

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

265. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Аноним (264), 11-Окт-26, 20:32

>> Уже есть.Но костыльно - проверка только на чтение, есть специальная псевдо фс
> г-ди... ну осильте ж вы уже md5sum , а?!
Ага, и вот ща буду каждый проект KiCad после очередного сохранения md5sum гонять...

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

267. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от maximnik0 (?), 11-Окт-26, 22:02

>никакие специальные фс для этого не нужны,
Тут куча народа писала- что у ext4 из за отсутствия контрольной суммы спокойно может уйти повреждённый файл в бэкап а ты и знать про это не будеш. В отличие от к примеру btrfs. Вот для этого и есть костыль : fs-verity — это функция ядра Linux, предназначенная для прозрачной проверки целостности и подлинности отдельных файлов.fs-verity защищает отдельные файлы на файловой системе, которая может быть read-write (например, ext4, f2fs, btrfs. Не совпадает хэш - выдаст функция ошибку чтения, админ узнает о повреждении файлов.

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

273. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 11-Окт-26, 23:01

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

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

278. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от maximnik0 (?), 11-Окт-26, 23:18

>Причем _самая_ из них невероятная - это как раз повреждение данных при исправной фс непосредственно на диске.
Это как раз самая вероятная причина - сейчас идут черепичники.И у многих  есть алгоритм  для редко используемых файлов переместить эти файлы в зону черепиц+ идёт таблица замены адресации.И не чего с этим сделать не реально_ обычных дисков все меньше и меньше:-(

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

314. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 12-Окт-26, 23:43

> Это как раз самая вероятная причина - сейчас идут черепичники.И у многих
они ни в каких скрытых потерях данных не замечены. Они просто жутко медленные при произвольной записи. И иногда просто дохнут. Если у гибридных слетит таблица - они просто отыквятся, без всяких скрытых ходов, даже опознаваться перестанут как устройство.
и обычные диски никуда не деваются, smr были и остаются в самом дешевом углу рынка.
что wd gold, что exos'ы, что тошибы Nseries по прежнему где были там и остались.
единственное исключение - позорная история барракуд, переименованных в про, чтобы дать место мусору с пола цеха под тем же именем. Через некоторое время сигейт спохватилась, про быстренько зак0пали, но все куды >8T снова cmr. (К покупке все равно настоятельно не рекомендую, но чудо-повреждений данных у них тоже не бывает.)
Кстати, куды превращались в тыковку (тоже из-за повреждения некоторых внутренних данных) задолго до smr и нанд-схем. Опять же никакие контрольные суммы тут тебе не помогли бы - оно с негромким "чпок" становилось 0 байт емкости.

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

318. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от maximnik0 (?), 13-Окт-26, 00:03

>они ни в каких скрытых потерях данных не замечены
Повреждаются файлы ,если бы не BTRFS я бы про это дело хрен узнал бы.Может у 3,5 все и хорошо,а вот с ноутбучными так мне не везёт -2 года и наченяються байтики портиться.И при этом SMART щука молчит пока специально полную проверку не устроит, только тогда переназначенные сектора вылазят :-( Радует только одно -как чуял была возможность набрал дисков, сейчас цены улетели в космос.

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

322. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 13-Окт-26, 02:31

ноутбучные больше терабайта - все smr, чудес-то не бывает, не впихнуть в этот размер ничего больше. Последними cmr были терабайтные hgst.
но я бы подозревал в порче байтиков все же не smr а память того ноутбука.
ремапы это другая история, это сектор просто не читается/читается за неприемлемое время. пока не попытаешься прочитать - не узнаешь, smart о нем тоже не узнает, так что тут все со смартом в порядке. с любой фс результат будет совершенно одинаковый - повисание программы и сбои сектора в dmesg, когда ты наконец попытаешься его прочитать.

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

325. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от maximnik0 (?), 13-Окт-26, 02:48

>но я бы подозревал в порче байтиков все же не smr а память того ноутбука.
Сутки гонял тесты , нечего memtest не нашел.А ошибка у меня вообще прикольная была- каталог очень давно не лазил,решил удалить.Так байтики повреждённые оказались, но Btrfs поченил , там именно байты,crc коррекции хватило.Но я не мог каталог удалить-откат транзакции из за некорректных методанных,b-дерево инод.

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

276. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Аноним (-), 11-Окт-26, 23:08

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

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

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

Сообщение от пох.. (?), 12-Окт-26, 23:48

> Еще веселее когда у тебя ВНЕЗАПНО - бабах - readonly filesystem! Бабах
> fsck - опа, а теперь совсем фаталити. А план на этот
опять врунишка выдает на гора какие-то свои фантазии и что-то прочитанное в интернетах.
> А в чем прикол? У кого оператива глючит. У кого проц сбоит.
> А кому - вот - драйвер Nvidia память бил, прямо эпидемия
от этого точно помогут контрольные суммы фс, местный анонимный кексперт- восстановитель данных зуб дает.
господи, ну как можно такую чушь нести?

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

173. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (173), 10-Окт-26, 11:48

Подскажите, какая файловая система Linux лучше всего подойдёт для хранения данных на внешних / съёмных жёстких дискаx? Ну, и на флешках...

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

185. "В ФС Ext4 намечен к удалению режим data=journal " –2 +/–

Сообщение от пох.. (?), 10-Окт-26, 15:31

размер дисков-то какой? И в чем цель хранения?
А то в диапазоне от ntfs3g до fat32+mtools
Зависит от того - тебе кинцо с десктопа до шибкоумного телевизора донести, свою нетленку на двести лет сохранить (но тут ты выбрал не те технологии вовсе), или ты с работы секретные доки тыришь. Или наоборот от налоговой прячешь...хотя да, причем бы тут линукс и его системы.

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

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

Сообщение от Аноним (207), 10-Окт-26, 21:27

NTFS

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

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

Сообщение от пох.. (?), 11-Окт-26, 12:33

> NTFS
подколка не засчитана. ntfs (и ntfs3g) хорошая фс, но у человека задача поставлена хоть и недостаточно четко, но - _хранение_ на _внешних_ носителях.
А значит скорее всего - больше запси чем чтения (или чтения нет вообще), это очень плохой паттерн для ntfs3g и так себе для ntfs3 (остальные вовсе мертвенькими родились), и возможность повреждения при отключении. Возможно его задачи гораздо лучше порешает mtools и fat32. (и да, очень жаль что нет похожего для ntfs)

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

205. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (205), 10-Окт-26, 20:48

до дропа слегка барахлящих жёстких дисков на всяких там пульсирующих аэрокулах 3... 2... 1...
ждём разброса на индийских и сомалийских помойках электронного мусора
а домой, похоже, придётся ставить redox, пока разрабы не пойдут ужинать с очередным баллмером

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

209. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Аноним (209), 11-Окт-26, 00:23

Господи, разговоров-то. Будто каждый второй использует data=journal (возможно, эти же люди пытаются попутно выиграть чуть-чуть производительности с помощью mitigations=off, чтобы уравновесить зло добром).

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

241. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 11-Окт-26, 12:39

> Господи, разговоров-то. Будто каждый второй использует data=journal (возможно, эти же
> люди пытаются попутно выиграть чуть-чуть производительности с помощью mitigations=off,
> чтобы уравновесить зло добром).
"когда они пришли за коммунистами..."
а когда они придут сломать тебе твою любовно построенную этажерку (потому что могут!) - уже всем будет похрену.

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

307. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Аноним (-), 12-Окт-26, 22:37

> а когда они придут сломать тебе твою любовно построенную этажерку (потому что
> могут!) - уже всем будет похрену.
Может он к тому моменту три новые этажерки построит, намного лучше, так что ему останется разве что сказать "спасибо что прибрали тут мусор"? :)

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

332. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от _ (??), 13-Окт-26, 16:50

Так редко кто нонче __новые__ этажерки строит то, всё больше новые версии старой... :-\
Даже семантик версионирование отовсюду выпилили чтоб у немамонтов вопросов ненужных не возникло :)

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

215. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (215), 11-Окт-26, 06:37

В плане устойчивости к внезапным выключениям ничего лучше NTFS не встречал. А Btrfs эта так вообще может сама по себе глючить.

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

247. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 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ообщить модератору

222. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (222), 11-Окт-26, 10:29

использую data=journal всегда и везде, производительность устраивает. они там о чем думают ломать надежный инструмент? давайте хоронить все что тормозит и плевать что это дает надежность, так?

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

223. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (222), 11-Окт-26, 10:32

безумие какое-то. с data=journal ext4 действительно надежная и быстрая fs.
на что тогда уходить если отключат? ext4 по сути реинкарнация ext3 которая продолжение ext2 с журналом - оно развивается больше 20 лет - стабильно уже очень и очень что проверено и мной в куче установок и множеством людей. что еще настолько же стабильно и надежно?

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

224. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (222), 11-Окт-26, 10:34

скажем ACID не будет работать на 100% если fs не гарантирует консистентность. ext4 с data=journal консистентность гарантирует и они это хотят сломать???

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

236. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 11-Окт-26, 11:59

> скажем ACID не будет работать на 100% если fs не гарантирует консистентность.
> ext4 с data=journal консистентность гарантирует и они это хотят сломать???
если твой acid пишет транзакции printf'ом не проверяя возвращаемое значение - нет, тоже не гарантирует.
Если правильно использует позик-семантику - даже data=writeback достаточно.
data=journal ни разу не для этого. Не нужно его использовать, если не понимаешь, для чего оно. (реальных причин - крайне мало или вообще ноль - зависит от вещей которые нужно тестировать прежде чем бежать внедрять, и если это кто и делал - они результатами не поделились)

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

277. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Аноним (-), 11-Окт-26, 23:10

> скажем ACID не будет работать на 100% если fs не гарантирует консистентность.
Большинство если не все реализации БД и проч - таки умеют жить с ТОЙ семантикой. Правда это - ценой выоса половины механики журнала на уровень приложухи...

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

259. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Alladin (?), 11-Окт-26, 19:41

ext4 надежная система, никогда на ней данных не терял. но и никакого data=journal я никогда не активировал
а значит, думаю ничего не поменяется

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

287. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Sm0ke85 (ok), 12-Окт-26, 09:18

Прочитал новость, объяснения выпиливания - глупые абсолютно, смотрятся как детский сад... Там реально хоть одна проблема то есть...? ext4 - rip в ближайшем будущем?

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

301. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 12-Окт-26, 12:03

> Прочитал новость, объяснения выпиливания - глупые абсолютно, смотрятся как детский сад...
> Там реально хоть одна проблема то есть...? ext4 - rip в
> ближайшем будущем?
а вот это ты узнаешь когда научишься кодить ;-)
пока есть личное мнение дедушки на зарплате ibm (которой работающая ext4 вообще не нужна) который пять лет назад признавался что кодить давно разучился, и ни на каком инструменте не играет, он руководитель.
(в основном причем погоняющий бесплатновую рабсилу)

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

303. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от Sm0ke85 (ok), 12-Окт-26, 13:44

>а вот это ты узнаешь когда научишься кодить ;-)
При чем тут "кодить" и конкретная реализация ФС...?
>пока есть личное мнение дедушки на зарплате ibm (которой работающая ext4 вообще не нужна) который пять лет назад признавался что кодить давно разучился, и ни на каком инструменте не играет, он руководитель.
>(в основном причем погоняющий бесплатновую рабсилу)
Пока ничего не ясно. Конкретика есть?

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

310. "В ФС Ext4 намечен к удалению режим data=journal " +/–

Сообщение от пох.. (?), 12-Окт-26, 23:13

>>а вот это ты узнаешь когда научишься кодить ;-)
> При чем тут "кодить" и конкретная реализация ФС...?
ты спрашиваешь - > Там реально хоть одна проблема то есть...?
я тебе отвечаю - научишься кодить - узнаешь, есть или не есть.
А пока вот:
>>пока есть личное мнение дедушки на зарплате ibm (которой работающая ext4 вообще не нужна) который пять лет назад признавался что кодить давно разучился, и ни на каком инструменте не играет, он руководитель.
>>(в основном причем погоняющий бесплатновую рабсилу)
> Пока ничего не ясно. Конкретика есть?
если ты имеешь в виду что я за тебя полезу разбираться в коде и принесу тебе результат на блюдечке, или кто-то еще с подобной квалификацией это сделает - то нет, такой нету и вряд ли будет.
К тому же не очень понимаю с чего ты готов поверить мне или какому-то другому васяну с опеннета, а не дедушке.
дедушка, лет 25 назад, когда еще был всего лишь уже немолодым человеком - сам (вроде, я со свечкой не стоял) руками это все написал. Стоит ли верить его мнению - это уж сам решай.
Своим глазам - верить, безусловно можно. Но надо кое-что знать и уметь.

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

329. "В ФС Ext4 намечен к удалению режим data=journal " –1 +/–

Сообщение от Sm0ke85 (ok), 13-Окт-26, 08:35

>ты спрашиваешь - > Там реально хоть одна проблема то есть...?
>я тебе отвечаю - научишься кодить - узнаешь, есть или не есть.
Ты глупости пишешь несусветные...
>если ты имеешь в виду что я за тебя полезу разбираться в коде и принесу тебе результат на блюдечке
Т.е. Ты кодить не умеешь или что? И при этом рассказываешь другим, что кодить нужно уметь...? Как у тебя это все в голове работает...? Поясни...?

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

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

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

Хоcтинг:

1. "В ФС Ext4 намечен к удалению режим data=journal "	+26 +/–
Сообщение от Аноним (1), 09-Окт-26, 09:51
Хлебом не корми - дай да выпилить что-нибудь что не сломано и жить не мешает.
Ответить \| Правка \| Наверх \| Cообщить модератору


	2. "В ФС Ext4 намечен к удалению режим data=journal "	+24 +/–
	Сообщение от A.Stahl (ok), 09-Окт-26, 09:54
	>жить не мешает приводит к значительному снижению производительности... не сочетается с некоторыми возможностями...и мешает реализации новой функциональности
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


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


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


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


	154. "В ФС Ext4 намечен к удалению режим data=journal "	+/–
	Сообщение от User (??), 10-Окт-26, 06:47
	... И натянул четвёртый слой резинотехнической защиты на свечку - ну, для НАДЁЖНОСТИ.
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


	216. "В ФС Ext4 намечен к удалению режим data=journal "	+/–
	Сообщение от User (??), 11-Окт-26, 07:21
	Оу. А для тех, кто считает "снапшоты" "бэкапами" в пятёрочке самая лагучая касса припасена.
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


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


	252. "В ФС Ext4 намечен к удалению режим data=journal "	+/–
	Сообщение от alexanderyt (ok), 11-Окт-26, 17:36
	Про виртуализацию тут никто и не вспомнил, кроме тебя. Так что, не пиши лишнего, за умного сойдешь.
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


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


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


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


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


	270. "В ФС Ext4 намечен к удалению режим data=journal "	+/–
	Сообщение от Аноним (-), 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ообщить модератору


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


	304. "В ФС Ext4 намечен к удалению режим data=journal "	+/–
	Сообщение от Аноним (-), 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 ощущают это отличие на уровне чуть ли не подсознания. И мы никогда не будем коллегами. Потому что таких как вы такие как я - презирают. >> Можно видите ли - > ... не путать одно с другим, но получается у поподвальных это вот > через раз - обычно после того, как мордочкой понатыкают. Ну вот я немного потыкал вас чтобы вы не зарывались. Вы сами по себе - не имеете ни единой заслуги где вы могли бы выйти и сказать "Я СДЕЛАЛ ЭТО!" - и показать ЭТО, конечно. В виде когда не будет возникать вопросов почему это было круто.
	Ответить \| Правка \| К родителю #285 \| Наверх \| Cообщить модератору


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


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


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


	19. "В ФС Ext4 намечен к удалению режим data=journal "	+1 +/–
	Сообщение от Kilrathi (ok), 09-Окт-26, 10:30
	Классика opensource: либо брать на себя поддержку режима, либо переходить на cow в zfs/btrfs (если производительность позволяет), либо компромиссить на xfs
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


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


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


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


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


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