forum.opennet.ru - "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повреждению ФС Ext4" (233)

"Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повреждению ФС Ext4"

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

"Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повреждению ФС Ext4"	+/–
Сообщение от opennews (??), 10-Дек-23, 11:30
Разработчики проекта Debian объявили о приостановке публикации установочных образов с обновлением Debian 12.3 из-за выявления в ядре Linux ошибки, приводящей к повреждению данных в файловой системе Ext4. Пользователям уже установленных систем рекомендовано воздержаться от установки обновлений пакетов с ядром из репозитория до публикации исправления... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60261
Ответить \| Правка \| Cообщить модератору

Оглавление

А я уже установил, что мне делать , Аноним (1), 11:30 , 10-Дек-23, (1)

Мигрируй на бтрфс , Аноним (5), 11:33 , 10-Дек-23, (5) +1

Чтобы не терять времени -- лучше сразу молотком комп разбить, чем сношаться с ра, Аноним (29), 12:00 , 10-Дек-23, (29) +5

посоны поговаривают что бтрфс практически не рассыпается в отличие от практическ, Бывалый смузихлёб (?), 13:10 , 10-Дек-23, (80) –8

Развалиться может что угодно - но в btrfs чаще всего предупреждение о проблемах , Аноним (-), 14:17 , 10-Дек-23, (109) +2
Советую почитать форум Synology на предмет стабильности BRTFS очень советую, ну, Олег (??), 01:16 , 17-Дек-23, (263)

Миллионы пользователей ChromeBook резко удивились, что оказывается у них все каж, Всем Анонимам Аноним (?), 13:19 , 10-Дек-23, (86)

Слегка не так Slight correction we use btrfs for the disk image backing the us, Аноним (151), 17:27 , 10-Дек-23, (151) +2
А что эти все делают и почему они вдруг в единственном числе , Анонимский (?), 22:54 , 10-Дек-23, (189) –1

Может прекратить жить по модели бабки, разносящей не проверенные слухи, лишь бы , 128557 (?), 14:09 , 10-Дек-23, (104) –2

сказала бабка, Аноним (120), 14:42 , 10-Дек-23, (120) +7
Но если где то повредилось пару байт и crc32 не хватает скорректировать ошибку,е, maximnik0 (?), 16:10 , 10-Дек-23, (139)

Люблю экспертов опеннета, всегда блеснут экспертизой 1 CRC32 - вообще не код , Аноним (153), 17:41 , 10-Дек-23, (153) +1

xxhash64 в плане коллизий вполне надежен, он не криптографический, т е не имеет, penetrator (?), 17:53 , 10-Дек-23, (158)

Ну дык можно вот его Если кому совсем нечего делать, -dev версии btrfs-tools ум, Аноним (153), 17:56 , 10-Дек-23, (160)

Ты с ней побывал почти в каждой новости о файловых системах Учитывайте, что зде, Аноним (165), 18:37 , 10-Дек-23, (165) +3

1 Мне все время рассказывают страшилки как я потеряю данные и проч Уже какой т, Аноним (-), 20:52 , 11-Дек-23, (237)

На бумаге по Btrfs все хорошо, на деле же там уже сами разработчики не ориентиру, Аноним (195), 23:55 , 10-Дек-23, (195) +1

Извольте-ка пруф на это храброе заявление предоставить На ваше несчастье я этих, Аноним (-), 21:03 , 11-Дек-23, (238)

Можно использовать для коррекции ошибок Как я помню один из видов crc32 может об, maximnik0 (?), 04:50 , 11-Дек-23, (209)

При сильном желании и SHA256 - код коррекции ошибок Вот вам блок с эн левых бит, Аноним (240), 21:43 , 11-Дек-23, (240)

вообще-то иногда и коррекции только никто в мире не умеет ее правильно применят, нах. (?), 09:35 , 11-Дек-23, (215)

Да я смогу и какимнить SHA256 например 1-бит ошибку замахать Но по мере роста ч, Аноним (240), 22:50 , 11-Дек-23, (244)

все же щупал однокурсницу - практическое - kernel panic при попытке прочитать п, нах. (?), 09:50 , 12-Дек-23, (251)

Все чуть хитрее Большую часть актуальных знаний по IT vs алго я получил путем ш, Аноним (240), 19:04 , 12-Дек-23, (253)

боюсь что это уровень заборостроительного факультета Я там вопрос задал - что н, нах. (?), 19:51 , 12-Дек-23, (255)

Меня интересуют практические применения и детали реализации Я этим пользуюс, Аноним (265), 06:23 , 19-Дек-23, (265)

Там даже конвертор EXT4 - btrfs есть Но вот это - таки не рекомендуется Это р, Аноним (153), 17:53 , 10-Дек-23, (159)

блжад, да в каком месте у вас хоть изредка бывает не так , нах. (?), 09:23 , 11-Дек-23, (213)

Чудак Файлуха при этом врапает себя в свободное место имевшейся ФС 1 Это довол, Аноним (240), 21:52 , 11-Дек-23, (242)

для fs рекламируемая фича которой безобидное увеличение на ходу - не говоря уже , нах. (?), 09:53 , 12-Дек-23, (252)

ПЦ какой-то - по сравнению с чем А кто еще умеет вообще внутрь себя врапать , Аноним (240), 19:41 , 12-Дек-23, (254)

отмены в какой момент И что будет если управляющие структуры лежат по одинаковы, нах. (?), 20:07 , 12-Дек-23, (256)

IIRC пока не снесен subvol с файлом-образом старой ФС Забавная абстракция, а , Аноним (265), 05:59 , 19-Дек-23, (264)

откати ядро , старые из реп не исчезли, Аноним (6), 11:36 , 10-Дек-23, (6) +2

Даже ничего откатывать не надо В Debian легко можно загрузиться с предыдущим яд, Аноним (50), 12:26 , 10-Дек-23, (50) +3

Это если за консолькой сидеть в момент загрузки и ручками выбирать ядро в грубе , Аноним (73), 12:50 , 10-Дек-23, (73) +1

В etc default grub можно попробовать покрутить параметр GRUB_DEFAULT только по, Твайлайт Спаркл (ok), 12:55 , 10-Дек-23, (75) +2

А разве там не systemd-boot по умолчанию , Аноним (102), 13:55 , 10-Дек-23, (102)

В дебиане то GRUB там самый обычный , Аноним (153), 17:47 , 10-Дек-23, (154)

Самый необычный Пропатченный гигантcкими листингами на Си, не проходившими код-, Аноним (167), 18:49 , 10-Дек-23, (167) +1

И этот великолепный господин конечно же предоставит к ознакомлению портянку с ба, Джентельмен Шоу (?), 23:09 , 10-Дек-23, (190)
Нельзя ли пруфануть это все И как насчет URL CVE А так сабж тоже специфичен для, Аноним (240), 22:54 , 11-Дек-23, (245)

А если вместо grub а используется boot efi , 128557 (?), 14:11 , 10-Дек-23, (105)

То человек должен уже знать, что делает, Мимосисадмин (?), 15:24 , 10-Дек-23, (126) +1

Перезагрузитесь с использованием более раннего ядра, дебиан сохраняет 3 версии я, Аноним (10), 11:40 , 10-Дек-23, (10) +4

6 1 0-13-amd64 1 SMP PREEMPT_DYNAMIC Debian 6 1 55-1 2023-09-29 А версия 6 1 0, Твайлайт Спаркл (ok), 12:53 , 10-Дек-23, (74)

Да, именно эта забагованная , Аноним (79), 13:09 , 10-Дек-23, (79) +2

Спасибо , Твайлайт Спаркл (ok), 13:28 , 10-Дек-23, (91)

Ты пакеты не разу не откатывал что-ли Посмотри в апт логе старые версии пакетов, Вы забыли заполнить поле Name (?), 11:42 , 10-Дек-23, (12)
Страдать 175 _ 12484 _ 175 , Аноним (38), 12:13 , 10-Дек-23, (38) +2
Пользоваться Эти мэйнтенеры всё равно ничего не понимают К тому же каждый поль, Аноним (83), 13:12 , 10-Дек-23, (83) +1

Только вот пользователям рачика это давным-давно починили, а они и не заметили , НяшМяш (ok), 13:36 , 10-Дек-23, (93) –2

Вооюще-то как раз заметили - и не выкатили провальный релиз , Аноним (153), 17:49 , 10-Дек-23, (155)
все равно каждый день переставляют, а прона нового всегда можно накачать а этим , нах. (?), 09:38 , 11-Дек-23, (216)

Обновление ядра с исправлением уже прилетело, Андрей04091977 (ok), 01:26 , 11-Дек-23, (199)
Тоже поставил 14 версию , а потом еще накатил последнюю 15 и после этого апгрейд, Cimeries (?), 21:21 , 12-Дек-23, (259) +1

Оперативно Буквально за день после релиза заметили Заметил сегодня из-за ошибо, Аноним (3), 11:32 , 10-Дек-23, (3) –1

В репах лежит уже новое ядро, пофиксенное , Аноним (185), 22:19 , 10-Дек-23, (185)

Скрыто модератором, нах. (?), 11:33 , 10-Дек-23, (4) –19

Скрыто модератором, Аноним (3), 11:45 , 10-Дек-23, (16) +3
Скрыто модератором, Аноним (153), 17:51 , 10-Дек-23, (156)

Скрыто модератором, нах. (?), 19:09 , 10-Дек-23, (169) –2

Скрыто модератором, Don Perignon (?), 03:07 , 11-Дек-23, (205)

Скрыто модератором, нах. (?), 09:22 , 11-Дек-23, (212)

Надо честно признать линукс себя изжил Пора дебиану на Illumos переходить , Аноним (29), 11:37 , 10-Дек-23, (7) –19

Это не Линукс себя изжил, это дебиан себя изжил Перейти на Illumos и своими про, Аноним (102), 14:09 , 10-Дек-23, (103) –4
Ну дык, с 91 года пилится Как и иксы, код -- лютое устаревшее хауно, си-портянк, Аноним (106), 14:14 , 10-Дек-23, (106) –1

systemd тоже на Си написан, причем написан плохо, Аноним (119), 14:42 , 10-Дек-23, (119) +1

Воот, надо на расте переписать в стиле вейланда, чтоб каждый сервис сам себя зап, Аноним (106), 17:12 , 10-Дек-23, (146) +2

Вэйланд тоже на си блин, хотя для фанов раста запилить реализацию на этом - таки, Аноним (153), 17:52 , 10-Дек-23, (157)

вейланд написан на английском, это протокол , emdash (?), 00:11 , 11-Дек-23, (196) +2

Есть реализация не на Си , Аноним (201), 02:00 , 11-Дек-23, (201)

Да, ПомидорИзДолины (?), 02:25 , 11-Дек-23, (204)
https github com Smithay smithay , Аноним (262), 19:58 , 15-Дек-23, (262)

заменить на обычные портянки с сапогами, сразу дурь выйдёт, Аноним (120), 14:45 , 10-Дек-23, (121)

Рано или поздно Linux сойдёт на нет, уступив место академическим Unix , 128557 (?), 14:15 , 10-Дек-23, (107) +2

В этом месте должна звучать классическая рождественская песня O, Tannenbaum У, Аноним (148), 17:21 , 10-Дек-23, (148) +4
Академическим Unix давно уже пора на пенсию, борода до пола выросла , Neon (??), 05:39 , 11-Дек-23, (210) +1

Это ты с ZZ Top попутал , 1 (??), 09:24 , 11-Дек-23, (214) +2

Ставлю на Иллинойс , Пряник (?), 15:34 , 11-Дек-23, (229)

Ну это просто днище, господа Мало того, что стабильно ядро дырявое, так еще и в, Аноним (8), 11:39 , 10-Дек-23, (8) +1

btrfs стала надежнее ext4 это в каком выдуманном мирке , Alladin (?), 11:43 , 10-Дек-23, (13) +8

Чувак, ты это пишешь буквально в теме про баг в ext4 , Шарп (ok), 11:50 , 10-Дек-23, (20) +2

Если он каждый раз будет писать это в теме про баг BTRFS - ты утонешь в его сооб, Аноним (38), 12:15 , 10-Дек-23, (40) +8

Проснись, BTRFS очень стабильна , 128557 (?), 14:18 , 10-Дек-23, (110) –2

Ты в changelog и ядра хоть раз заглядывал , Wizard160888 (?), 14:31 , 10-Дек-23, (114)

Так там во всех файлухах баги чинят Btrfs на данный момент не выглядит страшнее, Аноним (240), 22:58 , 11-Дек-23, (246) –1

Если да , то вопрос Не страшно , Wizard160888 (?), 14:34 , 10-Дек-23, (116)

он смел и отважен, а прона, случись что, нового накачает , нах. (?), 19:10 , 10-Дек-23, (170)

Вы там уже прочекали свои копии копий на предмет разрушения, эксперты Btrfs , Аноним (240), 23:00 , 11-Дек-23, (247)

ага, не грузит - просто в один непрекрасный момент mount отвечает error, а чего , нах. (?), 01:05 , 12-Дек-23, (249)

1 Ну вообще-то обычно - монтируется, если не идиотничать 2 Прочитать, внезапно, Аноним (240), 12:56 , 15-Дек-23, (261)

Стабильна в невосстановимых поверждениях в любой неожиданной для разработчиков с, Аноним (178), 21:17 , 10-Дек-23, (178) +1

насколько я понимаю - в случае ее raid6 можно сэкономить деньги и время - никому, нах. (?), 01:06 , 12-Дек-23, (250)

А при zfs у тебя ничего и не восстановишь, КО (?), 14:36 , 10-Дек-23, (117)
Сейчас закоммичу в btrfs баг и продолжим разговор , Пряник (?), 15:36 , 11-Дек-23, (230)

Допатчились Вот причина, почему все deb based имеют некую шизу - что-то тупит , Аноним (11), 11:41 , 10-Дек-23, (11)

Но это не точно, Вы забыли заполнить поле Name (?), 11:44 , 10-Дек-23, (15) +4

make -j nproc bindeb-pkg, Аноним (17), 11:47 , 10-Дек-23, (17)
Невероятно Диды сначала запутались в O_SYNC, потом шлифанули потерей данных, а , Шарп (ok), 11:48 , 10-Дек-23, (18) +5

Поправил, Аноним (23), 11:52 , 10-Дек-23, (23) +8

Нтфс рассыпалась куда чаще надо заметить, а баги весьма эпические с разносом суп, Аноним (43), 12:21 , 10-Дек-23, (43) +3

И мне особенно нравятся неудаляемые файлы в ней В некоторых случаях не поможет , Аноним (43), 12:25 , 10-Дек-23, (48) +1

Такие файлы удавалось удалить в Far кто-то объяснял это тем, что в Far работа с, Аноним (173), 19:56 , 10-Дек-23, (173)

Far умеет работать с UNC Возможно, с этим связано , Аноним (23), 23:13 , 10-Дек-23, (191)

За всю мою практику рассыпалась один раз, и то сам виноват 8212 битый IDE-каб, Аноним (23), 14:50 , 10-Дек-23, (122)

За 10 лет раз 5 устраняли баг с разносом при исчерпании места, и это только то, , Аноним (43), 15:05 , 10-Дек-23, (123)

Ваша хваленая ntfs просто обнулила размер мне некоторых файлов после миграции с , Аноним (136), 15:57 , 10-Дек-23, (136)

так она не наша, Аноним (164), 18:22 , 10-Дек-23, (164)

У ext4 пока баги из разряда забей , когда у остальных там что-то опасное было , Аноним (43), 12:08 , 10-Дек-23, (35)
BTRFS и адекватная в одном предложении Смешно По серьёзке - у меня BTRFS раз, Аноним (38), 12:20 , 10-Дек-23, (42) +5

За несколько лет использования Btrfs на нескольких HDD-дисках сталкивался только, Аноним (167), 19:18 , 10-Дек-23, (171) –4
Выпрями руки У меня с 2018 года на 2 ноутах btrfs, система установлена, работа, Андрей (??), 22:35 , 10-Дек-23, (187) –3

Ну что ты паришь Ты даже сам сидишь на NTFS , Аноним (56), 12:30 , 10-Дек-23, (56) –2

поди что плохое , нах. (?), 13:40 , 10-Дек-23, (98) +1

А начал как-будто хочешь про безопасный язык задвинуть , Вы забыли заполнить поле Name (?), 12:47 , 10-Дек-23, (68) +1
btrfs обсирается регулярно, судя по линукс-форумам а фанатики бегают и орут что, voiceofreason (?), 11:59 , 21-Дек-23, (266)

Вообще новость - ахтунг Разработчики ядра накатили на стабильную версию ядра па, Аноним (10), 11:49 , 10-Дек-23, (19) +7

Олдстейбл теперь новый стейбл, Аноним (8), 11:51 , 10-Дек-23, (21) +4

Видимо, да , Аноним (10), 11:53 , 10-Дек-23, (24)

Тебя ещё больше открытий ждёт Рановато тебе в аналитику лезть, поднаберись опыт, Аноним (43), 12:10 , 10-Дек-23, (36) –3

Ваше мнение очень важно для нас Пожалуйста, не вешайте трубку , Аноним (10), 12:31 , 10-Дек-23, (57)

Обязательно держи в курсе чьё мнение важно для вас , Аноним (56), 12:34 , 10-Дек-23, (59) –1

А ты подпишись на рассылку, и узнаешь первым Как маленький, ей-богу , Аноним (10), 12:36 , 10-Дек-23, (61)

Ты зато как старенький Кому нужны ваши рассылки - в мире, где изобрели твиттор,, Аноним (198), 00:45 , 11-Дек-23, (198)

Ты зашёл на форум компьютерщиков и имеешь что-то против автоматизации рутинных о, Аноним (79), 02:01 , 11-Дек-23, (202)

Зато мне в новостях про Федору любители дебиана и его убунту-тестинга на десктоп, FF (?), 12:44 , 10-Дек-23, (66)

я о том, что мейтейны бэкпортируют всякие не поддерживаемые межмажорные релизы,, FF (?), 12:46 , 10-Дек-23, (67)

Это нормальная ситуация - если что-то считается сверхнадёжным, то рано или поздн, Аноним (79), 13:02 , 10-Дек-23, (77)

обычное дело, ты, видимо, недавно с компьютерами познакомилсяо сколько нам откры, Аноним (43), 12:05 , 10-Дек-23, (33) +1
Ну, если ты обновляешься немедленно после выхода мажорной версии - ты должен пре, Аноним (38), 12:24 , 10-Дек-23, (46) –4

Это минорный апдейт , Аноним (54), 12:29 , 10-Дек-23, (54)
Ты вообще читаешь, что написано , Аноним (10), 12:47 , 10-Дек-23, (69) +1

Диванный теоретик Отозвали , Аноним (3), 13:20 , 10-Дек-23, (87)

Скрыто модератором, Аноним (79), 13:28 , 10-Дек-23, (90)
Ошб 1 https deb debian org debian bookworm main amd64 linux-image-6 1 0-14-amd, Аноним (3), 13:35 , 10-Дек-23, (92) +1

Тогда хорошо, а то я обновляться на эту версию не пытался Раньше она была в pro, Аноним (79), 13:39 , 10-Дек-23, (97)
Ещё несколько часов назад спокойно обновлялось, хотя новость от вчера Такое , Аноним (54), 13:51 , 10-Дек-23, (100) +1

Я четыре часа назад обновлять пытался Результат в логе выше , Аноним (3), 15:36 , 10-Дек-23, (128)

Не спорьте - у дебиан куча зеркал, где раньше синхронизировали, где позже, Аноним (73), 16:39 , 10-Дек-23, (142) +2

bookworm stable kernel ядро Linux для 64-разрядных персональных компьютеров, Аноним (200), 01:29 , 11-Дек-23, (200)

Да, уже несколько часов известно, что баг пофиксили , Аноним (79), 02:02 , 11-Дек-23, (203)

Причем все дерьмо теперь льется на дебиан Вся вина которых что они взяли ядро , Аноним (148), 15:38 , 10-Дек-23, (129) +1

Ну так почему-то дебиан воспринимается некоторыми не как арч с его собирается, , Аноним (43), 15:47 , 10-Дек-23, (131)
самое короткое изложение проблемы взято https lwn net Articles 954285 - Stab, Аноним (148), 16:55 , 10-Дек-23, (143) +2

А на примере с Winodows Microsoft бы в первую очередь выпустила, а потом отложи, Аноним (22), 11:52 , 10-Дек-23, (22)
Спасибо, чуваки Чую, неделя будет интересной , Аноним (54), 11:54 , 10-Дек-23, (25) +3
Самый стабильный дистрибутив, Алексей (??), 12:04 , 10-Дек-23, (32) –1

Именно В рачах с бомжарами багованное ядро провисело несколько дней и никто даж, Аноним (50), 12:28 , 10-Дек-23, (53) –2

Когда у тебя постоянно что-то отваливается, на такие мелочи не обращаешь внимани, Вы забыли заполнить поле Name (?), 12:50 , 10-Дек-23, (72) +2

Вот и я о том же То что в Debian - ЧП, в других дистрибутивах обыденность , Аноним (50), 13:22 , 10-Дек-23, (88) +2

Да не обыденность, просто меньше косяков - вот и меньше про них пишут Там ещё ок, Михалков (?), 15:49 , 10-Дек-23, (132) –2

Стабильность -- понятие относительное По сравнению с остальными дистрибутивам, Аноним (29), 12:30 , 10-Дек-23, (55)

Как там этот ваш Преображенский говорил Не понимаю, кто на ком стоял Кто что , freehck (ok), 12:12 , 10-Дек-23, (37) +4

те кто понимают чего чего-чего - ext4 - не являются авторами новости, вероя, нах. (?), 19:07 , 10-Дек-23, (168)
Из 6 5 криво набэкпортировали в 6 1 В результате 6 1 64 и 6 1 65 пользовать нел, Аноним (211), 07:00 , 11-Дек-23, (211)

Никогда не было - и вот опять Код файловых систем неплохо бы изолировать от ОС, Аноним (41), 12:16 , 10-Дек-23, (41) –1

Хорошо что ты заговорил про микроядро , Аноним (56), 12:27 , 10-Дек-23, (51)

Никто не говорит про микроядро Я заговорил о API и желательно ABI-совместимости, Аноним (63), 12:37 , 10-Дек-23, (63) +1

лог не пробовали посмотреть https git kernel org pub scm linux kernel git sta, Аноним (45), 12:23 , 10-Дек-23, (45)
Через какое-то время Мы прекращаем сборку дебиан потому что у нас что-то не пол, Аноним (56), 12:25 , 10-Дек-23, (49) +3

Грег бросает ядро линукс и переходит на гну хурд тогда уж , Аноним (54), 12:34 , 10-Дек-23, (58) +1

В майкрософт, Вы забыли заполнить поле Name (?), 12:49 , 10-Дек-23, (71) +5

если честно, то можно и на 11м и на 10м сидеть и все будет в норме пакетов на , Аноним (22), 12:34 , 10-Дек-23, (60) +1

как хорошо что у мя хомяк на ext3, Аноним (64), 12:38 , 10-Дек-23, (64)

И четвёртое ядро , я (?), 13:51 , 10-Дек-23, (101)

черт а как ты догадался У меня LTS, который на поддержке , Аноним (64), 18:22 , 10-Дек-23, (163)

У альтовцев просто пишут,что ext 2-3,а оно там явно 4 , Аноним (108), 14:17 , 10-Дек-23, (108)

uname -aLinux devuan 5 15 142 1 SMP Sun May 1 12 00 00 CEST 2011 x86_64 GNU L, glad_valakas (?), 12:39 , 10-Дек-23, (65) –1

Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..., Вы забыли заполнить поле Name (?), 12:48 , 10-Дек-23, (70)
https git kernel org pub scm linux kernel git stable linux git log h v5 15 14, Аноним (45), 12:56 , 10-Дек-23, (76)

Писали же что ребята на переносах выдыхаются Чтобы так бекпортировать между в, Аноним (78), 13:04 , 10-Дек-23, (78) +1
Опять direct i o поломали , Tron is Whistling (?), 13:10 , 10-Дек-23, (81)
Вот поэтому я никогда и не обновляю ядро, какое было на iso такое и стоит годами, Аноним (82), 13:12 , 10-Дек-23, (82)

fat в ro на керамике веками проработает без сбоев, Аноним (45), 13:23 , 10-Дек-23, (89) +1

fat -грязная проприетарщина mount dev root on type ext2 ro,noatime как-т, Аноним (241), 21:52 , 11-Дек-23, (241)

непонятноскорее всегоАхахаЛинукс, Аноним (82), 13:16 , 10-Дек-23, (84) +2

all stable kernels that have 91562895f803 ext4 properly sync file size update, Аноним (-), 17:02 , 10-Дек-23, (145)

А я уже упоминал об этой проблеме с ядром 6 5 и замиранием системы в Endless OS , pic (?), 13:36 , 10-Дек-23, (94)

Ну вот и правильно, релиз Endless OS 5 1 с _проблемным ядром 6 5_ отключен для о, pic (?), 15:39 , 10-Дек-23, (130)

Ну и как так вышло, что в типа самом стабильном дистрибутиве косяки уровня ролли, Аноним (96), 13:37 , 10-Дек-23, (96) –1

Разогнались Проще говоря один раз отмерили и семь раз сделали , Аноним (22), 13:43 , 10-Дек-23, (99) –1
Задайте свой вопрос на kernel org, Аноним (135), 15:54 , 10-Дек-23, (135)

Делать стэйбл версию, чтобы в неё переносить некритичные патчи из анстэйбл, гени, КО (?), 14:34 , 10-Дек-23, (115) +1

По логике всё это надо было пихать опционально в backports-репозиторий , pic (?), 15:30 , 10-Дек-23, (127)

Еще раз - бэкпортили разработчики ядра, из 6 5 в 6 1, который отличается длитель, Аноним (148), 16:06 , 10-Дек-23, (138) +2

Не усмотрел что релизе Debian 12 состоялся с ядром 6 1, как-то экстраполировал D, pic (?), 18:01 , 10-Дек-23, (161)

Вот они, любители бэкпортировать во всей красе , Аноним (120), 14:41 , 10-Дек-23, (118)
Горшочек вари В свое время намучился переустановками ос из-за обновлений и пл, Аноним (124), 15:12 , 10-Дек-23, (124) –1
Там ещё окаменелый софт со времён помёта мамонта Даже в этих условиях у кого-, Михалков (?), 15:50 , 10-Дек-23, (134) –2
Лучше бы дизайн нормальный нарисовали и выбрали один тулкит за стандарт, выброси, Аноним (150), 17:26 , 10-Дек-23, (150)

Нормальный дизайн давно нарисован - это win95-подобные схемы , Аноним (236), 19:01 , 11-Дек-23, (236)

О, а я-то думал почему у меня при апгрейде E Failed to fetch 403 Access den, Аноним (162), 18:17 , 10-Дек-23, (162)
Но зачем они притащили это в Debian стабильный, вот в чем вопрос Кто виновен в , Вася (??), 18:47 , 10-Дек-23, (166) –3
Установлен LMDE 6, uname -a показывает именно 6 1 0-14 Что теперь делать А как, Аноним (172), 19:26 , 10-Дек-23, (172)

См выше https www opennet ru opennews art shtml num 60261 138, Аноним (173), 20:07 , 10-Дек-23, (174)
Читать Чернышевского и Ленина э-э-э Перезагрузиться в более раннюю, незаба, Аноним (79), 20:12 , 10-Дек-23, (175) +1

И чем 5 15 не угодила , nox. (?), 22:13 , 10-Дек-23, (184)

А где в bookworm е версия 5 15 , Аноним (79), 22:40 , 10-Дек-23, (188)

Смысле, что делать Загрузиться в предыдущую версию и ждать фикса Или вы из тех, Джентельмен Шоу (?), 03:31 , 11-Дек-23, (207)

У меня после обновления ядра домашний сервачок в осадок выпал Пришлось ставить , Аноним (176), 20:22 , 10-Дек-23, (176) +2
И зачем нужны эти жалкие надстройки над EXT2 Почему бы просто не перейти на отве, Шишкин (?), 20:51 , 10-Дек-23, (177) +1

Везде стоит ext2, она намного быстрее чем ext4 , Аноним (179), 21:22 , 10-Дек-23, (179)
Дай набойчик на док где взять reiser5 и как потом применить , Аноним (192), 23:14 , 10-Дек-23, (192)

Пофиксили, пришла обнова на 6 1 0-15 , eugener (ok), 21:47 , 10-Дек-23, (180)

да, так и есть обновил деб на втором ноуте, полёт норм , dannyD (?), 23:27 , 10-Дек-23, (194)

Версия 6 6 6 на подходе Это знамения , Аноним (181), 21:52 , 10-Дек-23, (181) –1

Последние времена настают, Аноним (79), 22:09 , 10-Дек-23, (182)

Всё ближе к демонам из FreeBSD , Аноним (192), 23:16 , 10-Дек-23, (193)

Так ставь на Ext3 , nox. (?), 22:12 , 10-Дек-23, (183) –1

у тебя ж ntfs , нах. (?), 12:52 , 11-Дек-23, (226)

Всего у меня в работе 4 компьютера ноутбуком что-то перестал пользоваться На , nox. (?), 14:06 , 13-Дек-23, (260)

Но ведь сложность развесистых веток git оправдана как раз тем, что там не нужно , Аноним (186), 22:25 , 10-Дек-23, (186)

Кстати, там что-то типа https www atlassian com git tutorials comparing-workfl, Аноним (186), 15:43 , 11-Дек-23, (232)

Debian стабильность, говорили они, и вот тебе на в стабильном дистрибутиве на , Аноним (197), 00:15 , 11-Дек-23, (197) –1

Как достали дебилы, кричащие про протухшее ПО в Дебиане Хочется поновее - испол, Аноним (206), 03:13 , 11-Дек-23, (206) +1

Но ведь testing или unstable вместе с новым ПО получают ещё большую нестабильнос, Аноним (197), 12:03 , 11-Дек-23, (222)

А то что этот баг появился сперва в апстриме, в стабильной же версии ядра, мы ск, Аноним (208), 03:34 , 11-Дек-23, (208) +1

что интересно - там ДВА бага Первый - тот что без особого шума был исправлен в , нах. (?), 09:40 , 11-Дек-23, (217)

Ну так в чем я не прав, пока нормальные дистрибутивы получили нормальный свежий , Аноним (197), 12:11 , 11-Дек-23, (224)

нормальный свежий патч получить могли только любители сидеть на свеженьком тол, нах. (?), 12:51 , 11-Дек-23, (225)

Демагогия , Аноним (197), 18:11 , 11-Дек-23, (235)

Ну смысл в том что Debian должен был не попасть в просак из за особенностей его , Аноним (197), 12:09 , 11-Дек-23, (223)

две сохраняет если не чистить apt autoremove , Аноним (219), 09:55 , 11-Дек-23, (219)
Прекрасно по тексту таки непонятно --- это в kernel проблема или debian овском , yet another anonymous (?), 14:05 , 11-Дек-23, (227)

Перечитай первую строкуПроблема в ядре А разрабы Debian её заметили Но поздно , Пряник (?), 15:42 , 11-Дек-23, (231)

Дебиановский workflow во всй красе ни одного прямого указания на коммит в ядре , yet another anonymous (?), 23:14 , 11-Дек-23, (248)

они отгружают архив с kernel org, внезапно Без всякого понятия где и чьи там ко, нах. (?), 20:17 , 12-Дек-23, (258)

Debian помогает искать баги в Linux , Пряник (?), 15:31 , 11-Дек-23, (228) +1
Версия ядра 6 6 6 вышла Страшно конпелять , Аноним (181), 15:47 , 11-Дек-23, (233) +1
Тысяча чертей Как можно было накосячить в коде ext4 Майки уволили криворуких ин, Минона (ok), 22:33 , 11-Дек-23, (243)

google silent data corruption ext4 ext3, ext2 впрочем о мертвых гугль обычно, нах. (?), 20:14 , 12-Дек-23, (257)

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

1. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (1), 10-Дек-23, 11:30

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

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

5. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Аноним (5), 10-Дек-23, 11:33

Мигрируй на бтрфс

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

29. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +5 +/–

Сообщение от Аноним (29), 10-Дек-23, 12:00

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

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

80. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." –8 +/–

Сообщение от Бывалый смузихлёб (?), 10-Дек-23, 13:10

посоны поговаривают что бтрфс практически не рассыпается в отличие от практически не восстановимых при сбое ФС семейства экст№

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

109. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +2 +/–

Сообщение от Аноним (-), 10-Дек-23, 14:17

> посоны поговаривают что бтрфс практически не рассыпается в
> отличие от практически не восстановимых при сбое ФС семейства экст№
Развалиться может что угодно - но в btrfs чаще всего предупреждение о проблемах все же есть сильно заранее, если системные логи мониторить хоть немного. А ext4 все пофиг, до того момента как объем факапа не нагнет все к чертям.

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

263. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Олег (??), 17-Дек-23, 01:16

Советую почитать форум Synology на предмет стабильности BRTFS) очень советую, ну это как пример сообщества активного BRTFS, других уж не знаю....
Разрушить ext еще постараться нужно, что не скажешь про кучу внутренних болячек BRTFS
Вместо BRTFS лучше бы ZFS упомянули....
Вообще непонимаю что сподвигает людей всместо ZFS выбирать эксперементальный BRTFS, внедряли бы сразу уж Riserfs 5, фишек тоже тьма и с стабильностью так понимаю -+ также

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

86. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Всем Анонимам Аноним (?), 10-Дек-23, 13:19

Миллионы пользователей ChromeBook резко удивились, что оказывается у них все каждый день рассыпается

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

151. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +2 +/–

Сообщение от Аноним (151), 10-Дек-23, 17:27

Слегка не так
"Slight correction: we use btrfs for the disk image backing the user's crostini state only. The rest of Chrome OS, and the crostini VM rootfs, still use ext4."

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

189. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." –1 +/–

Сообщение от Анонимский (?), 10-Дек-23, 22:54

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

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

104. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." –2 +/–

Сообщение от 128557 (?), 10-Дек-23, 14:09

Может прекратить жить по модели бабки, разносящей не проверенные слухи, лишь бы обратили внимание?
BTRFS хороша и стабильна.

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

120. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +7 +/–

Сообщение от Аноним (120), 10-Дек-23, 14:42

сказала бабка

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

139. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от maximnik0 (?), 10-Дек-23, 16:10

>BTRFS хороша и стабильна.
Но если где то повредилось пару байт и crc32 не хватает скорректировать ошибку,есть не хилый шанс не починить фс.Реально, средства проверки падают и хрен что сделаешь кроме отката.Это что за фс где из за одного файла вся фс в расскарячку становится :-( Я не спорю, сейчас гораздо она стала стабильный, и быстрей,уже детских ошибок нет,(по крайней мере приделали рабочий костыль_это я про дополнительное место для метаданных) но отсутствие рабочего fsck уже достало...
Хорошо хоть все данные можно выципить.
(Но очередь записи в схеме жёсткий диск + Флэш память у btrfs хороша,такого конечно в ехт4 нету и хрен сделаешь....)

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

153. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Аноним (153), 10-Дек-23, 17:41

>>BTRFS хороша и стабильна.
> Но если где то повредилось пару байт и crc32 не хватает скорректировать ошибку,
Люблю экспертов опеннета, всегда блеснут экспертизой...
1) CRC32 - вообще не код коррекции ошибок! Ошибка корректируется путем чтения блока из второй копии, внезапно (RAID1/DUP/...). Ну или вычисляется за счет parity (RAID5/6, не рекомендуется, особенно второй).
2) CRC32 довольно хорошо ловит "битовые ошибки" типичные для факапов сторажей и глючного железа.
3) Если CRC32 мало под ваши требования есть xxhash, и даже sha256/blake2s - если надо ну вот реально неубиваемый хеш который хрен словит коллизию даже на петабайтах. Но если у вас хеш стресстестится - это наверное повод задуматься о смене гнилого железа так то.
> есть не хилый шанс не починить фс.
Чинябельность ФС зависит сугубо от наличия 2 копии (или парити) и сойдется ли чексум там. Избыточность с которой можно починиться либо есть, либо нет. Чудес не бывает.
> Реально, средства проверки падают и хрен что сделаешь кроме отката.
Сразу видно эксперта который btrfs видел только на картинке. И то не факт.
> мере приделали рабочий костыль_это я про дополнительное место для метаданных) но
> отсутствие рабочего fsck уже достало...
Для меня это вообще ломовая фича в ситуациях где некому any key жать, оно просто работает, отклонения от идеала - парирует из другой копии. А отвечать на тупые вопросы на встраиваемых системах, да и серверах ВНЕЗАПНО, НЕКОМУ.
Да и вообще - ext4 довольно средняя штука. От бэдов под метаданными вполне может и скопытиться или потерять довольно много данных. Plan B на этот случай - нет. И даже RAID1 в подобной ситуации может и не помочь, особенно если накопитель как сейчас модно вернет труху без отлупа IO error, что конечно подляна - но бывает вот.
> (Но очередь записи в схеме жёсткий диск + Флэш память у btrfs
> хороша,такого конечно в ехт4 нету и хрен сделаешь....)
У EXT4 полное журналирование - капец тормозное. А без этого - он вообще класть хотел что с данными при крахе случится, его интересует только совпадение аллокаций свободного места с файлами, что там внутри файла... а вот что получится то и будет. Данных откатить это или довести до конца транзакцию без полного журнала нет. А с полным журналом - две записи вместо 1 будут. Сперва в журнал - намерения, потом в основной регион.
Btrfs, bcachefs и ко читерят - идея cow в том что по сути журналом становится вся площадь. При этом более не надо переносить из журнала в основную область и вторая запись отпадает. К сожалению, это вызывает нужду в Garbage Collector ибо вечная история записей - все же сожрет место. И иногда надо все же подтирать. Такой подход приколен тем что при записи ничего не портится из существующего. А фикс консистентности делается ... простым игнором недописаного. Этого никогда не было - и все тут. Ведь все данные для предыдущего состояния - на месте. Отсюда и нужда в аллокации места для изменений. К метаданным это тоже применяется. Поэтому на btrfs всегда есть множество альтернативных точек входа для поыптки ре-парсинга. Это будут чуть более старые состояния, но возможно что нужный файл в нужном виде там был, а деревья этого состояния достаточно живые чтобы нужные файлы вынуть.

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

158. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от penetrator (?), 10-Дек-23, 17:53

xxhash64 в плане коллизий вполне надежен, он не криптографический, т.е. не имеет характеристик важных для криптографии и не устойчив к криптографическим аттакам (но ему и не нужно), а вот 64-битного пространства при его характеристиках хватает с запасом, можно посмотреть что отдает по нему SMHasher

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

160. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (153), 10-Дек-23, 17:56

> xxhash64 в плане коллизий вполне надежен, он не криптографический,
> т.е. не имеет характеристик важных для криптографии и не устойчив к криптографическим
> аттакам (но > ему и не нужно), а вот 64-битного пространства при его характеристиках
> хватает с запасом, можно посмотреть что отдает по нему SMHasher
Ну дык можно вот его. Если кому совсем нечего делать, -dev версии btrfs-tools умеют конвертить тип чексум, на отмонтированой ФС. Я с сыпучей флехой поиздевался - оно даже допирает коррекцию сделать при такой конверсии походу, вот уж не ожидал то.
Еще кстати из операций на отмонтированой ФС - bg_tree всячески рулит, особенно на механике, так оно маунтиться начинает быстрее чем даже ext4/bcachefswhatever.

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

165. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +3 +/–

Сообщение от Аноним (165), 10-Дек-23, 18:37

> Я с сыпучей флехой поиздевался
Ты с ней побывал почти в каждой новости о файловых системах. Учитывайте, что здесь btrfs-евангелист с его "накопитель как сейчас модно вернет труху" и закрыванием глаз на баги любимой ФС.

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

237. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (-), 11-Дек-23, 20:52

>> Я с сыпучей флехой поиздевался
> Ты с ней побывал почти в каждой новости о файловых системах. Учитывайте,
> что здесь btrfs-евангелист с его "накопитель как сейчас модно вернет труху"
> и закрыванием глаз на баги любимой ФС.
1) Мне все время рассказывают страшилки как я потеряю данные и проч. Уже какой там по счету год. А они все никак не теряются.
2) Есть ощущение что этот булшит часто ретранслируют кадры которые вон то не видели даже на картинке. А то и вовсе юзеры виндов позорные. Которые так то игнорят проблемы своих фетишей еще активнее, пытаясь даунплеить реально существующие проблемы. Коллекция глюкастиков наловленых btrfs'ом не даст соврать.
3) Я еще и с bcachefs экспериментирую - за примерно то же самое: продвинутый дизайн, обещающий опять же простой и удобный менеджмент :). Так что можете назло бабушке отморозить уши и ничего слаще EXT4 не использовать, кому хуже то?!
А "евангелист" я только потому что мне нравятся продвинутые современные технологии - и крутые эффективные тимы разработчиков. Поэтому считаю несправедлимым тот крап который тут выдают те кто это вообше не юзал, но ценное мнение - имеют. И вообще, EXT4 всяким место на свалке истории. Дизайн который вечно тупит своими директориями которые он отрастить может, а сдуть нет, а то и вовсе налетает на недостаток, блин, инодов - и кладет с прибором на участь данных - это, извините, по современному состоянию дел - таки архаика. Ну как паровоз примерно. Вроде ездит - но желающих это делать вот так будет все меньше.

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

195. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Аноним (195), 10-Дек-23, 23:55

На бумаге по Btrfs все хорошо, на деле же там уже сами разработчики не ориентируются, настолько переусложнена. Там по ходу разработки необходимость менять архитектуру возникала раза так два - изначальная ко всем новым задумкам не подходила. И сейчас они с грехом пополам пытаются усидеть на той самой первоначальной архитектуре, потому что перерабатывать ее уже никто не будет. Это тупиковый путь и тупиковая ФС.

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

238. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (-), 11-Дек-23, 21:03

> На бумаге по Btrfs все хорошо, на деле же там уже сами разработчики не ориентируются,
Извольте-ка пруф на это храброе заявление предоставить? На ваше несчастье я этих разработчиков еще и знаю. И имел опыт взаимодействия с ними. Так что сейчас мы узнаем уровень вашей квалификации. Если не ответите и сольетесь - все понятно.
Я даже могу назвать пару фич которые в разработке. Скажем Extent Tree V2, решающий ряд проблем масштабируемости на очень быстрых сторажах. А мне вот bg_tree очень понравился (since kernel 6.1), время монтирования скостил конкретно, особенно на механике.
> настолько переусложнена. Там по ходу разработки необходимость менять архитектуру
> возникала раза так два - изначальная ко всем новым задумкам не подходила.
А теперь извольте показать - что там в архитектуре радикально поменяли? Желательно еще и с комитами где это случилось. Ща мы тут всех экспертов по полочкам и разложим, ибо дело мастера боится.
> И сейчас они с грехом пополам пытаются усидеть на той самой первоначальной
> архитектуре, потому что перерабатывать ее уже никто не будет. Это тупиковый путь
> и тупиковая ФС.
Если так рассуждать, то по таким стандартам NTFS это окаменелый помет динозавра, EXT4 и XFS - тоже окаменелые фекалии мамонта... а если так посмотреть, то новомодный bcachefs содрал процентов так 85-90 от именно архитектуры, именно btrfs'а. Ну не от вон тех же складов костылей, в самом то деле? И теперь файлухи будут делать - ну вот как-то так. Потому что перспективные паттерны дизайна.
Сложное? Возможно, но эквивалентная этажерка md/dm/lvm/... - еще хуже, и, главное, менеджмент этого всего в том месиве уровней это подный крындец. Либо забить на все продвинутости типа чексумм, снапшотов, райды и прочь - и админить как будто на дворе 80-е прошлого века. Либо познать как выглядит боль. А потом сравнить с вон тем - и попробовать убедить себя использовать те деревянные оглобли еще раз...

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

209. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от maximnik0 (?), 11-Дек-23, 04:50

>CRC32 - вообще не код коррекции ошибок!
Можно использовать для коррекции ошибок.Как я помню один из видов crc32 может обнаружить до 7 однобитных  ошибок для 1024 бит  и надёжно скорректировать 3 из них .Я это к чему-читал я в баг падчах что 1 битную ошибку все таки должен  btrfs-check ремонтировать если я правильно понял перевод.
Теоретическая работа для коррекции 3 битных ошибок -https://translated.turbopages.org/proxy_u/en-ru.ru.56586785-...
Но требует 1,4 Гб места для таблицы перебора.Дальше для исправления возможны коллизии......

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

240. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (240), 11-Дек-23, 21:43

>>CRC32 - вообще не код коррекции ошибок!
> Можно использовать для коррекции ошибок.Как я помню один из видов crc32 может
> обнаружить до 7 однобитных ошибок для 1024 бит и
> надёжно скорректировать 3 из них .
При сильном желании и SHA256 - код коррекции ошибок. Вот вам блок с эн левых битов, и тасуйте биты брутфорсом, пока SHA256 не сойдется! Сколько битов осилите сбрутфорсить, столько и ваше. Но какой-нибудь ридсоломон декодировать сильно быстрее, и починит намного больше. Но как чексум для вот именно валидации содержимого он не такой уж и сильный, рядом с SHA256 не стоял. Если даже некто и сбил автомобилем веротолет - это еще не делает автомобили ПВО.
В btrfs - как минимум в обычном режиме, CRC32 сугубо как чексум и нужен сугубо для валидации прочитаного и единственное что интересует это коллизии, когда нечто левое будет проглочено как валидный блок. А восстановление из избыточной копии. И с вот этой частью механики я малость повозился и даже в стресстесты этого аспекта для тестов умею.
> Я это к чему-читал я в баг падчах
Что сие такое и есть ли у этого урл?
> что 1 битную ошибку все таки должен btrfs-check
Хотелось бы пруфлинк на это дело, чтоли. У меня сорц btrfs-tools если что есть. А так 1 бит и FEC накопителя обычно починит, левай случается когда он неосилил, и там уже что угодно может быть, кто ж знает что фирвар при этом выгружает. Да и идея в том что при избыточности оно self heal само на ходу делает. Прозрачно и без участия юзера. Это еще и ремапу проблемных секторов помогает, фирмваре стоража не надо пыхтеть пытаясь выдернуть нечитаемый сектор. EXT4 при таком будет как дятел ломиться в нечитаемый сектор, а запись туда может никогда и не случиться и ремапа не будет, будет сектор (и файл/метаданные) где всегда затык.
> ошибок -https://translated.turbopages.org/proxy_u/en-ru.ru.56586785-...-
> e6e82254-74722d776562/https/github.com/jeffareid/misc/blob/master/crccor3.c
> Но требует 1,4 Гб места для таблицы перебора.Дальше для исправления возможны коллизии......
Концептуально, конечно, но с такими соотношениями - нахрена оно такое? Показать что автомобилем при очень сильном желании можно сбить вертолет?

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

215. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от нах. (?), 11-Дек-23, 09:35

> Люблю экспертов опеннета, всегда блеснут экспертизой...
> 1) CRC32 - вообще не код коррекции ошибок! Ошибка корректируется путем чтения
вообще-то иногда и коррекции (только никто в мире не умеет ее правильно применять. Если бы ты не щупал однокурсницу на лекции о циклических кодах - ты бы даже знал, какие правильные вопросы надо задать гуглю, это-то даже на ит-факультетах есть. И ты НЕ НАЙДЕШЬ на них ответов. Возможно они есть где-то в документах itu-t доступных по подписке за пару миллионов швейцарских франков, но это неточно.)
> блока из второй копии, внезапно (RAID1/DUP/...). Ну или вычисляется за счет
> parity (RAID5/6, не рекомендуется, особенно второй).
и если нам не повезло - нет второй или обе битые - "всеми щупальцами облизался и спрашивает - и что делать будиииим?!"
Нет, чо, серьезно что-ли у вас Btrfsck не знает что полагается при этом делать?!
> Чинябельность ФС зависит сугубо от наличия 2 копии (или парити) и сойдется
надо же - в ext2 нет никакой второй копии - а починить ее обычно удается.
Забытое умение древних, неповторимый загадочный артефакт (и похоже таки да, забытое).
>> Реально, средства проверки падают и хрен что сделаешь кроме отката.
> Сразу видно эксперта который btrfs видел только на картинке. И то не
если на картинке падают средства проверки - надо найти художника и выколоть ему глазки!
> копии. А отвечать на тупые вопросы на встраиваемых системах, да и
> серверах ВНЕЗАПНО, НЕКОМУ.
внезапно, есть кому. Но на вопрос sigbus ответить кроме пол-второго и нечего.
> Да и вообще - ext4 довольно средняя штука. От бэдов под метаданными
> вполне может и скопытиться или потерять довольно много данных. Plan B
но все реальные случаи - почему-то именно с бырбырфэсе.
> У EXT4 полное журналирование - капец тормозное. А без этого - он
оно предназначалось для очень странного в те годы варианта быстрый журнал + медленный сторадж. Полагаю его 20 лет никто не тестировал и не проверял даже когда он появился.
И оно предназначено вовсе не для защиты от крэша.
> Btrfs, bcachefs и ко читерят - идея cow в том что по
> сути журналом становится вся площадь. При этом более не надо переносить
если не задать себе вдруг вопрос - где начало того конца которым начинаетя начало.
(я, кстати, честно не знаю где у нее и как, знаю про zfs, потому что приходилось чинить. Нет, не свою, помогать другим людям разбирающимся в ней плохо. Нет, не спрашивайте как они доигрались - там все было плохо, не только не разбирались.)
> А фикс консистентности делается ... простым игнором недописаного. Этого никогда не
А теперь представим что это была страничка базы данных и она не совпадает с размером или алайментом блока...

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

244. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (240), 11-Дек-23, 22:50

> вообще-то иногда и коррекции (только никто в мире не умеет ее правильно применять.
Да я смогу и какимнить SHA256 например 1-бит ошибку замахать. Но по мере роста числа битов на брутфорс, наивное "декодирование" станет крайне ресурсоемким.
> Если бы ты не щупал однокурсницу на лекции о циклических кодах - ты бы даже знал,
> какие правильные вопросы надо задать гуглю, это-то даже на ит-факультетах есть.
В контексте btrfs-а меня интересует фактическое поведение self heal как ты понимаешь, а не абстрактные возможности сбития автомобилями вертолетов.
> И ты НЕ НАЙДЕШЬ на них ответов. Возможно они есть где-то в документах itu-t доступных
> по подписке за пару миллионов швейцарских франков, но это неточно.)
Да ну и болт с ним, а? У меня вон там шикарный ридсоломон есть, а вон там "очень странный формат сигнала". Но это к делу не относится. В вон том применении оно сугубо для детектирования ошибок. И есть на выбор несколько других алго для этого.
> и если нам не повезло - нет второй или обе битые -
Я честно говоря такой джекпот даже на сыпучей флехе не выиграл пока. А на более нормальном оборудовании - какая вообще вероятность что у тебя на 2 разных дисках (или даже одном но исправном) сектора не прочтутся? А, это произведение вероятностей? А знаешь, вот так мне теорвер намного больше нравится. Если я вдруг смогу такой джекпот на реалистичных read error rate, числе секторов и проч - я тогда в ЛасВегас заеду, посмотреть что еще я могу.
> "всеми щупальцами облизался и спрашивает - и что делать будиииим?!"
Там для совсем параноиков есть RAID1C3 и даже C4. Если у тебя сразу столько сыпется - это чего? :)
> Нет, чо, серьезно что-ли у вас Btrfsck не знает что полагается при этом делать?!
В этом случае уже без гарантий. А вон там ext4 налетел на бэд под метаданными. Ну и вот чего он смогет? Констатировать что джеппа? Это очень ценно и полезно. И это если еще накопитель вернул io error а не выдал труху, иначе оно могло резко и внезапно скопытиться. Думаешь, CRC на журнал эти кадры от хорошей жизни налепили? Просто реплей кривого журнала - тома замешивает при случае совсем уж в спагетти имени рейзера, прищлось, вот, придумать хоть что-то.
А btrfs даже на 1-девайсовой ФС хранит метаданные как DUP, что очень способствует тому чтобы не узнавать вон то "а что если".
>> Чинябельность ФС зависит сугубо от наличия 2 копии (или парити) и сойдется
> надо же - в ext2 нет никакой второй копии - а починить ее обычно удается.
Агаблин, теорвер решил постебаться - на глаза попался EXT4 с бэдом под метаданными. Не то чтобы он вообще совсем помер - но это out of service и мануальные фиксы и потеря данных.
Прости но мало кто хочет танцевать окучивая локалхост и откребая какие там еще ошметки, гоняя какие там еще fsck (что на современных объемах занимает немеряно времени). Хотят чтобы просто работало. Btrfs это и делает - пока это возможно. А если мануальное внимание надо - это всяко фейл. Ну и говоря за себя - я данные с такой штуки всяко достану, особенно с помощью вон того зала.
> Забытое умение древних, неповторимый загадочный артефакт (и похоже таки да, забытое).
Это как неуловимый Джо. Людям от компьютеров надо чтобы работало. А не чтобы путем заклинаний подымать труп. Если он труп, требующий мануальщины это уже фейл.
Кто мне будет на управляющем одноплатнике жать эникей? И отвечать на вопросы fsck? И на сервере кстати тоже. Да и на десктопе - я проснувшись в каде порисовать собирался, а не с fsck интерфеситься. И вопрос в том какой масштаб задника. Если это 1 бэд в сто лет, DUP его зарулил и на этом все закончилось это одно. Если хардвар осыпается и его надо инить/менять - окей, и чем мне вон то знание древних поможет? Тем что спрячет от меня факап и позволит порушить больше данных?
> если на картинке падают средства проверки - надо найти художника и выколоть
Как там твои средства проверки ZFS'а на тему факапов с копиями копий поживают? Помнится там диагностика проблемы была весьма компромиссным костылем.
> но все реальные случаи - почему-то именно с бырбырфэсе.
Мде? А почему я тогда рекаверил данные с NTFS и EXT4? Если btrfs с умом юзать - он вообще нагибаться ну вот не хочет чего-то. И это... у EXT4 in place запись очень даже деструктивная, в отличие от вон того. Так что если что-то затерлось в EXT4 - это уже совсем навсегда и отменить вообще совсем никак нельзя. Этого физически более нет. А вот в btrfs можно попытаться и выцепить немного более старое состояние если ну вот реально приспичило. Запись же недеструктивана, а GC в общем случае приходит не сразу.
> оно предназначалось для очень странного в те годы варианта быстрый журнал +
> медленный сторадж. Полагаю его 20 лет никто не тестировал и не проверял даже
> когда он появился. И оно предназначено вовсе не для защиты от крэша.
А что мне вообще делать с файлом где новая голова и старый хвост предлагается? Большая часть софта ЭТО жрать не будет. Всякие сжатые форматы словят decode error - и байбай.
> если не задать себе вдруг вопрос - где начало того конца которым начинаетя начало.
У btrfs ответом на него является такая штука как "generation". Оно знает чего хочет (и насколько это актуально) - записи маркированы generation'ом. При серьезных расстыковках не станет маунтиться чтобы не разнести все. Мануально ессно есть ряд опций чтобы все же попытаться заякориться. Но это уже навороты и мануальщина.
> (я, кстати, честно не знаю где у нее и как,
Как минимум generation прописывается довольно много куда. Это нечто типа серийного номера очередного изменения, и по нему видно насколько это то что оно хотело. Если посмотреть логи офлайн вычитывалки и тому подобных продвинутых вещей - там бывает более подробно разрисовано как оно это видит - мол, это блоки такого-то файла, gen такой-то, но мы бы хотели gen такой-то, ищем дальше...
> знаю про zfs, потому что приходилось чинить. Нет, не свою, помогать другим людям
> разбирающимся в ней плохо.
У меня btrfs тоже не разваливался. А другим... ну я вот одному гражданину пул спас, сказав что у него ssd осыпается. Он очень радовался что ему вовремя на факап указали. Btrfs это чинил и еще не осыпался, но по логам было понятно что девайс просится в мусорку.
> А теперь представим что это была страничка базы данных и она не
> совпадает с размером или алайментом блока...
Базы по сути сами наполовину файлухи - и используют свою логику журналинга. Это 1 из причин появления NOCOW. Если кто хотел косплеить ФС, с кастомной семантикой - пусть и косплеит, зачем ему вообше мешать? А делать 1 и ту же работу (журналинг, чексуминг, ...) 2 раза - вообще неоптимально. Если кто хотел фичесет EXT4 - btrfs "до кучи" может это ему дать! Но вообще конкретику ессно смотреть надо. Не тот случай когда универсальные ответы вида "а что будет если" есть.
В целом - ФС оказывается в более старом консистентном состоянии. А БД, если ее писал не совсем кретин, своей семантикой должна форсить сброс буферов и фиксацию на диске данных в критичные для нее моменты. Если оно так делало - по идее семантика сохранится, очевидный минус - синк занимает энное время, так что перфоманс БД на CoW с типовыми паттернами - такое себе. Поэтому там и есть фича прикинуться "а я типа тоже EXT4, вот вам inplace патчинг, все как вы любите".

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

251. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от нах. (?), 12-Дек-23, 09:50

>> вообще-то иногда и коррекции (только никто в мире не умеет ее правильно применять.
> Да я смогу и какимнить SHA256 например 1-бит ошибку замахать.
все же щупал однокурсницу :-(
> В контексте btrfs-а меня интересует фактическое поведение self heal
практическое - kernel panic при попытке прочитать.
> Я честно говоря такой джекпот даже на сыпучей флехе не выиграл пока.
потому что опыт ограничен одной сыпучей флехой. А на деле оно портится в памяти. (поэтому от корректирующего кода действительно ноль пользы)
> А на более нормальном оборудовании - какая вообще вероятность что у тебя на 2 разных дисках (или
> даже одном но исправном) сектора не прочтутся?
э... в реальном случае (один диск сдох совсем, второй из той же партии и того же возраста) - очень даже велика, но еще более вероятно что прочтутся, в обоих мусор, и это кого надо сектор (не данных) и что делать будииим?
> В этом случае уже без гарантий. А вон там ext4 налетел на бэд под метаданными. Ну и вот чего он
> смогет?
смотря что за метаданные и что за бэд (не бывает у меня "бэдов", выкинь уже свою флэшку)
смонтирует аварийно в r/o и будешь выковыривать файлы по одному, обходя поврежденное место, в самом крайнем случае. Но скорее всего fsck восстановит консистентное состояние, потеряешь только то что уже необратимо повреждено.
За ТРИДЦАТЬ с-ка лет что я вожусь с этой хренью - ОДИН раз (и это - спасибо улучшайкерам, была бы там ext2/ext4 без журнала - вообще ничего бы не потерялось) восстановленное fsck оказалось проще выкинуть чем разбираться.
> В целом - ФС оказывается в более старом консистентном состоянии.
спасибо, вон там она оказалась в консистентном, но радости с этого не было никакой.

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

253. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (240), 12-Дек-23, 19:04

> все же щупал однокурсницу :-(
Все чуть хитрее. Большую часть актуальных знаний по IT vs алго я получил путем штудирования лекций CS западных вузов, по частной инициативе, с уклоном в современный state of art и практические применения. Поэтому мои знания имеют уклон в практические кейсы. Я понимаю основы и меня нельзя напугать какой-нибудь "дистанцией хэмминга" или полиномиальной математикой, да даже то что ридасоломон на полях галуа делает.
Тем не менее, я пожалуй признаю что погорячился насчет заяв что CRC совсем не алгоритм коррекции. Некое его применение в этом качестве и правда возможно, так что в этом смысле я пожалуй погорячился.
> практическое - kernel panic при попытке прочитать.
Я что-то сравнимое видел 1 раз. В тестах, с -rc ядрами. На специфичной конфиге. Кредитсы по итогам разбора полетов (да, я впрягся и этого бага с нами уже нет) - ушли господам из mm/ с их рефакторами - реФАКтор вышел. Btrfs-ники виноваты тем что у них вылезло. Наверное и где-то еще, просто "где баг нашелся - там и гасится". Btrfs-ники компетентно и быстро вывели на чистую воду, пнули господ mm/, те резко зафиксили, я через полдня уже вертел патч фиксящий все это великолепие. Подтвердил что трабл починен, комитнули в майнлайн, вот, отлично, релиз не профакапили. Люблю хэппи энд :P.
> потому что опыт ограничен одной сыпучей флехой.
Неа. Еще оно несколько раз вполне успешно парировало редкие рандомные бэды, а еще у меня появилась коллекция глюкастиков - от шнурка до проца. И даже, вот - я ж писал что чуваку с энтерпрайзным ssd пул от разлета спас. А фигли, гад делал примерно то же что и флеха, только активнее. Чувак думал что это баг btrfs. Оказалось - сыпящийся SSDшник. Я понаблюдал, он такой дажеко не 1, лучше всего на это любители bcache (не того который fs) нарываются.
> А на деле оно портится в памяти.
> (поэтому от корректирующего кода действительно ноль пользы)
Прикинь, в моей коллекции есть и несколько битых модулей памяти. И кроме всего прочего - я пользуясь случаем и немного поизучал как именно failure mode выглядит.
Это как-то так: оно обычно видит CSUM error, вопит в лог, читает 2 копию, фиксит. На самом деле это не очень надо было (на стораже данные норм чаще всего), но кроме всего прочего это чинит буфер в RAM и проч, апликухам левак не уходит. Но самое главное - кривой хардвар хайлайтится. Да, вот тут с теорвером уже не стоит в кошки-мышки играть, проиграть однажды уже вполне реально.
Я даже видел пару типов которые такой джекпот выиграли. На самом деле - в "зале" есть пара граждан которые изумительно просекают это, и ор на флипнутый бит в деревьях детектят влет (там есть некий sanity check). И вот тут - если "everything failed" можно гада реально флипнуть хексэдитором, но это для тех кто понимает дизайн и может такие вещи. Актуально только если избыточности ну вот не было, иначе оно само починит метаданные из другой копии, проблема прозрачно аннулируется и никакого хардкора. При том даже на 1-дисковой конфиге оно с неких пор DUP для метаданных делает, послав всех экспертов с "SSD дедублицирует, блаблабла" в пень - real world эксперименты показали что выживаемость ФС с DUP как метаданные - улучшается.
В общем ты имхо недооцениваешь мое любопытство по части странных ситуаций. Но разумеется ВСЕ возможные взбрыки btrfs я не видел и врядли увижу. Да что там, я и все баги EXT4 наизусть не знаю.
> э... в реальном случае (один диск сдох совсем, второй из той же
> партии и того же возраста) - очень даже велика, но еще
> более вероятно что прочтутся, в обоих мусор, и это кого надо сектор (не данных) и что делать будииим?
На практике - таки обычно недурно парирует. Даже, вот, отгрузку трухи протертым энтерпрайзным SSD выживало, чувак думал что это баг btrfs. Пришлось объяснить что это "хана его энтерпрайз SSDшнику", а вовсе не.
> смотря что за метаданные и что за бэд
Ну и с btrfs'ом все примерно так же. Тем более что метаданные почти всегда дублированы. EXT4 так не умеет, однако.
> (не бывает у меня "бэдов",
Угумс. И труху накопители не возвращают. А как ты с нтфс и EXT4 это проверял то?
> выкинь уже свою флэшку)
Зачем? Кому баг, кому фича - теперь это реалистичный стресстест косплеящий вон то, возврат гамна без IO error наверх. Я и кентовскую штуку погоняю так - когда он привинтит некоторые запчасти на место, сейчас это еще малость негуманно.
> смонтирует аварийно в r/o и будешь выковыривать файлы по одному, обходя поврежденное
> место, в самом крайнем случае. Но скорее всего fsck восстановит консистентное
> состояние, потеряешь только то что уже необратимо повреждено.
Вообще оно как бы да, неплохо чинится. Но технически это фейл: функциональность системы была потеряна, потребовалась мануальщина. Мне не надо жигуль с загаром, мне надо чтобы системы - работали. Пока это технически возможно.
> За ТРИДЦАТЬ с-ка лет что я вожусь с этой хренью -
EXT4 явно менее 30 лет...
> ОДИН раз (и это - спасибо улучшайкерам, была бы там ext2/ext4 без
> журнала - вообще ничего бы не потерялось) восстановленное fsck оказалось проще
> выкинуть чем разбираться.
Вот после каких-то таких прецедентов они кроме всего прочего приделали к журналу чексумы. Но между нами - это сейчас как обсуждение проблем джижка ржавых жигулей.
> спасибо, вон там она оказалась в консистентном, но радости с этого не было никакой.
Ну так я о чем. Когда btrfs консистентный, то и данные обычно все же - в юзабельном формате. А базы таки - кастомные зверушки. Ими вообще лучше не заниматься если не понимать основы их механики, журнала, commit/rollback и прочего, иначе горя хлебнуть можно. А если это понимать - окей, можно осмысленно стыковать фичи движка и ФС, не вижу особых проблем. И если кому надо NOCOW - пусть сам и косплеит ФС, от вон того останется только управление местом/аллокацией по сути. Но БД чаще всего именно этого на самом деле и хотели. Они б и на RAW раздел бы, если б не было столько гимора с его администрированием.
А в случае сабжа - баг таки весьма нишевой вышел, бэкпортеры бэк-испортили, и весьма резво заметили :). Это даже не к EXT4 претензия как таковая.

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

255. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от нах. (?), 12-Дек-23, 19:51

> Все чуть хитрее. Большую часть актуальных знаний по IT vs алго я получил путем штудирования
> лекций CS западных вузов
боюсь что это уровень заборостроительного факультета. Я там вопрос задал - что надо спросить у гугля (на что он не ответит или даст только неправильные ответы) про itu-t crc ? Если бы ты нашел ту лекцию которую надо - ты бы знал на него ответ. И если бы тебя всерьез интересовала сохранность данных - ты был бы в ах...е от того на каких соплях и магических ритуалах вместо знаний построены технологии.
> Я понимаю основы
Чувак - основы - это вот рид-соломон. Его вообще никто не понимает, ни одна живая душа. Кроме может быть самих Рида с Соломоном но это неточно и живы ли они - сомнительно, обоим должно быть за 90.
Чортова магия. Непонятная красивая матемагическая загогулина, неприменимая толком ни к какому реальному делу. На CS этому не учат, этому учат на мехмате, и то не всех.
Приложили к делу - некто профессор Планк со ученики (и ученицы, но это тоже неточно). "всего" через 35 лет сумев ту писанину прочитать и придумать как ее употребить.
Через ШЕСТЬ гребаных лет некто по имени Dung заметил ашиппочку. Обмишулились чуток - очень похоже что университетская типография просто листик на пол уронила, или он к предыдущему прилип. Сводящую  все эти шаманские действия банально к х-ю.
Вот это были - практики (ну старались, как могли). А ты - увы, в лучшем случае смог бы - скопипастить. Нет, это тоже не так легко  и просто, и понадобился еще один чувак - некто Peter Anvin. Вот он уже оставил (и до сих пор валяющуюся в недрах kernel.org) внятную инструкцию - бери вот это, помножь вон на то, сложи вот с тем, и получившееся считай своими данными, раз уж часть массива накрылась.
Небольшая проблемка была в том, что он это в первый раз сделал в 2002м году. А Ding нашел отклеившийся листик - в 2003м. Чуешь чем пахнет?
P.S. давай проверим, читал ли ты хотя бы статью тех практиков, или сразу перешел к готовым рецептам. ЧТО в ней самое странное и на самом деле - страшное, в очередной раз вызывающее ужас от соплей на которых построена цивилизация ?

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

265. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (265), 19-Дек-23, 06:23

>> лекций CS западных вузов
> боюсь что это уровень заборостроительного факультета.
Меня интересуют "практические применения" и "детали реализации". Я этим пользуюсь для моих проектов - поэтому в курсе схем с неплохими соотношениями и интересными (мне) свойствами. Часть знаний optimized out, современный мир в 1 голову не лезет.
> Если бы ты нашел ту лекцию которую надо - ты бы знал на него ответ.
У меня ограниченный запас времени + дофига проектов которые я хочу попробовать. И перегруженный знаниями мозг ("фуллстэк" между хардом и софтом пушит меня за лимиты, но это и делает меня мощнее). Поискарь запросами? Только если gain стоит efforts!
Пример: я запустил годный ридсоломон, даже на атмеге голимой ОК, сделав нехилый рефактор (и починив пару вулнов древних). Могу осмысленно параметризовать это (без лекций CS я б нихрена не понял). В паре с "странным форматом сигнала" превзошло самые дикие фантазии. Вон то расширит мои возможности так же?
> И если бы тебя всерьез интересовала сохранность данных - ты был
> бы в ах...е от того на каких соплях и магических ритуалах
> вместо знаний построены технологии.
Я частично видел. И даже сам смог некторые "ритуалы". После трансляций старинных рун из int в bin, без уверенности 100% эквивалентности... "signal acquired" сказало фирмваре =). Этого комбо никогда не существовало. Слишком примитивно для инопланетян, слишком сложно для землян. Мне стало интересно "а работает ли"? Я нашел ответы на свои вопросы. "В воздухе повисло присутствие". Теперь я знаю как это. В небольшом bias между рандомом и почти рандомом - бесконечность.
Кстати, новомодный LDPC - научная версия "highly likely" вообще :P. Никаких ГАРАНТИЙ вообще IIRC нету. Зато соотношение DATA/FEC хорошее, за что и популяризовался. Правда в основном в эфирных делах. Меня больше это в контексте FEC интересовало.
>> Я понимаю основы
> Чувак - основы - это вот рид-соломон. Его вообще никто не понимает,
> ни одна живая душа.
Не все же такие мощные как те Древние. Обычный землянин с тех правил математики поделит на ноль. Но я смог отрефакторить за древними рунические письмена на древнем диалекте си, ничего не сломав и (после чтения paper'ов) дописав пару штук, посмотреть тонка ли у меня кишка. Заодно узнав на своем заду почему таблицы "с константами от богов" в рантайме считать плохая идея. Зато, вот, таблицы в RAM могу теперь генерить примерно как некоторые CRC, в фирмвари это выбор "flash size" VS "RAM usage". Для этого таки пришлось немного въехать в странноватую полиномиальную математику.
> Кроме может быть самих Рида с Соломоном но это неточно и живы ли они - сомнительно,
> обоим должно быть за 90.
ЧСХ они изначально сформулировали свое добро заметно иначе чем это делают современные реализации.
> Чортова магия. Непонятная красивая матемагическая загогулина, неприменимая толком ни
> к какому реальному делу.
Я прицепил эту загогулину корректировать ошибки, правда, по воздуху, в той черной магии как раз не выделяется, остальное получилось под стать :). И да, они в оригинале сформулировали это заметно иначе. Современные объяснения заметно отличаются, в реальном коде - еще больше отличаются.
> На CS этому не учат, этому учат на мехмате, и то не всех.
Остальные с ума сойдут от такой математики. Но вон тем не покажут как это эффективно делать на реальных микропроцессорах с разумными параметрами. Это знание вообще есть у считанных единиц Древних на всю планету. Которые как-то смогли в оба мира. Их немного.
Кст в вике где-то есть объяснение декодирования ридсоломона на тупом примере, для самых маленьких, экстраполяция на мелких числах, графически, показывающая "core" идеи. ЧСХ - нет, ЭТО не в статье про ридсоломона, ибо нефиг :). Операции над полиномами тоже найти можно но тоже в одупляемом виде где-то в сторонке. Или, вот, лекциях CS западных вузов, более нацеленных на то чтобы студень мог если не накодить свой - так хоть осмысленно юзать и рефакторить чужое. С пониманием почему оно такое и что он делает.
> или он к предыдущему прилип. Сводящую  все эти шаманские действия
> банально к х-ю.
Это ты про одно из современных описаний RS как частного случая BCH чтоли?
> Вот это были - практики (ну старались, как могли). А ты -
> увы, в лучшем случае смог бы - скопипастить.
Я таки - вот - рефакторнул и даже отсебятины немного докорябал. Хоть и очень примерно понимал что я делаю, но имеючи рунические таблицы древних я мог сравнить результат да посмотреть лажается мой код или нет (да, я никогда не настаивал что я эксперт в операциях над полиномами транслироваными в двоичную систему).
> - некто Peter Anvin. Вот он уже оставил (и до сих
> пор валяющуюся в недрах kernel.org) внятную инструкцию - бери вот это,
> помножь вон на то, сложи вот с тем, и получившееся считай
> своими данными, раз уж часть массива накрылась.
Я как ни странно больше с парой других реализаций развлекался, они больше для передачи данных в неидеальном мире - а я именно этого и хотел. Для блочных дел - как я понимаю ридсоломон может быть весьма урезанный, там предполагается что все "erasures" известны. В случае comm мы далеко не всегда знаем где у нас erasures и там соответственно полное декодирование.
> в 2002м году. А Ding нашел отклеившийся листик - в 2003м.
> Чуешь чем пахнет?
Каким-нибудь факапом. Но как я уже сказал - не понимаю почему ты уверен что я прошел тот же путь что и ты, изучая это все дабы не быть абизяной и понимать что я делаю и почему, и даже иметь возможнось read/write этого кода. Что так то полезно - минус 2 вулна за дидами с референсом отрицательных индексов и переполнениями int-ов :)
> P.S. давай проверим, читал ли ты хотя бы статью тех практиков, или
> сразу перешел к готовым рецептам. ЧТО в ней самое странное и
> на самом деле - страшное, в очередной раз вызывающее ужас от
> соплей на которых построена цивилизация ?
Тех - это каких? CSовские лекции западных универов неплохо описывали именно то что я видел в фактической реализации. Это позволило довольно комфортно в ней шариться и я смог позволить себе рефактор и фикс вулнов, и даже оптимизации, понимая граничные условия и проч. А вот диды в этом деле слажали - и повесили пару вулнов. Что в коде потенциально кушающем random (или НеРандом) из эфира меня несколько напрягает. Почему-то.

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

159. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (153), 10-Дек-23, 17:53

> Мигрируй на бтрфс
Там даже конвертор EXT4 -> btrfs есть. Но вот это - таки не рекомендуется. Это работает, но структура ФС неоптимальная, экзотичная и так можно получить странные баги.

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

213. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от нах. (?), 11-Дек-23, 09:23

>> Мигрируй на бтрфс
> Там даже конвертор EXT4 -> btrfs есть. Но вот это - таки
> не рекомендуется. Это работает, но структура ФС неоптимальная, экзотичная и так
> можно получить странные баги.
блжад, да в каком месте у вас хоть изредка бывает не так?!

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

242. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (240), 11-Дек-23, 21:52

> блжад, да в каком месте у вас хоть изредка бывает не так?!
Чудак. Файлуха при этом врапает себя в свободное место имевшейся ФС.
1) Это довольно неоптимальная аллокация, делали не "как лучше" а "уж где нашлось место". Поэтому перфоманс такого комбо - ну вот как повезет.
2) Лэйаут ФС при этом весьма экзотичный, и если хотелось потестить код в редко используемых закоулках на странных комбо - это можно. Вот прям ща - оно, таки, вроде уже работает без особых приколов. Но с учетом 1) все равно очень на любителя комбо.
3) Если хочется побыковать на глючность фичи - окей, оно глючно по сравнению С КЕМ? Кто так вообще еще умеет? Я еще у кента какие-то зачатки этого видел. Ну он с его cow дизайном тоже может попытаться такие фортели в принципе. Для реализации такого пируэта надо CoW с write-anywhere структурой. Иначе номер не получится. Ведь надо втискиваться уж где есть место.

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

252. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от нах. (?), 12-Дек-23, 09:53

>> блжад, да в каком месте у вас хоть изредка бывает не так?!
> Чудак. Файлуха при этом врапает себя в свободное место имевшейся ФС.
> 1) Это довольно неоптимальная аллокация, делали не "как лучше" а "уж где
для fs рекламируемая фича которой безобидное увеличение на ходу - не говоря уже об антирекламируемой с перебалансировкой вручную - это п-ц какой-то. Это даже хуже ntfs (у той только и беды что mft не посередине где теоретически оптимальнее, а где получилось)
> 2) Лэйаут ФС при этом весьма экзотичный, и если хотелось потестить код
> в редко используемых закоулках на странных комбо - это можно. Вот
нет, спасибо, у меня growfs таки очень обыденный случай, когда дотестите, тогда и приходите.
> 3) Если хочется побыковать на глючность фичи - окей, оно глючно по
> сравнению С КЕМ? Кто так вообще еще умеет? Я еще у
fat2ntfs существует 25 лет.

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

254. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (240), 12-Дек-23, 19:41

>> 1) Это довольно неоптимальная аллокация, делали не "как лучше" а "уж где
> для fs рекламируемая фича которой безобидное увеличение на ходу -
> не говоря уже об антирекламируемой с перебалансировкой вручную - это п-ц какой-то.
ПЦ какой-то  - "по сравнению с чем"? А кто еще умеет вообще внутрь себя врапать чужой ФС, да еще с возможностью отмены конверсии? Ну вот EXT4 в ZFS например вообще сконвертить - смогешь? Для референса в сравнении?
А для понимания... как-то раз я под виндой хотел NTFS размер урезать и новый раздел втулить. Всего лишь. На том компе не было упса, я нашел какую-то прогу... шел примерно 30-й час ресайза (всего то, бжд) - и тут грохнулось питание. Догадайся что было дальше.
DataRecovery мое давнее хобби, я большую часть выцепил, но "по...ться завернуть" резко подвалило. Надеюсь, это объясняет почему я полюбил управление местом btrfs, там это совсем иначе. Он по backref уберет что надо - совсем не за 30 часов если не хотеть чего-то вообще странного, а крах при этом похрен, т.к. у COW записи недеструктивные. Оно либо не успело "указатели перевесить" и провалившаяся операция - самоотменится, либо успело - и это "успешный commit" в терминах транзакций.
> Это даже хуже ntfs (у той только и беды что mft не> посередине где теоретически оптимальнее,
> а где получилось)
Когда тебе надо вписаться вокруг уже существующей ФС - НЕ ИСПОРТИВ ЕЕ - ибо декларится возможность отката (можно получить старую ФС в исходном виде) - там, видишь ли, придется осетра урезать - и делать аллокации сугубо на свободном месте оригинала.
Это на самом деле - офигеннейшее сбитие автомобилем вертолета, показывающее гибкость аллокатора и мощь CoW. Большинство inplace дизайнов так тупо не сможет - за отсутствием гибкости или фиксированного размещения структур. Но начать от этого считать что автомобили - отличное ПВО.
По перфомансу этот кейс оптимальным быть не может - структуры новой ФС вкроены туда где было свободное место оригинальной ФС. Это и позволяет откат до старой ФС при таком желании. Если структуры оригинала трогать - ок, а как на это откат делать тогда?! А ты ТАКОЕ вообще с ZFS например смогешь вообще? Или с чем там еще? Такая технология требует CoW для "write anywhere" аллокаций, чтобы вписаться в свободное место другой ФС. На уровне абстракций - прикольно, имхо.
>> 2) Лэйаут ФС при этом весьма экзотичный, и если хотелось потестить код
>> в редко используемых закоулках на странных комбо - это можно.
> Вот нет, спасибо, у меня growfs таки очень обыденный случай, когда дотестите,
Это не про grow. Прицепить еще +девайс - без проблем. И место добавится. Но вот лэйаут конверченой из другой ФС файлухи - "странный": btrfs вписывается в свободное место существовавшей ФС. Не трогая ее - дабы иметь возможность отката на оригинал. Представляешь, можно вернуться на старую ФС (конечно без изменений записаных в btrfs). Это круть cow механики. Вон то - нечто типа readonly базы, относительно которой cow будет дельту делать. Можно это снести, тогда откат на старую ФС станет невозможен. Однако лэйаут останется "странный" и в более адекватный вид приводится ребалансом + дефрагом для более разумной аллокации.
А NTFS - попробуй впиши допустим в свободное место вон того EXT4? И как, хорошо получается? :)
> тогда и приходите.
Да оно вроде работает и даже баги более-менее поубиваля - просто я сразу на старте понимаю что из-за особенности технологии "мы сбили автомобилем вертолет" - лэйаут после такой конверсии будет не особо оптимальный, пришлось вписываться в свободное место чужой ФС уж как оно там есть.
> Я еще у fat2ntfs существует 25 лет.
Окей, а там можно откатиться на FAT если NTFS тебе не понравился? Вон то видите ли CoW механику использует, вообще не руша оригинал по сути :). Недеструктивная запись довольно круто отличается от in-place операций. В частности и - вот - возможностью UNDO этого всего. Это одно из лучших свойств CoW технологий.

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

256. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от нах. (?), 12-Дек-23, 20:07

>>> 1) Это довольно неоптимальная аллокация, делали не "как лучше" а "уж где
>> для fs рекламируемая фича которой безобидное увеличение на ходу -
>> не говоря уже об антирекламируемой с перебалансировкой вручную - это п-ц какой-то.
> ПЦ какой-то  - "по сравнению с чем"? А кто еще умеет
> вообще внутрь себя врапать чужой ФС, да еще с возможностью отмены
отмены в какой момент? И что будет если управляющие структуры лежат по одинаковым офсетам (уж суперблок-то точно)?
> конверсии? Ну вот EXT4 в ZFS например вообще сконвертить - смогешь?
> Для референса в сравнении?
вопрос в наличии места где это можно сделать. Его понадобится - много.
> А для понимания... как-то раз я под виндой хотел NTFS размер урезать
> и новый раздел втулить. Всего лишь. На том компе не было
> упса, я нашел какую-то прогу... шел примерно 30-й час ресайза (всего
ну может дело было в какой-то проге? А может в том что места банально не было.
> то, бжд) - и тут грохнулось питание. Догадайся что было дальше.
Казалось бы, что? При переписывании файлов внутри журналирующей метаданные fs? У скольких мильенов навернулось питание при ночном defrag?
> крах при этом похрен, т.к. у COW записи недеструктивные. Оно либо
> не успело "указатели перевесить" и провалившаяся операция - самоотменится, либо успело
> - и это "успешный commit" в терминах транзакций.
либо места на бесконечное стадо коров - не хватило.
> Когда тебе надо вписаться вокруг уже существующей ФС - НЕ ИСПОРТИВ ЕЕ
то на ней просто должно быть достаточно свободного места для манипуляций с двумя fs сразу.
Чудес не бывает.
> - ибо декларится возможность отката (можно получить старую ФС в исходном
> виде) - там, видишь ли, придется осетра урезать - и делать
и зачем она нам? Какое-то совсем ненужное действо. Нам нужно просто не потерять данные, а этот откат - ну ок, один из возможных механизмов. Как видим, довольно непростой и дорогой в реализации, может попроще стоило выбрать?
Напоминаю, возможность ресайза вниз у ext4 - встроенная фича.
> откат до старой ФС при таком желании. Если структуры оригинала трогать
> - ок, а как на это откат делать тогда?! А ты
А зачем он нужен? Нам нужно просто не потерять данные если что-то пойдет не так. Точки восстановления, не, не слышали?
> Это не про grow. Прицепить еще +девайс - без проблем. И место
> добавится. Но вот лэйаут конверченой из другой ФС файлухи - "странный":
понятно. Лучше видимо избегать таких чудес.
> дабы иметь возможность отката на оригинал. Представляешь, можно вернуться на старую
> ФС (конечно без изменений записаных в btrfs). Это круть cow механики.
троллейбусизбуханкижпг
нам не надо обратно раз уж мы полезли в это - очевидно что мы хотим оригинал заменять (и вовсе не хотим выяснять потом как добавить к нему изменившееся, даже если откатимся).
Нам надо просто не потерять данные если в процессе что-то сбойнет. Но, видимо, был выбран механизм по принципу "где светлее".
> Окей, а там можно откатиться на FAT если NTFS тебе не понравился?
нет, зачем он мне если мы от него пытаемся уйти? Что-то мне подсказывает что ТАКОЙ мне бы точно не понравился.

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

264. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (265), 19-Дек-23, 05:59

> отмены в какой момент?
IIRC "пока не снесен subvol с файлом-образом старой ФС". Забавная абстракция, а? :). Посмотри в их readthedocs детали, прикольно придумано.
> И что будет если управляющие структуры лежат по одинаковым офсетам (уж суперблок-то точно)?
Не помню что там, вероятно несколько блоков физически удвигают. Логически, старая ФС вписана в btrfs как "файл образа" в subvol "ее снапшота". Это защищает старый фс, оформляя все аллокации (включая и метаданные) как аллокации btrfs. При откате видимо возврат нескольких блоков назад. Остальное... у оригинала ничего и не менялось! Конвертор сделал btrfs метаданные, которые референсятся на те же файлы, поскольку трогать их было нельзя из-за защиты снапшотом, cow при записи выноски делает. Это идет в btrfs free space, которое заодно и extX free space был. Поскольку Ext метаданные никто не апдейтил, откат ессно в оригинальное состояние, как и ожидаемо от снапшота.
> вопрос в наличии места где это можно сделать. Его понадобится - много.
Его надо...
1) Для служебных структур btrfs.
2) Для свободного места btrfs.
Это вполне умеренно, bulk data никто не кантует! Конечно метаданные btrfs будут дублировать метаданные оригинала, но блоки будут референснуто прям из оригинала, не надо их копировать. Это ж cow/write anywhere! Что куда хочет то и референсит. Поэтому может и вон то защитить, и отреференсить, и запись редиректнуть в безопасный регион. Помнишь я говорил что ты не понимаешь истинную мощь технологий cow и write-anywhere? Это пример того что оно может.
> ну может дело было в какой-то проге? А может в том что места банально не было.
Я думаю что дело в том что в NTFS нет backrefs... Кент вон уже тоже заметил что у его сарая нет стены^W backrefs и скорость операций...не та которую он хотел!
> Казалось бы, что? При переписывании файлов внутри журналирующей метаданные fs?
А таки разлет был хорош. Записи же деструктивные! Это не cow где сперва "планируемую" копию сделали, а потом перевесили указатели, после чего GC может подгребать деаллоцированый старый вариант и мало места для лажи. А в деструктивной записи малейшее отклонение от идеала и усе, факап.
> У скольких мильенов навернулось питание при ночном defrag?
Не знаю. Но нескольким из - я вынимал данные с немоунтабельной виндой напроч нтфсины. Пришлось и вон там ту же магию, внепланово. Я более-менее все выцепил но времени убилось в разы больше планируемого и в итоге закончилось полным data move -> repartition -> возврат данных. Убийство времени и позор менеджмента систем.
> либо места на бесконечное стадо коров - не хватило.
Бесконечное не надо - только на маневровый регион, остальное GC может подгребать наздоровье, оно уже ни для чего не используется. После перевеса указателей - старый регион подлежит деаллокации. Теоретически надо места на 1 двигаемый экстент. Практически конечно супернеоптимально в таком виде.
> то на ней просто должно быть достаточно свободного места для манипуляций с
> двумя fs сразу. Чудес не бывает.
Есть 1 чудо: указателей на регион может быть более 1. Блоки  будут реюзануты, место сожрется на второй набор метаданных. И конечно блоки оригинала нельзя деаллоцировать пока есть снапшот, иначе как откатывать?! Это просто креативное использование фич CoW. Люблю такое, так системщиков и архитектов видно.
> и зачем она нам? Какое-то совсем ненужное действо.
В случае btrfs
1) возможен откат на оригинал! крутое и стебное использование механики снапшотов.
2) конверсия делается с минимумом интрузива - основной объем не кантуют.
> Нам нужно просто не потерять данные, а этот откат - ну ок, один из возможных механизмов.
Ага! При этом с данными - да и метаданными старой ФС - ничего не случается, поводов для жесткого дестроя минимум. Они креативно крафтят второй набор метаданных по сути :)
> Как видим, довольно непростой и дорогой в реализации, может попроще стоило выбрать?
Чего такого дорогого в генерации второго набора метаданных по уже имеющемуся? Самое плохое что с этого происходит - не особо оптимальный лэйаут структур. Но это более-менее лечится, в доках написано как.
> Напоминаю, возможность ресайза вниз у ext4 - встроенная фича.
И чего? Ну попробуй вписать EXT4 в какой-нибудь другой ФС не разнося ту ФС в хламину. Сорян чтобы это работало - надо CoW семантику умеющую write anywhere.
> А зачем он нужен? Нам нужно просто не потерять данные если что-то пойдет не так.
> Точки восстановления, не, не слышали?
По моему они наоборот намного красивее тех костылей сделали. Юзанули мощь cow по полной и по сути 2 набор метаданных создают. И если юзер захочет то может откатиться на старую фс. Прикольная манифестация настоящей мощи cow.
> понятно. Лучше видимо избегать таких чудес.
Да. И про это в доке написано, как и что сделать если снапшот снесен для оптимизации лэйаута. Но абстракция стебная. И да - кому-то идея зашла, и они внешний тул ntfs2btrfs сделали, то же самое делает как я понимаю.
> троллейбусизбуханкижпг нам не надо обратно раз уж мы полезли в это - очевидно
> что мы хотим оригинал заменять (и вовсе не хотим выяснять потом
> как добавить к нему изменившееся, даже если откатимся).
Откат на снапшот - подразумевает потерю изменений с момента снапшотирования. Это как раз ожидаемое поведение абстракции "снапшот".
> Нам надо просто не потерять данные если в процессе что-то сбойнет.
> Но, видимо, был выбран механизм по принципу "где светлее".
Когда в руках молоток, все вокруг кажется гвоздями. Зачем изобретать костыли если вся механика умеющая это и намного круче уже была?!
>> Окей, а там можно откатиться на FAT если NTFS тебе не понравился?
> нет, зачем он мне если мы от него пытаемся уйти?
Eval сделать - с возможностью передумать.
> Что-то мне подсказывает что ТАКОЙ мне бы точно не понравился.
А я таки проперся таким импользованием механики фс. Норм сбитие вертолета автомобилем. Ну и откат такой технологии должен быть достаточно прост и мало что может обломаться. Если не создавать себе проблем "точками отката" и проч, не придется их героически решать.

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

6. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +2 +/–

Сообщение от Аноним (6), 10-Дек-23, 11:36

откати ядро , старые из реп не исчезли

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

50. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +3 +/–

Сообщение от Аноним (50), 10-Дек-23, 12:26

Даже ничего откатывать не надо. В Debian легко можно загрузиться с предыдущим ядром, оно никуда не исчезает.

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

73. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Аноним (73), 10-Дек-23, 12:50

Это если за консолькой сидеть в момент загрузки и ручками выбирать ядро в грубе. А так он загрузит последнее установленное ядро.

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

75. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +2 +/–

Сообщение от Твайлайт Спаркл (ok), 10-Дек-23, 12:55

В /etc/default/grub можно попробовать покрутить параметр GRUB_DEFAULT (только после сохранения вызывать update-grub)

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

102. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (102), 10-Дек-23, 13:55

>В /etc/default/grub можно попробовать покрутить параметр GRUB_DEFAULT (только после сохранения вызывать update-grub)
А разве там не systemd-boot по умолчанию?

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

154. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (153), 10-Дек-23, 17:47

>> В /etc/default/grub можно попробовать покрутить параметр GRUB_DEFAULT
>> (только после сохранения вызывать update-grub)
> А разве там не systemd-boot по умолчанию?
В дебиане то? GRUB там самый обычный.

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

167. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Аноним (167), 10-Дек-23, 18:49

Самый необычный. Пропатченный гигантcкими листингами на Си, не проходившими код-ревью апстрима, чтобы сделать то, что делается одной строчкой на шелле. С уникальными уязвимостями, которых не бывало нигде, кроме Дебиана.

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

190. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Джентельмен Шоу (?), 10-Дек-23, 23:09

> Самый необычный. Пропатченный гигантcкими листингами на Си, не проходившими код-ревью
> апстрима, чтобы сделать то, что делается одной строчкой на шелле. С
> уникальными уязвимостями, которых не бывало нигде, кроме Дебиана.
И этот великолепный господин конечно же предоставит к ознакомлению портянку с багтрекера, где куча этих "уникальных уязвимостей, которых не бывало нигде, кроме Дебиана", дабы эти заявления не были голословными! ;)

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

245. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (240), 11-Дек-23, 22:54

> Самый необычный. Пропатченный гигантcкими листингами на Си,
> не проходившими код-ревью апстрима, чтобы сделать то, что делается
> одной строчкой на шелле.
Нельзя ли пруфануть это все?
> С уникальными уязвимостями, которых не бывало нигде, кроме Дебиана.
И как насчет URL? CVE?
А так сабж тоже специфичен для бэкпортированых ядер. У полисей как и у медали есть 2 стороны. Это оборотная сторона фиксирования версии - иногда можно и уникальный баг словить. Но вообще это случается раз в дохрена. В отличие от развалов федороарчей где суицидникам выгружают на головы свежак "как есть".

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

105. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от 128557 (?), 10-Дек-23, 14:11

> В /etc/default/grub можно попробовать покрутить параметр GRUB_DEFAULT
А если вместо grub'а используется boot.efi?

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

126. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Мимосисадмин (?), 10-Дек-23, 15:24

То человек должен уже знать, что делает

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

10. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +4 +/–

Сообщение от Аноним (10), 10-Дек-23, 11:40

Перезагрузитесь с использованием более раннего ядра, дебиан сохраняет 3 версии ядра при обновлениях.

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

74. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Твайлайт Спаркл (ok), 10-Дек-23, 12:53

6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29)
А версия 6.1.0-14-amd64 забагованная, да?

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

79. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +2 +/–

Сообщение от Аноним (79), 10-Дек-23, 13:09

Да, именно эта забагованная.

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

91. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Твайлайт Спаркл (ok), 10-Дек-23, 13:28

Спасибо.

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

12. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Вы забыли заполнить поле Name (?), 10-Дек-23, 11:42

Ты пакеты не разу не откатывал что-ли? Посмотри в апт логе старые версии пакетов, да запусти apt install с ними.

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

38. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +2 +/–

Сообщение от Аноним (38), 10-Дек-23, 12:13

Страдать ¯\_(ツ)_/¯

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

83. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Аноним (83), 10-Дек-23, 13:12

Пользоваться. Эти мэйнтенеры всё равно ничего не понимают. К тому же каждый пользователь Рачика признает вас своим корешем.

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

93. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." –2 +/–

Сообщение от НяшМяш (ok), 10-Дек-23, 13:36

Только вот пользователям рачика это давным-давно починили, а они и не заметили. А любителям окаменевшего наоборот сломали.

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

155. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (153), 10-Дек-23, 17:49

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

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

216. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от нах. (?), 11-Дек-23, 09:38

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

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

199. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Андрей04091977 (ok), 11-Дек-23, 01:26

Обновление ядра с исправлением уже прилетело

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

259. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Cimeries (?), 12-Дек-23, 21:21

Тоже поставил 14 версию , а потом еще накатил последнюю 15 и после этого апгрейда перестал выключатся комп! В итоге загружаюсь с 13 сейчас!  Теперь что делать не знаю! Ждать следующего обновления?

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

3. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." –1 +/–

Сообщение от Аноним (3), 10-Дек-23, 11:32

Оперативно. Буквально за день после релиза заметили. Заметил сегодня из-за ошибок при попытке обновить ядро из реп.

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

185. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (185), 10-Дек-23, 22:19

В репах лежит уже новое ядро, пофиксенное

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

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

Сообщение от нах. (?), 10-Дек-23, 11:33

zfs им не нравилась, ниправильная-ниправильная, осень слозна и не по-редхатовски. А тут в швятаом ext4 внезапная ой хрень, и - ТАДАМ, снова никто не знает - в чем причина.

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

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

Сообщение от Аноним (3), 10-Дек-23, 11:45

> Доступен промежуточный выпуск проекта OpenZFS 2.2.1, развивающего реализацию файловой системы ZFS для Linux и FreeBSD. Выпуск примечателен добавлением поддержки ядра Linux 6.6 и попыткой устранения проблемы, приводящей к повреждению данных (обнулению части блоков) в файлах после их копирования.

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

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

Сообщение от Аноним (153), 10-Дек-23, 17:51

> zfs им не нравилась, ниправильная-ниправильная, осень слозна и не по-редхатовски.
> А тут в швятаом ext4 внезапная ой хрень, и - ТАДАМ, снова никто не знает - в чем причина.
Вообще-то не только знают - но и пофиксили. Чуть ли не за сутки, в отличие от вооон тех. И баг существовал - ну может аж 1 день. Да еще вкорячен вот именно бэкпортерами, которые таки бэк-испортили :)

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

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

Сообщение от нах. (?), 10-Дек-23, 19:09

>> А тут в швятаом ext4 внезапная ой хрень, и - ТАДАМ, снова никто не знает - в чем причина.
> Вообще-то не только знают - но и пофиксили.
очень, очень удобно писать об этом через два дня. Когда и знают, и пофиксили.
А на момент появления проблемы - только догадывались, что что-то где-то пошло не так.

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

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

Сообщение от Don Perignon (?), 11-Дек-23, 03:07

> zfs им не нравилась, ниправильная-ниправильная, осень слозна и не по-редхатовски. А тут
> в швятаом ext4 внезапная ой хрень, и - ТАДАМ, снова никто
> не знает - в чем причина.
Мужик, вот что с тобой не так?!
Причём тут zfs или ext4, если проблема из-за косяка в ядре? Или чукча не читатель, чукча - писатель?!

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

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

Сообщение от нах. (?), 11-Дек-23, 09:22

>> zfs им не нравилась, ниправильная-ниправильная, осень слозна и не по-редхатовски. А тут
>> в швятаом ext4 внезапная ой хрень, и - ТАДАМ, снова никто
>> не знает - в чем причина.
> Мужик, вот что с тобой не так?!
а вот что не так с экспертами опеннета?
> Причём тут zfs или ext4, если проблема из-за косяка в ядре? Или
то есть эксперту даже невдомек что "косяк в ядре" и есть косяк в коде ext4? О сколько ж нам открытий чудных...но почему-то они все больше в области прикладной психиатрии.

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

7. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." –19 +/–

Сообщение от Аноним (29), 10-Дек-23, 11:37

Надо честно признать: линукс себя изжил. Пора дебиану на Illumos переходить.

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

103. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." –4 +/–

Сообщение от Аноним (102), 10-Дек-23, 14:09

>Надо честно признать: линукс себя изжил. Пора дебиану на Illumos переходить.
Это не Линукс себя изжил, это дебиан себя изжил. Перейти на Illumos и своими прогрессивными, современными инновациями зас*ать и его? Нет уж, пусть лучше дальше Линукс "улучшают".

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

106. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." –1 +/–

Сообщение от Аноним (106), 10-Дек-23, 14:14

Ну дык, с 91 года пилится. Как и иксы, код -- лютое устаревшее хауно, си-портянки, давно пора выкинуть и положить под сустемд что-то другое.

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

119. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Аноним (119), 10-Дек-23, 14:42

systemd тоже на Си написан, причем написан плохо

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

146. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +2 +/–

Сообщение от Аноним (106), 10-Дек-23, 17:12

Воот, надо на расте переписать в стиле вейланда, чтоб каждый сервис сам себя запускал и перезапускал.

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

157. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (153), 10-Дек-23, 17:52

> Воот, надо на расте переписать в стиле вейланда, чтоб каждый сервис сам
> себя запускал и перезапускал.
Вэйланд тоже на си блин, хотя для фанов раста запилить реализацию на этом - таки идея.

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

196. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +2 +/–

Сообщение от emdash (?), 11-Дек-23, 00:11

вейланд написан на английском, это протокол

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

201. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (201), 11-Дек-23, 02:00

> вейланд написан на английском, это протокол
Есть реализация не на Си?

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

204. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от ПомидорИзДолины (?), 11-Дек-23, 02:25

Да

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

262. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (262), 15-Дек-23, 19:58

https://github.com/Smithay/smithay

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

121. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (120), 10-Дек-23, 14:45

заменить на обычные портянки с сапогами, сразу дурь выйдёт

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

107. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +2 +/–

Сообщение от 128557 (?), 10-Дек-23, 14:15

Рано или поздно Linux сойдёт на нет, уступив место академическим Unix.

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

148. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +4 +/–

Сообщение от Аноним (148), 10-Дек-23, 17:21

В этом месте должна звучать классическая рождественская песня "O, Tannenbaum". У детишек, певших ее 30 лет назад, уже свои детишки, а может и внучатки. Но песня живет!

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

210. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Neon (??), 11-Дек-23, 05:39

Академическим Unix давно уже пора на пенсию, борода до пола выросла.

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

214. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +2 +/–

Сообщение от 1 (??), 11-Дек-23, 09:24

Это ты с ZZ Top попутал.

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

229. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Пряник (?), 11-Дек-23, 15:34

Ставлю на Иллинойс!

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

8. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Аноним (8), 10-Дек-23, 11:39

Ну это просто днище, господа. Мало того, что стабильно ядро дырявое, так еще и в дебиане. Вовремя я обновился, еще и почти 100 гигов файлов прописал на сервере. А ведь еще пару недель назад над zfs насмехались, можете почитать лол https://opennet.ru/60167-zfs
Ставьте ext4 говорили они, самая стабильная файловая система, ФС МИРА.
Самое смешное, что дожили до момента, когда даже btrfs стала надежнее, чем ext4.

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

13. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +8 +/–

Сообщение от Alladin (?), 10-Дек-23, 11:43

btrfs стала надежнее ext4? это в каком выдуманном мирке?

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

20. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +2 +/–

Сообщение от Шарп (ok), 10-Дек-23, 11:50

Чувак, ты это пишешь буквально в теме про баг в ext4.

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

40. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +8 +/–

Сообщение от Аноним (38), 10-Дек-23, 12:15

Если он каждый раз будет писать это в теме про баг BTRFS - ты утонешь в его сообщениях ))

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

110. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." –2 +/–

Сообщение от 128557 (?), 10-Дек-23, 14:18

Проснись, BTRFS очень стабильна.

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

114. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Wizard160888 (?), 10-Дек-23, 14:31

Ты в changelog'и ядра хоть раз заглядывал?

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

246. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." –1 +/–

Сообщение от Аноним (240), 11-Дек-23, 22:58

> Ты в changelog'и ядра хоть раз заглядывал?
Так там во всех файлухах баги чинят. Btrfs на данный момент не выглядит страшнее остальных в этом моменте.
А ZFS вообще недавно, вот, вырвался вперед и выхватил пальму первенства в баговании. И так то если посмотреть багтрек ZFS - да вы вообще спокойно спать не сможете. "И эти люди запрещают мне ковыряться в носу?"

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

116. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Wizard160888 (?), 10-Дек-23, 14:34

Если "да", то вопрос: Не страшно?

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

170. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от нах. (?), 10-Дек-23, 19:10

> Если "да", то вопрос: Не страшно?
он смел и отважен, а прона, случись что, нового накачает!

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

247. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (240), 11-Дек-23, 23:00

>> Если "да", то вопрос: Не страшно?
> он смел и отважен, а прона, случись что, нового накачает!
Вы там уже прочекали свои копии копий на предмет разрушения, эксперты? :) Btrfs почему-то такие обсираки на головы юзерей не грузит и вообще - они в состоянии тесты гонять ДО релиза.

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

249. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от нах. (?), 12-Дек-23, 01:05

ага, не грузит - просто в один непрекрасный момент mount отвечает error, а чего егог, как это теперь хотя бы прочитать - а хз.
> они в состоянии тесты гонять ДО релиза
и конечно же у них есть именно такой тест. Ой, нет. Это он у zfs теперь есть.
И нет, у меня нет копий-копий за полной ненадобностью таковых, только авторам игого могло такое придти в голову вообще (вероятнее всего потому что make и autoconf немодно, а модно наг0внякать что-то двести раз копирующее туда-сюда потому что так было проще чем головой думать).

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

261. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (240), 15-Дек-23, 12:56

> ага, не грузит - просто в один непрекрасный момент mount отвечает error,
> а чего егог, как это теперь хотя бы прочитать - а хз.
1) Ну вообще-то обычно - монтируется, если не идиотничать.
2) Прочитать, внезапно, в dmesg.
3) читать man 5 btrfs - на тему опций монтирования (там есть и общей эксплуатационной мудрости). Ну или если тухло, man btrfs-rescue (использовать это стоит только понимая что оно делает!) или если совсем упс, btrfs-restore.
Только конечно если ты там хотел супер-плесневелый энтерпрайз - не забудь уточнить саппортед ли вообще твой конфиг у апстрима.
>> они в состоянии тесты гонять ДО релиза
> и конечно же у них есть именно такой тест.
> Ой, нет. Это он у zfs теперь есть.
Там вон чудное обсуждение запалили - мол "фичу перед релизом надо бы потестировать". Btrfs'ники по моему наблюдению сперва таки выкатывают фичу "off by default", самые заинтересованые тестят, потом если все ок, а фича может быть полезна ALL - ее может и активируют по дефолту, но - опосля. Это - нормальный подход к релизу имхо.
> И нет, у меня нет копий-копий за полной ненадобностью таковых,
И ты конечно за весь софт знаешь что он там делал?
> только авторам игого могло такое придти в голову вообще (вероятнее всего
> потому что make и autoconf немодно, а модно наг0внякать что-то двести
> раз копирующее > туда-сюда потому что так было проще чем головой думать).
Я тут согласен - но вот то что остальные до этого не доперли - не факт. Да и ты же не предлагал замести факап файлухи под ковер я надеюсь? Редко трахающие пользователей баги - никто не отловит но они будут данные портить, без репродусера. Это круто, конечно. Если проект хочется слить.

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

178. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Аноним (178), 10-Дек-23, 21:17

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

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

250. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от нах. (?), 12-Дек-23, 01:06

насколько я понимаю - в случае ее raid6 можно сэкономить деньги и время - никому и ничего после его крэша достать оттуда не удавалось.
Безусловно эти чуваки - тоооочно знают как надо писать файловые системы!

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

117. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от КО (?), 10-Дек-23, 14:36

А при zfs у тебя ничего и не восстановишь

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

230. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Пряник (?), 11-Дек-23, 15:36

Сейчас закоммичу в btrfs баг и продолжим разговор...

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

11. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (11), 10-Дек-23, 11:41

Допатчились. Вот причина, почему все deb based имеют некую шизу -  что-то тупит или не работает там, где в апстриме уже давно всё работает без проблем.

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

15. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +4 +/–

Сообщение от Вы забыли заполнить поле Name (?), 10-Дек-23, 11:44

> где в апстриме уже давно всё работает без проблем
Но это не точно

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

17. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (17), 10-Дек-23, 11:47

make -j`nproc` bindeb-pkg

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

18. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +5 +/–

Сообщение от Шарп (ok), 10-Дек-23, 11:48

Невероятно. Диды сначала запутались в O_SYNC, потом шлифанули потерей данных, а Грег Кроа-Хартман перенёс это в шта^Wстабильную (бггг) ветку ядра.
Давайте подведём итоги. Буквально за этот год успели обосраться: ext4, zfs (https://www.opennet.dev/opennews/art.shtml?num=60167), xfs (https://www.opennet.dev/opennews/art.shtml?num=59204).
Какие ещё нужны доводы, чтобы уже побросать вышеописанный хлам и перейти на единственную адекватную современную ФС - btrfs?

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

23. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +8 +/–

Сообщение от Аноним (23), 10-Дек-23, 11:52

> на единственную адекватную современную ФС - NTFS
Поправил

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

43. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +3 +/–

Сообщение от Аноним (43), 10-Дек-23, 12:21

Нтфс рассыпалась куда чаще надо заметить, а баги весьма эпические с разносом суперблока на куски при обычном использовании.

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

48. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Аноним (43), 10-Дек-23, 12:25

И мне особенно нравятся неудаляемые файлы в ней. В некоторых случаях не поможет даже удаление в ntfs3g (обычно срабатывает), но теперь уже сама ntfs3g подпортит из-за своей кривоты. Или когда там chkdsk теряет или уничтожает данные автоматически, о том, что всё пропало, пользователю надо догадаться самостоятельно.

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

173. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (173), 10-Дек-23, 19:56

> И мне особенно нравятся неудаляемые файлы в ней. В некоторых случаях не поможет даже удаление в ntfs3g (обычно срабатывает)
Такие файлы удавалось удалить в Far (кто-то объяснял это тем, что в Far работа с файлами организована не только с помощью WinAPI, часть функций - собственная реализация).

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

191. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (23), 10-Дек-23, 23:13

Far умеет работать с UNC. Возможно, с этим связано.

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

122. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (23), 10-Дек-23, 14:50

За всю мою практику рассыпалась один раз, и то сам виноват — битый IDE-кабель надо было вовремя менять.

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

123. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (43), 10-Дек-23, 15:05

За 10 лет раз 5 устраняли баг с разносом при исчерпании места, и это только то, о чём я знаю (а я совсем не слежу).

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

136. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (136), 10-Дек-23, 15:57

Ваша хваленая ntfs просто обнулила размер мне некоторых файлов после миграции с windows 7  на windows 10.

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

164. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (164), 10-Дек-23, 18:22

так она не наша

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

35. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (43), 10-Дек-23, 12:08

У ext4 пока баги из разряда "забей", когда у остальных там что-то опасное было (у бтрфс, кстати, в прошлый раз, и вроде недавно ещё видеодрайвер её разносил).

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

42. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +5 +/–

Сообщение от Аноним (38), 10-Дек-23, 12:20

BTRFS и адекватная в одном предложении... Смешно )
По серьёзке - у меня BTRFS разваливалась на двух разных машинах сама по себе.
Как думаешь, сколько раз это происходило с EXT4?
Правильно, за всё время, что я сижу на Linux (с 2011 года) - ноль
А ещё BTRFS тупо медленнее, замороченнее и больше долбает диск. Хотя сама её концепция мне очень нравится...

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

171. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." –4 +/–

Сообщение от Аноним (167), 10-Дек-23, 19:18

За несколько лет использования Btrfs на нескольких HDD-дисках сталкивался только с одной проблемой на одном, самом интенсивно используемом, из них: "нет места на диске" при создании файлов. Места, действительно, на нём всегда было впритык, что усугубилось частым обменом данными с другими дисками. Починилось балансировкой диска (btrfs-balance) и включением автодефрагментации (autodefrag) при монтировании.
Но у меня роллинг-дистр со свежим ядром и ПО, без сомнительных патчей, а не Дебиан-вей.
> BTRFS тупо медленнее, замороченнее и больше долбает диск
Зависит от способов применения и характера данных. Я заметил другую разницу: на HDD дисках со включенным сжатием (compress=zstd) чтение ощутимо быстрее, чем на ext4. В специальных случаях можно получить гигантскую экономию места и времени записи. Например, в сценариях сборки ПО (в чистом окружении), где копируются большие объемы данных: системный корень, репозитории кода и т.п..

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

187. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." –3 +/–

Сообщение от Андрей (??), 10-Дек-23, 22:35

Выпрями руки. У меня с 2018 года на 2 ноутах btrfs, система установлена,  работает без отвала.

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

56. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." –2 +/–

Сообщение от Аноним (56), 10-Дек-23, 12:30

Ну что ты паришь. Ты даже сам сидишь на NTFS.

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

98. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от нах. (?), 10-Дек-23, 13:40

> Ну что ты паришь. Ты даже сам сидишь на NTFS.
поди что плохое?!

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

68. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Вы забыли заполнить поле Name (?), 10-Дек-23, 12:47

> Какие ещё нужны доводы, чтобы уже побросать вышеописанный хлам и перейти на единственную адекватную современную ФС - btrfs?
А начал как-будто хочешь про безопасный язык задвинуть.

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

266. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от voiceofreason (?), 21-Дек-23, 11:59

> Буквально за этот год успели обосраться
btrfs обсирается регулярно, судя по линукс-форумам. а фанатики бегают и орут что ФС идеальная, просто надо вот тут и вот там периодически подр-чить вприсядку

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

19. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +7 +/–

Сообщение от Аноним (10), 10-Дек-23, 11:49

Вообще новость - ахтунг. Разработчики ядра накатили на стабильную версию ядра патч, который вносит критический баг в самую стабильную и самую популярную файловую систему, и потом всё это попадает в качестве обновления стабильный Дебиан, а мейнтейнеры этого самого "рок стейбл" Дебиана не отзывают пакет, а постят в твиторе, что-де пользователям стоит воздержаться от обновлений. Через несколько часов публикуют новость на сайте, из заголовка которой нельзя понять, о чём идёт речь и насколько всё серьёзно (дескать, выпуск 12.3 просто отложен - а вся мякотка внутри), ещё через несколько часов - создают тему на официальном форуме.
А сколько людей незамутнённо обновили Дебиан, не прочитав этой новости - кто его знает. Вангую, что от этого косяка останется дурное послевкусие на долгое время.
Радуюсь за себя, что не обновлял свой Дебиан и сижу на незабагованной версии ядра. А от таких новостей появляется навязчивое желание опять законпелять генту.

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

21. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +4 +/–

Сообщение от Аноним (8), 10-Дек-23, 11:51

Олдстейбл теперь новый стейбл

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

24. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

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

Видимо, да.

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

36. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." –3 +/–

Сообщение от Аноним (43), 10-Дек-23, 12:10

Тебя ещё больше открытий ждёт. Рановато тебе в аналитику лезть, поднаберись опыта.

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

57. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (10), 10-Дек-23, 12:31

Ваше мнение очень важно для нас. Пожалуйста, не вешайте трубку.

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

59. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." –1 +/–

Сообщение от Аноним (56), 10-Дек-23, 12:34

Обязательно держи в курсе чьё мнение важно для вас.

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

61. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (10), 10-Дек-23, 12:36

А ты подпишись на рассылку, и узнаешь первым. Как маленький, ей-богу.

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

198. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (198), 11-Дек-23, 00:45

Ты зато как старенький. Кому нужны ваши рассылки - в мире, где изобрели твиттор, телеграм, дискорд и иже с ними?

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

202. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (79), 11-Дек-23, 02:01

Ты зашёл на форум компьютерщиков и имеешь что-то против автоматизации рутинных операций?

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

66. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от FF (?), 10-Дек-23, 12:44

Зато мне в новостях про Федору любители дебиана и его убунту-тестинга на десктопе отвечали.

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

67. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от FF (?), 10-Дек-23, 12:46

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

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

77. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (79), 10-Дек-23, 13:02

Это нормальная ситуация - если что-то считается сверхнадёжным, то рано или поздно оно ломается с тем большим треском, чем сильнее ему доверяют.

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

33. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Аноним (43), 10-Дек-23, 12:05

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

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

46. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." –4 +/–

Сообщение от Аноним (38), 10-Дек-23, 12:24

Ну, если ты обновляешься немедленно после выхода мажорной версии - ты должен прекрасно осознавать последствия.
Если обновился так рано - ну, сам себе злобный буратино ¯\_(ツ)_/¯ Помянем. Надеюсь, обновлял ты не прод на работе...

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

54. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (54), 10-Дек-23, 12:29

Это минорный апдейт.

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

69. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Аноним (10), 10-Дек-23, 12:47

Ты вообще читаешь, что написано?

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

87. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (3), 10-Дек-23, 13:20

> а мейнтейнеры этого самого "рок стейбл" Дебиана не отзывают пакет
Диванный теоретик? Отозвали.

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

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

Сообщение от Аноним (79), 10-Дек-23, 13:28

Нет, не отозвали. Вот прямо сейчас в репозиториях дебиана забагованная версия 6.1.64-1:
https://packages.debian.org/search?keywords=linux-image-amd6...

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

92. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Аноним (3), 10-Дек-23, 13:35

Ошб:1 https://deb.debian.org/debian bookworm/main amd64 linux-image-6.1.0-14-amd64 amd64 6.1.64-1
  403  Access denied - broken package [IP: xxx.xxx.xx.xxx 443]
Ошб:2 https://deb.debian.org/debian bookworm/main amd64 linux-image-amd64 amd64 6.1.64-1
  403  Access denied - broken package [IP: xxx.xxx.xx.xxx 443]
E: Не удалось получить https://deb.debian.org/debian/pool/main/l/linux-signed-amd64... denied - broken package [IP: xxx.xxx.xx.xxx 443]
E: Не удалось получить https://deb.debian.org/debian/pool/main/l/linux-signed-amd64... denied - broken package [IP: xxx.xxx.xx.xxx 443]
E: Не удалось получить некоторые архивы; возможно, нужно запустить apt-get update или попытаться повторить запуск с ключом --fix-missing?

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

97. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (79), 10-Дек-23, 13:39

Тогда хорошо, а то я обновляться на эту версию не пытался. Раньше она была в proposed-updates, а теперь просто в stable.

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

100. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Аноним (54), 10-Дек-23, 13:51

Ещё несколько часов назад спокойно обновлялось, хотя новость от вчера. Такое.

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

128. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (3), 10-Дек-23, 15:36

Я четыре часа назад обновлять пытался. Результат в логе выше.

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

142. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +2 +/–

Сообщение от Аноним (73), 10-Дек-23, 16:39

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

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

200. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (200), 11-Дек-23, 01:29

> Нет, не отозвали. Вот прямо сейчас в репозиториях дебиана забагованная версия 6.1.64-1
bookworm (stable) (kernel): ядро Linux для 64-разрядных персональных компьютеров (метапакет)
6.1.66-1: amd64

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

203. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (79), 11-Дек-23, 02:02

Да, уже несколько часов известно, что баг пофиксили.

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

129. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Аноним (148), 10-Дек-23, 15:38

Причем все дерьмо теперь льется на дебиан :(
Вся вина которых что они взяли ядро 6.1.64 с kernel.org. Озвученное всеми светилами линукс как longterm stable. Умудрившимися поделить связный набор из двух патчей из 6.5 в два отдельных, закомиченных отдельно в 6.1.64 и ядро 6.1.66.
То есть закомпиленное в генту или арче ядро 6.1.64 будет точно так же бажным. Но виноват дебиан, не иначе.

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

131. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (43), 10-Дек-23, 15:47

Ну так почему-то дебиан воспринимается некоторыми не как арч с его "собирается, значит, работает". Почему, не знаешь? Как по мне, так ещё более паршивый и менее предсказуемый дистрибутив. К старателям из ядра вопрос отдельный, но давно уже ясно, что лтс -- это нежизнеспособная помойка.

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

143. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +2 +/–

Сообщение от Аноним (148), 10-Дек-23, 16:55

самое короткое изложение проблемы (взято https://lwn.net/Articles/954285/)
- Stable kernels < 6.5 are affected if they have 91562895f803 (ext4 commit)
- Kernels >= 6.5 are not affected, as they will _also_ have 936e114a245b6 (iomap commit)

Yes, it seems only 6.1.64 and 6.1.65 are affected: https://kernel.dance/#91562895f803
Because 6.1.66 has the other "fixing" commit: https://kernel.dance/#936e114a245b6

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

22. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (22), 10-Дек-23, 11:52

А на примере с Winodows: Microsoft бы в первую очередь выпустила, а потом отложила.. как это часто бывает

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

25. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +3 +/–

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

Спасибо, чуваки. Чую, неделя будет интересной.

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

32. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." –1 +/–

Сообщение от Алексей (??), 10-Дек-23, 12:04

Самый стабильный дистрибутив

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

53. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." –2 +/–

Сообщение от Аноним (50), 10-Дек-23, 12:28

Именно. В рачах с бомжарами багованное ядро провисело несколько дней и никто даже не заметил. А тут несколько часов и уже все исправлено.

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

72. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +2 +/–

Сообщение от Вы забыли заполнить поле Name (?), 10-Дек-23, 12:50

Когда у тебя постоянно что-то отваливается, на такие мелочи не обращаешь внимания

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

88. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +2 +/–

Сообщение от Аноним (50), 10-Дек-23, 13:22

Вот и я о том же. То что в Debian - ЧП, в других дистрибутивах обыденность.

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

132. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." –2 +/–

Сообщение от Михалков (?), 10-Дек-23, 15:49

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

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

55. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (29), 10-Дек-23, 12:30

"Стабильность" -- понятие относительное. По сравнению с остальными дистрибутивами дебиан стабильный, да.

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

37. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +4 +/–

Сообщение от freehck (ok), 10-Дек-23, 12:12

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

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

168. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от нах. (?), 10-Дек-23, 19:07

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

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

211. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (211), 11-Дек-23, 07:00

Из 6.5 криво набэкпортировали в 6.1.
В результате 6.1.64 и 6.1.65 пользовать нельзя, остальное можно.
В контексте Debian12 это версия 6.1.0-14. Если у тебя Debian12 и «uname -a» выдаёт такое, нужно откатываться.

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

41. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." –1 +/–

Сообщение от Аноним (41), 10-Дек-23, 12:16

>выявления в ядре Linux ошибки, приводящей к повреждению данных в файловой системе Ext4
"Никогда не было" - и вот опять!
Код файловых систем неплохо бы изолировать от ОС и агрессивно фазить специальным юрезспейсным тестовым процессом. Заодно и сделать общим между fuse и ядерной реализацией.

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

51. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (56), 10-Дек-23, 12:27

Хорошо что ты заговорил про микроядро.

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

63. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Аноним (63), 10-Дек-23, 12:37

Никто не говорит про микроядро. Я заговорил о API и желательно ABI-совместимости интерфейсов между ФС, ядром, fuse-адаптером и фаззером. Реализация ФС собирается в kernel object, но чтобы его кроме ядра могли загружать и фаззер, и fuse-адаптер как обычный shared object.

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

45. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (45), 10-Дек-23, 12:23

> В ходе обсуждения ошибки разработчики Debian упомянули, что проблема устранена в обновлении 6.1.66, но пока непонятно какое из добавленных в этот выпуск исправлений решает проблему, так как явно связанных с VFS и Ext4 изменений в ядре 6.1.66 нет (
лог не пробовали посмотреть ?
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...

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

49. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +3 +/–

Сообщение от Аноним (56), 10-Дек-23, 12:25

Через какое-то время: Мы прекращаем сборку дебиан потому что у нас что-то не получается.

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

58. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Аноним (54), 10-Дек-23, 12:34

Грег бросает ядро линукс и переходит на гну/хурд тогда уж.

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

71. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +5 +/–

Сообщение от Вы забыли заполнить поле Name (?), 10-Дек-23, 12:49

В майкрософт

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

60. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Аноним (22), 10-Дек-23, 12:34

если честно, то можно и на 11м и на 10м сидеть и все будет в норме.. пакетов на аккумулировано хватит на многие года. да и в целом потенциала достаточно чтобы не дергаться

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

64. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (64), 10-Дек-23, 12:38

как хорошо что у мя хомяк на ext3

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

101. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от я (?), 10-Дек-23, 13:51

И четвёртое ядро?

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

163. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (64), 10-Дек-23, 18:22

черт... а как ты догадался? :) У меня LTS, который на поддержке...

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

108. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (108), 10-Дек-23, 14:17

У альтовцев просто пишут,что ext 2-3,а оно там явно 4.

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

65. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." –1 +/–

Сообщение от glad_valakas (?), 10-Дек-23, 12:39

% uname -a
Linux devuan 5.15.142 #1 SMP Sun May 1 12:00:00 CEST 2011 x86_64 GNU/Linux
новость не осилил. мои локалхосты дефектные или нет ?

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

70. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Вы забыли заполнить поле Name (?), 10-Дек-23, 12:48

> Проблема проявляется в стабильной ветке ядра Linux 6.1

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

76. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (45), 10-Дек-23, 12:56

> Linux devuan 5.15.142
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
> 2 days    iomap: update ki_pos a little later in iomap_dio_complete
>  мои локалхосты дефектные или нет ?
нет
А в 6.1 только 6.1.64 и 6.1.65 с небольшой проблемой потому что патч не донесли из апстрима

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

78. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Аноним (78), 10-Дек-23, 13:04

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

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

81. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Tron is Whistling (?), 10-Дек-23, 13:10

Опять direct i/o поломали...

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

82. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (82), 10-Дек-23, 13:12

Вот поэтому я никогда и не обновляю ядро, какое было на iso такое и стоит годами.

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

89. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Аноним (45), 10-Дек-23, 13:23

> Вот поэтому я никогда и не обновляю ядро
fat в ro на керамике веками проработает без сбоев

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

241. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (241), 11-Дек-23, 21:52

fat -грязная проприетарщина
~# mount
/dev/root on / type ext2 (ro,noatime)
...
как-то так

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

84. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +2 +/–

Сообщение от Аноним (82), 10-Дек-23, 13:16

> непонятно какое из добавленных в этот выпуск исправлений решает проблему
> скорее всего речь ведётся о прекращении проявления проблемы
непонятно
скорее всего
Ахаха
Линукс

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

145. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (-), 10-Дек-23, 17:02

all stable kernels that have 91562895f803 ("ext4: properly sync file size update after O_SYNC direct IO") before 6.5 are corrupting data
что тут непонятного?

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

94. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от pic (?), 10-Дек-23, 13:36

>Проблема проявляется в стабильной ветке ядра Linux 6.1, в которую было перенесено исправление, изначально добавленное в ветку 6.5
А я уже упоминал об этой проблеме с ядром 6.5 и замиранием системы в Endless OS.

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

130. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от pic (?), 10-Дек-23, 15:39

>Upgrades to 5.1.0 are currently disabled while we investigate an issue where some computers no longer start up after the upgrade.
Ну вот и правильно, релиз Endless OS 5.1 с _проблемным ядром 6.5_ отключен для обновления.
Пусть разбираются, негоже делать стабильную систему незагружаемой.

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

96. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." –1 +/–

Сообщение от Аноним (96), 10-Дек-23, 13:37

Ну и как так вышло, что в типа самом стабильном дистрибутиве косяки уровня роллинга типа арча?

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

99. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." –1 +/–

Сообщение от Аноним (22), 10-Дек-23, 13:43

Разогнались.
Проще говоря один раз отмерили и семь раз сделали.

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

135. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (135), 10-Дек-23, 15:54

Задайте свой вопрос на kernel.org

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

115. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от КО (?), 10-Дек-23, 14:34

Делать стэйбл версию, чтобы в неё переносить некритичные патчи из анстэйбл, гениально

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

127. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от pic (?), 10-Дек-23, 15:30

По логике всё это надо было пихать опционально в backports-репозиторий.

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

138. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +2 +/–

Сообщение от Аноним (148), 10-Дек-23, 16:06

Еще раз - бэкпортили разработчики ядра, из 6.5 в 6.1, который отличается длительным сроком поддержки. Дебиан в этой схеме - пострадавший, а не виновник.

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

161. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от pic (?), 10-Дек-23, 18:01

Не усмотрел что релизе Debian 12 состоялся с ядром 6.1, как-то экстраполировал Debian 12 на Endless OS 5.1, она тоже на Debian собирается, только ядро у меня стоит 5.15, думал такое же в Debian 12 стоит, а 6.1 в backports. Оказывается базовый образ Endless OS перешагивает релизы Debian по ядрам.

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

118. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (120), 10-Дек-23, 14:41

Вот они, любители бэкпортировать во всей красе.

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

124. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." –1 +/–

Сообщение от Аноним (124), 10-Дек-23, 15:12

"Горшочек вари!" В свое время намучился переустановками ос из-за обновлений и плюнул.Год назад установил Arch (все настроил под себя) и отключил все репозитории, живу стабильно и не чего не отваливается..

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

134. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." –2 +/–

Сообщение от Михалков (?), 10-Дек-23, 15:50

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

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

150. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (150), 10-Дек-23, 17:26

Лучше бы дизайн нормальный нарисовали и выбрали один тулкит за стандарт, выбросив все остальное.
Вся остальная эта мышиная возня под капотом никому на десктопе не интересна.

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

236. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (236), 11-Дек-23, 19:01

Нормальный дизайн давно нарисован - это win95-подобные схемы.

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

162. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (162), 10-Дек-23, 18:17

О, а я-то думал почему у меня при апгрейде "E:Failed to fetch ... 403 Access denied - broken package [IP xxx.xxx.xxx.xxx 80]"
А оно вононочомихалыч!

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

166. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." –3 +/–

Сообщение от Вася (??), 10-Дек-23, 18:47

Но зачем они притащили это в Debian стабильный, вот в чем вопрос. Кто виновен в этом саботаже? У каждой ошибки есть фамилия и должность.

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

172. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (172), 10-Дек-23, 19:26

Установлен LMDE 6, uname -a показывает именно 6.1.0-14. Что теперь делать? А как же миллион раз обещанная надежность и фундаментальная стабильность?

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

174. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (173), 10-Дек-23, 20:07

См. выше: https://www.opennet.dev/opennews/art.shtml?num=60261#138

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

175. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Аноним (79), 10-Дек-23, 20:12

> Что теперь делать?
Читать Чернышевского и Ленина... э-э-э... Перезагрузиться в более раннюю, незабагованную версию ядра.

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

184. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от nox. (?), 10-Дек-23, 22:13

И чем 5.15 не угодила?

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

188. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (79), 10-Дек-23, 22:40

А где в bookworm'е версия 5.15?

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

207. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Джентельмен Шоу (?), 11-Дек-23, 03:31

> Установлен LMDE 6, uname -a показывает именно 6.1.0-14. Что теперь делать? А
> как же миллион раз обещанная надежность и фундаментальная стабильность?
Смысле, что делать? Загрузиться в предыдущую версию и ждать фикса. Или вы из тех позитивных оптимистов, которые установив новую версию ядра вычищаете все предыдущие?

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

176. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +2 +/–

Сообщение от Аноним (176), 10-Дек-23, 20:22

У меня после обновления ядра домашний сервачок в осадок выпал. Пришлось ставить видеокарту и выяснять что к чему. Оказалось что встроенный realtek на 2.5гбит со стороны linux не поднимает линк и вешается намертво, хотя на свитче линк активен. Подумал что он таки сдох и уже собрался искать замену, но перезагрузка на предыдущее ядро все исправила. Так что сломали не только лишь ext4.

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

177. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Шишкин (?), 10-Дек-23, 20:51

И зачем нужны эти жалкие надстройки над EXT2?
Почему бы просто не перейти на отвечающую всем современным требованиям Reiser5?

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

179. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (179), 10-Дек-23, 21:22

> И зачем нужны эти жалкие надстройки над EXT2?
Везде стоит ext2, она намного быстрее чем ext4.

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

192. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (192), 10-Дек-23, 23:14

Дай набойчик на док где взять reiser5 и как потом применить.

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

180. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от eugener (ok), 10-Дек-23, 21:47

Пофиксили, пришла обнова на 6.1.0-15.

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

194. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от dannyD (?), 10-Дек-23, 23:27

да, так и есть.
обновил деб на втором ноуте, полёт норм.

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

181. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." –1 +/–

Сообщение от Аноним (181), 10-Дек-23, 21:52

Версия 6.6.6 на подходе. Это знамения.

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

182. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (79), 10-Дек-23, 22:09

Последние времена настают

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

193. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (192), 10-Дек-23, 23:16

Всё ближе к демонам из FreeBSD?

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

183. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." –1 +/–

Сообщение от nox. (?), 10-Дек-23, 22:12

Так ставь на Ext3.

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

226. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от нах. (?), 11-Дек-23, 12:52

> Так ставь на Ext3.
у тебя ж ntfs?

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

260. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от nox. (?), 13-Дек-23, 14:06

Всего у меня в работе 4 компьютера (ноутбуком что-то перестал пользоваться). На архивном диске и на 2 компьютерах под Windows - NTFS. На 2 компьютерах - Ext4.

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

186. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (186), 10-Дек-23, 22:25

Но ведь сложность развесистых веток git оправдана как раз тем, что там не нужно бэкпортировать. Баг исправляется в одном месте и все версии штатно обновляются.

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

232. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (186), 11-Дек-23, 15:43

Кстати, там что-то типа https://www.atlassian.com/git/tutorials/comparing-workflows/... или как вообще организовано?

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

197. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." –1 +/–

Сообщение от Аноним (197), 11-Дек-23, 00:15

Debian = стабильность, говорили они, и вот тебе на в стабильном дистрибутиве на стабильном ядре, баг в файловой системе повреждающий данные, фактически единственный плюс который предоставляет данный дистрибутив как выясняется не является никаким плюсом, все так же как у всех, и даже хуже из-за специфики дистрибутива, и в нагрузку ещё и ПО протухшее.

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

206. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Аноним (206), 11-Дек-23, 03:13

Как достали дебилы, кричащие про протухшее ПО в Дебиане. Хочется поновее - используй ветку testing или unstable. И unstable, если что - это НЕ про нестабильность софта, ищи в гугле почему так ветка называется. Debian unstable постабильнее релизов многих дистров будет.

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

222. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (197), 11-Дек-23, 12:03

Но ведь testing или unstable вместе с новым ПО получают ещё большую нестабильность, не говоря о том что новое ПО в них не всегда такое новое как в других дистрибутивах, какой смысл пользоваться дебианом если нужно разменивать его хвалебную "стабильность" на новое ПО? Другие дистрибутивы справляются лучше с задачей стабильность+свежее ПО, просто потому что цикл обновления гораздо меньше.

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

208. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Аноним (208), 11-Дек-23, 03:34

> Debian = стабильность, говорили они, и вот тебе на в стабильном дистрибутиве
> на стабильном ядре, баг в файловой системе повреждающий данные, фактически единственный
> плюс который предоставляет данный дистрибутив как выясняется не является никаким плюсом,
> все так же как у всех, и даже хуже из-за специфики
> дистрибутива, и в нагрузку ещё и ПО протухшее.
А то что этот баг появился сперва в апстриме, в стабильной же версии ядра, мы скромно умалчиваем, да? ;)

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

217. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от нах. (?), 11-Дек-23, 09:40

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

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

224. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (197), 11-Дек-23, 12:11

Ну так в чем я не прав, пока нормальные дистрибутивы получили нормальный свежий патч, дебиан получил кривой бэкпорт.

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

225. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от нах. (?), 11-Дек-23, 12:51

"нормальный свежий патч" получить могли только любители сидеть на свеженьком только что из под хвоста. где одно починили, в десяти других местах поломали.
Нормальные дистрибутивы, ага, для любителей экспериментов на себе.
А вот сколько времени оно там было поломано до того - это эксперты вряд ли даже и знают.

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

235. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (197), 11-Дек-23, 18:11

Демагогия.

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

223. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (197), 11-Дек-23, 12:09

Ну смысл в том что Debian должен был не попасть в просак из за особенностей его цикла обновлений, а в итоге обосрался ещё хуже чем дистрибутивы со свежим ПО за счёт кривого бэкпорт патча. Вот и вся хваленная "стабильность" дебиана.

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

219. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Аноним (219), 11-Дек-23, 09:55

> так как Debian сохраняет три версии ядра при обновлениях.
две сохраняет если не чистить apt autoremove.

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

227. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от yet another anonymous (?), 11-Дек-23, 14:05

Прекрасно: по тексту таки непонятно --- это в kernel проблема или debian'овском опакечивании kernel'а?

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

231. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Пряник (?), 11-Дек-23, 15:42

Перечитай первую строку
> Разработчики проекта Debian объявили о приостановке публикации установочных образов с обновлением Debian 12.3 из-за выявления в ядре Linux ошибки
Проблема в ядре! А разрабы Debian её заметили. Но поздно...

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

248. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от yet another anonymous (?), 11-Дек-23, 23:14

Дебиановский workflow во всй красе: ни одного прямого указания на коммит в ядре (хоть в чьём дереве). Так что понять, что же они отгружают в пакете на самом деле они сами могут ли понять?

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

258. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от нах. (?), 12-Дек-23, 20:17

> Дебиановский workflow во всй красе: ни одного прямого указания на коммит в
> ядре (хоть в чьём дереве). Так что понять, что же они
> отгружают в пакете на самом деле они сами могут ли понять?
они отгружают архив с kernel.org, внезапно. Без всякого понятия где и чьи там комиты.
Но ты разумеется можешь сказать apt source и поискать комит самостоятельно.

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

228. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Пряник (?), 11-Дек-23, 15:31

Debian помогает искать баги в Linux!

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

233. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +1 +/–

Сообщение от Аноним (181), 11-Дек-23, 15:47

Версия ядра 6.6.6 вышла. Страшно конпелять.

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

243. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от Минона (ok), 11-Дек-23, 22:33

Тысяча чертей!
Как можно было накосячить в коде ext4?!
Майки уволили криворуких индусов и те подались в Линукс?

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

257. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..." +/–

Сообщение от нах. (?), 12-Дек-23, 20:14

> Тысяча чертей!
> Как можно было накосячить в коде ext4?!
google: silent data corruption ext4
(ext3, ext2... впрочем о мертвых гугль обычно возвращает ничего, а ты промышленной некромантией вряд ли владеешь да и кота тебе жаль)
> Майки уволили криворуких индусов и те подались в Линукс?
have always been there.

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

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

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

Партнёры:

Хостинг:

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

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

1. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
Сообщение от Аноним (1), 10-Дек-23, 11:30
> Пользователям уже установленных систем рекомендовано воздержаться от установки обновлений пакетов с ядром из репозитория до публикации исправления. А я уже установил, что мне делать?
Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+1 +/–
	Сообщение от Аноним (5), 10-Дек-23, 11:33
	Мигрируй на бтрфс
	Ответить \| Правка \| Наверх \| Cообщить модератору


	29. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+5 +/–
	Сообщение от Аноним (29), 10-Дек-23, 12:00
	Чтобы не терять времени -- лучше сразу молотком комп разбить, чем сношаться с рассыпающейся от каждого чиха BTRFS.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	80. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	–8 +/–
	Сообщение от Бывалый смузихлёб (?), 10-Дек-23, 13:10
	посоны поговаривают что бтрфс практически не рассыпается в отличие от практически не восстановимых при сбое ФС семейства экст№
	Ответить \| Правка \| Наверх \| Cообщить модератору


	109. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+2 +/–
	Сообщение от Аноним (-), 10-Дек-23, 14:17
	> посоны поговаривают что бтрфс практически не рассыпается в > отличие от практически не восстановимых при сбое ФС семейства экст№ Развалиться может что угодно - но в btrfs чаще всего предупреждение о проблемах все же есть сильно заранее, если системные логи мониторить хоть немного. А ext4 все пофиг, до того момента как объем факапа не нагнет все к чертям.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	263. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Олег (??), 17-Дек-23, 01:16
	Советую почитать форум Synology на предмет стабильности BRTFS) очень советую, ну это как пример сообщества активного BRTFS, других уж не знаю.... Разрушить ext еще постараться нужно, что не скажешь про кучу внутренних болячек BRTFS Вместо BRTFS лучше бы ZFS упомянули.... Вообще непонимаю что сподвигает людей всместо ZFS выбирать эксперементальный BRTFS, внедряли бы сразу уж Riserfs 5, фишек тоже тьма и с стабильностью так понимаю -+ также
	Ответить \| Правка \| К родителю #80 \| Наверх \| Cообщить модератору


	86. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Всем Анонимам Аноним (?), 10-Дек-23, 13:19
	Миллионы пользователей ChromeBook резко удивились, что оказывается у них все каждый день рассыпается
	Ответить \| Правка \| К родителю #29 \| Наверх \| Cообщить модератору


	151. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+2 +/–
	Сообщение от Аноним (151), 10-Дек-23, 17:27
	Слегка не так "Slight correction: we use btrfs for the disk image backing the user's crostini state only. The rest of Chrome OS, and the crostini VM rootfs, still use ext4."
	Ответить \| Правка \| Наверх \| Cообщить модератору


	189. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	–1 +/–
	Сообщение от Анонимский (?), 10-Дек-23, 22:54
	> Миллионы пользователей ChromeBook резко удивились, что оказывается у них все каждый день > рассыпается А что эти все делают и почему они вдруг в единственном числе?
	Ответить \| Правка \| К родителю #86 \| Наверх \| Cообщить модератору


	104. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	–2 +/–
	Сообщение от 128557 (?), 10-Дек-23, 14:09
	Может прекратить жить по модели бабки, разносящей не проверенные слухи, лишь бы обратили внимание? BTRFS хороша и стабильна.
	Ответить \| Правка \| К родителю #29 \| Наверх \| Cообщить модератору


	120. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+7 +/–
	Сообщение от Аноним (120), 10-Дек-23, 14:42
	сказала бабка
	Ответить \| Правка \| Наверх \| Cообщить модератору


	139. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от maximnik0 (?), 10-Дек-23, 16:10
	>BTRFS хороша и стабильна. Но если где то повредилось пару байт и crc32 не хватает скорректировать ошибку,есть не хилый шанс не починить фс.Реально, средства проверки падают и хрен что сделаешь кроме отката.Это что за фс где из за одного файла вся фс в расскарячку становится :-( Я не спорю, сейчас гораздо она стала стабильный, и быстрей,уже детских ошибок нет,(по крайней мере приделали рабочий костыль_это я про дополнительное место для метаданных) но отсутствие рабочего fsck уже достало... Хорошо хоть все данные можно выципить. (Но очередь записи в схеме жёсткий диск + Флэш память у btrfs хороша,такого конечно в ехт4 нету и хрен сделаешь....)
	Ответить \| Правка \| К родителю #104 \| Наверх \| Cообщить модератору


	153. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+1 +/–
	Сообщение от Аноним (153), 10-Дек-23, 17:41
	>>BTRFS хороша и стабильна. > Но если где то повредилось пару байт и crc32 не хватает скорректировать ошибку, Люблю экспертов опеннета, всегда блеснут экспертизой... 1) CRC32 - вообще не код коррекции ошибок! Ошибка корректируется путем чтения блока из второй копии, внезапно (RAID1/DUP/...). Ну или вычисляется за счет parity (RAID5/6, не рекомендуется, особенно второй). 2) CRC32 довольно хорошо ловит "битовые ошибки" типичные для факапов сторажей и глючного железа. 3) Если CRC32 мало под ваши требования есть xxhash, и даже sha256/blake2s - если надо ну вот реально неубиваемый хеш который хрен словит коллизию даже на петабайтах. Но если у вас хеш стресстестится - это наверное повод задуматься о смене гнилого железа так то. > есть не хилый шанс не починить фс. Чинябельность ФС зависит сугубо от наличия 2 копии (или парити) и сойдется ли чексум там. Избыточность с которой можно починиться либо есть, либо нет. Чудес не бывает. > Реально, средства проверки падают и хрен что сделаешь кроме отката. Сразу видно эксперта который btrfs видел только на картинке. И то не факт. > мере приделали рабочий костыль_это я про дополнительное место для метаданных) но > отсутствие рабочего fsck уже достало... Для меня это вообще ломовая фича в ситуациях где некому any key жать, оно просто работает, отклонения от идеала - парирует из другой копии. А отвечать на тупые вопросы на встраиваемых системах, да и серверах ВНЕЗАПНО, НЕКОМУ. Да и вообще - ext4 довольно средняя штука. От бэдов под метаданными вполне может и скопытиться или потерять довольно много данных. Plan B на этот случай - нет. И даже RAID1 в подобной ситуации может и не помочь, особенно если накопитель как сейчас модно вернет труху без отлупа IO error, что конечно подляна - но бывает вот. > (Но очередь записи в схеме жёсткий диск + Флэш память у btrfs > хороша,такого конечно в ехт4 нету и хрен сделаешь....) У EXT4 полное журналирование - капец тормозное. А без этого - он вообще класть хотел что с данными при крахе случится, его интересует только совпадение аллокаций свободного места с файлами, что там внутри файла... а вот что получится то и будет. Данных откатить это или довести до конца транзакцию без полного журнала нет. А с полным журналом - две записи вместо 1 будут. Сперва в журнал - намерения, потом в основной регион. Btrfs, bcachefs и ко читерят - идея cow в том что по сути журналом становится вся площадь. При этом более не надо переносить из журнала в основную область и вторая запись отпадает. К сожалению, это вызывает нужду в Garbage Collector ибо вечная история записей - все же сожрет место. И иногда надо все же подтирать. Такой подход приколен тем что при записи ничего не портится из существующего. А фикс консистентности делается ... простым игнором недописаного. Этого никогда не было - и все тут. Ведь все данные для предыдущего состояния - на месте. Отсюда и нужда в аллокации места для изменений. К метаданным это тоже применяется. Поэтому на btrfs всегда есть множество альтернативных точек входа для поыптки ре-парсинга. Это будут чуть более старые состояния, но возможно что нужный файл в нужном виде там был, а деревья этого состояния достаточно живые чтобы нужные файлы вынуть.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	158. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от penetrator (?), 10-Дек-23, 17:53
	xxhash64 в плане коллизий вполне надежен, он не криптографический, т.е. не имеет характеристик важных для криптографии и не устойчив к криптографическим аттакам (но ему и не нужно), а вот 64-битного пространства при его характеристиках хватает с запасом, можно посмотреть что отдает по нему SMHasher
	Ответить \| Правка \| Наверх \| Cообщить модератору


	160. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Аноним (153), 10-Дек-23, 17:56
	> xxhash64 в плане коллизий вполне надежен, он не криптографический, > т.е. не имеет характеристик важных для криптографии и не устойчив к криптографическим > аттакам (но > ему и не нужно), а вот 64-битного пространства при его характеристиках > хватает с запасом, можно посмотреть что отдает по нему SMHasher Ну дык можно вот его. Если кому совсем нечего делать, -dev версии btrfs-tools умеют конвертить тип чексум, на отмонтированой ФС. Я с сыпучей флехой поиздевался - оно даже допирает коррекцию сделать при такой конверсии походу, вот уж не ожидал то. Еще кстати из операций на отмонтированой ФС - bg_tree всячески рулит, особенно на механике, так оно маунтиться начинает быстрее чем даже ext4/bcachefswhatever.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	165. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+3 +/–
	Сообщение от Аноним (165), 10-Дек-23, 18:37
	> Я с сыпучей флехой поиздевался Ты с ней побывал почти в каждой новости о файловых системах. Учитывайте, что здесь btrfs-евангелист с его "накопитель как сейчас модно вернет труху" и закрыванием глаз на баги любимой ФС.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	237. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Аноним (-), 11-Дек-23, 20:52
	>> Я с сыпучей флехой поиздевался > Ты с ней побывал почти в каждой новости о файловых системах. Учитывайте, > что здесь btrfs-евангелист с его "накопитель как сейчас модно вернет труху" > и закрыванием глаз на баги любимой ФС. 1) Мне все время рассказывают страшилки как я потеряю данные и проч. Уже какой там по счету год. А они все никак не теряются. 2) Есть ощущение что этот булшит часто ретранслируют кадры которые вон то не видели даже на картинке. А то и вовсе юзеры виндов позорные. Которые так то игнорят проблемы своих фетишей еще активнее, пытаясь даунплеить реально существующие проблемы. Коллекция глюкастиков наловленых btrfs'ом не даст соврать. 3) Я еще и с bcachefs экспериментирую - за примерно то же самое: продвинутый дизайн, обещающий опять же простой и удобный менеджмент :). Так что можете назло бабушке отморозить уши и ничего слаще EXT4 не использовать, кому хуже то?! А "евангелист" я только потому что мне нравятся продвинутые современные технологии - и крутые эффективные тимы разработчиков. Поэтому считаю несправедлимым тот крап который тут выдают те кто это вообше не юзал, но ценное мнение - имеют. И вообще, EXT4 всяким место на свалке истории. Дизайн который вечно тупит своими директориями которые он отрастить может, а сдуть нет, а то и вовсе налетает на недостаток, блин, инодов - и кладет с прибором на участь данных - это, извините, по современному состоянию дел - таки архаика. Ну как паровоз примерно. Вроде ездит - но желающих это делать вот так будет все меньше.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	195. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+1 +/–
	Сообщение от Аноним (195), 10-Дек-23, 23:55
	На бумаге по Btrfs все хорошо, на деле же там уже сами разработчики не ориентируются, настолько переусложнена. Там по ходу разработки необходимость менять архитектуру возникала раза так два - изначальная ко всем новым задумкам не подходила. И сейчас они с грехом пополам пытаются усидеть на той самой первоначальной архитектуре, потому что перерабатывать ее уже никто не будет. Это тупиковый путь и тупиковая ФС.
	Ответить \| Правка \| К родителю #153 \| Наверх \| Cообщить модератору


	238. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Аноним (-), 11-Дек-23, 21:03
	> На бумаге по Btrfs все хорошо, на деле же там уже сами разработчики не ориентируются, Извольте-ка пруф на это храброе заявление предоставить? На ваше несчастье я этих разработчиков еще и знаю. И имел опыт взаимодействия с ними. Так что сейчас мы узнаем уровень вашей квалификации. Если не ответите и сольетесь - все понятно. Я даже могу назвать пару фич которые в разработке. Скажем Extent Tree V2, решающий ряд проблем масштабируемости на очень быстрых сторажах. А мне вот bg_tree очень понравился (since kernel 6.1), время монтирования скостил конкретно, особенно на механике. > настолько переусложнена. Там по ходу разработки необходимость менять архитектуру > возникала раза так два - изначальная ко всем новым задумкам не подходила. А теперь извольте показать - что там в архитектуре радикально поменяли? Желательно еще и с комитами где это случилось. Ща мы тут всех экспертов по полочкам и разложим, ибо дело мастера боится. > И сейчас они с грехом пополам пытаются усидеть на той самой первоначальной > архитектуре, потому что перерабатывать ее уже никто не будет. Это тупиковый путь > и тупиковая ФС. Если так рассуждать, то по таким стандартам NTFS это окаменелый помет динозавра, EXT4 и XFS - тоже окаменелые фекалии мамонта... а если так посмотреть, то новомодный bcachefs содрал процентов так 85-90 от именно архитектуры, именно btrfs'а. Ну не от вон тех же складов костылей, в самом то деле? И теперь файлухи будут делать - ну вот как-то так. Потому что перспективные паттерны дизайна. Сложное? Возможно, но эквивалентная этажерка md/dm/lvm/... - еще хуже, и, главное, менеджмент этого всего в том месиве уровней это подный крындец. Либо забить на все продвинутости типа чексумм, снапшотов, райды и прочь - и админить как будто на дворе 80-е прошлого века. Либо познать как выглядит боль. А потом сравнить с вон тем - и попробовать убедить себя использовать те деревянные оглобли еще раз...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	209. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от maximnik0 (?), 11-Дек-23, 04:50
	>CRC32 - вообще не код коррекции ошибок! Можно использовать для коррекции ошибок.Как я помню один из видов crc32 может обнаружить до 7 однобитных ошибок для 1024 бит и надёжно скорректировать 3 из них .Я это к чему-читал я в баг падчах что 1 битную ошибку все таки должен btrfs-check ремонтировать если я правильно понял перевод. Теоретическая работа для коррекции 3 битных ошибок -https://translated.turbopages.org/proxy_u/en-ru.ru.56586785-... Но требует 1,4 Гб места для таблицы перебора.Дальше для исправления возможны коллизии......
	Ответить \| Правка \| К родителю #153 \| Наверх \| Cообщить модератору


	240. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Аноним (240), 11-Дек-23, 21:43
	>>CRC32 - вообще не код коррекции ошибок! > Можно использовать для коррекции ошибок.Как я помню один из видов crc32 может > обнаружить до 7 однобитных ошибок для 1024 бит и > надёжно скорректировать 3 из них . При сильном желании и SHA256 - код коррекции ошибок. Вот вам блок с эн левых битов, и тасуйте биты брутфорсом, пока SHA256 не сойдется! Сколько битов осилите сбрутфорсить, столько и ваше. Но какой-нибудь ридсоломон декодировать сильно быстрее, и починит намного больше. Но как чексум для вот именно валидации содержимого он не такой уж и сильный, рядом с SHA256 не стоял. Если даже некто и сбил автомобилем веротолет - это еще не делает автомобили ПВО. В btrfs - как минимум в обычном режиме, CRC32 сугубо как чексум и нужен сугубо для валидации прочитаного и единственное что интересует это коллизии, когда нечто левое будет проглочено как валидный блок. А восстановление из избыточной копии. И с вот этой частью механики я малость повозился и даже в стресстесты этого аспекта для тестов умею. > Я это к чему-читал я в баг падчах Что сие такое и есть ли у этого урл? > что 1 битную ошибку все таки должен btrfs-check Хотелось бы пруфлинк на это дело, чтоли. У меня сорц btrfs-tools если что есть. А так 1 бит и FEC накопителя обычно починит, левай случается когда он неосилил, и там уже что угодно может быть, кто ж знает что фирвар при этом выгружает. Да и идея в том что при избыточности оно self heal само на ходу делает. Прозрачно и без участия юзера. Это еще и ремапу проблемных секторов помогает, фирмваре стоража не надо пыхтеть пытаясь выдернуть нечитаемый сектор. EXT4 при таком будет как дятел ломиться в нечитаемый сектор, а запись туда может никогда и не случиться и ремапа не будет, будет сектор (и файл/метаданные) где всегда затык. > ошибок -https://translated.turbopages.org/proxy_u/en-ru.ru.56586785-...- > e6e82254-74722d776562/https/github.com/jeffareid/misc/blob/master/crccor3.c > Но требует 1,4 Гб места для таблицы перебора.Дальше для исправления возможны коллизии...... Концептуально, конечно, но с такими соотношениями - нахрена оно такое? Показать что автомобилем при очень сильном желании можно сбить вертолет?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	215. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от нах. (?), 11-Дек-23, 09:35
	> Люблю экспертов опеннета, всегда блеснут экспертизой... > 1) CRC32 - вообще не код коррекции ошибок! Ошибка корректируется путем чтения вообще-то иногда и коррекции (только никто в мире не умеет ее правильно применять. Если бы ты не щупал однокурсницу на лекции о циклических кодах - ты бы даже знал, какие правильные вопросы надо задать гуглю, это-то даже на ит-факультетах есть. И ты НЕ НАЙДЕШЬ на них ответов. Возможно они есть где-то в документах itu-t доступных по подписке за пару миллионов швейцарских франков, но это неточно.) > блока из второй копии, внезапно (RAID1/DUP/...). Ну или вычисляется за счет > parity (RAID5/6, не рекомендуется, особенно второй). и если нам не повезло - нет второй или обе битые - "всеми щупальцами облизался и спрашивает - и что делать будиииим?!" Нет, чо, серьезно что-ли у вас Btrfsck не знает что полагается при этом делать?! > Чинябельность ФС зависит сугубо от наличия 2 копии (или парити) и сойдется надо же - в ext2 нет никакой второй копии - а починить ее обычно удается. Забытое умение древних, неповторимый загадочный артефакт (и похоже таки да, забытое). >> Реально, средства проверки падают и хрен что сделаешь кроме отката. > Сразу видно эксперта который btrfs видел только на картинке. И то не если на картинке падают средства проверки - надо найти художника и выколоть ему глазки! > копии. А отвечать на тупые вопросы на встраиваемых системах, да и > серверах ВНЕЗАПНО, НЕКОМУ. внезапно, есть кому. Но на вопрос sigbus ответить кроме пол-второго и нечего. > Да и вообще - ext4 довольно средняя штука. От бэдов под метаданными > вполне может и скопытиться или потерять довольно много данных. Plan B но все реальные случаи - почему-то именно с бырбырфэсе. > У EXT4 полное журналирование - капец тормозное. А без этого - он оно предназначалось для очень странного в те годы варианта быстрый журнал + медленный сторадж. Полагаю его 20 лет никто не тестировал и не проверял даже когда он появился. И оно предназначено вовсе не для защиты от крэша. > Btrfs, bcachefs и ко читерят - идея cow в том что по > сути журналом становится вся площадь. При этом более не надо переносить если не задать себе вдруг вопрос - где начало того конца которым начинаетя начало. (я, кстати, честно не знаю где у нее и как, знаю про zfs, потому что приходилось чинить. Нет, не свою, помогать другим людям разбирающимся в ней плохо. Нет, не спрашивайте как они доигрались - там все было плохо, не только не разбирались.) > А фикс консистентности делается ... простым игнором недописаного. Этого никогда не А теперь представим что это была страничка базы данных и она не совпадает с размером или алайментом блока...
	Ответить \| Правка \| К родителю #153 \| Наверх \| Cообщить модератору


	244. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Аноним (240), 11-Дек-23, 22:50
	> вообще-то иногда и коррекции (только никто в мире не умеет ее правильно применять. Да я смогу и какимнить SHA256 например 1-бит ошибку замахать. Но по мере роста числа битов на брутфорс, наивное "декодирование" станет крайне ресурсоемким. > Если бы ты не щупал однокурсницу на лекции о циклических кодах - ты бы даже знал, > какие правильные вопросы надо задать гуглю, это-то даже на ит-факультетах есть. В контексте btrfs-а меня интересует фактическое поведение self heal как ты понимаешь, а не абстрактные возможности сбития автомобилями вертолетов. > И ты НЕ НАЙДЕШЬ на них ответов. Возможно они есть где-то в документах itu-t доступных > по подписке за пару миллионов швейцарских франков, но это неточно.) Да ну и болт с ним, а? У меня вон там шикарный ридсоломон есть, а вон там "очень странный формат сигнала". Но это к делу не относится. В вон том применении оно сугубо для детектирования ошибок. И есть на выбор несколько других алго для этого. > и если нам не повезло - нет второй или обе битые - Я честно говоря такой джекпот даже на сыпучей флехе не выиграл пока. А на более нормальном оборудовании - какая вообще вероятность что у тебя на 2 разных дисках (или даже одном но исправном) сектора не прочтутся? А, это произведение вероятностей? А знаешь, вот так мне теорвер намного больше нравится. Если я вдруг смогу такой джекпот на реалистичных read error rate, числе секторов и проч - я тогда в ЛасВегас заеду, посмотреть что еще я могу. > "всеми щупальцами облизался и спрашивает - и что делать будиииим?!" Там для совсем параноиков есть RAID1C3 и даже C4. Если у тебя сразу столько сыпется - это чего? :) > Нет, чо, серьезно что-ли у вас Btrfsck не знает что полагается при этом делать?! В этом случае уже без гарантий. А вон там ext4 налетел на бэд под метаданными. Ну и вот чего он смогет? Констатировать что джеппа? Это очень ценно и полезно. И это если еще накопитель вернул io error а не выдал труху, иначе оно могло резко и внезапно скопытиться. Думаешь, CRC на журнал эти кадры от хорошей жизни налепили? Просто реплей кривого журнала - тома замешивает при случае совсем уж в спагетти имени рейзера, прищлось, вот, придумать хоть что-то. А btrfs даже на 1-девайсовой ФС хранит метаданные как DUP, что очень способствует тому чтобы не узнавать вон то "а что если". >> Чинябельность ФС зависит сугубо от наличия 2 копии (или парити) и сойдется > надо же - в ext2 нет никакой второй копии - а починить ее обычно удается. Агаблин, теорвер решил постебаться - на глаза попался EXT4 с бэдом под метаданными. Не то чтобы он вообще совсем помер - но это out of service и мануальные фиксы и потеря данных. Прости но мало кто хочет танцевать окучивая локалхост и откребая какие там еще ошметки, гоняя какие там еще fsck (что на современных объемах занимает немеряно времени). Хотят чтобы просто работало. Btrfs это и делает - пока это возможно. А если мануальное внимание надо - это всяко фейл. Ну и говоря за себя - я данные с такой штуки всяко достану, особенно с помощью вон того зала. > Забытое умение древних, неповторимый загадочный артефакт (и похоже таки да, забытое). Это как неуловимый Джо. Людям от компьютеров надо чтобы работало. А не чтобы путем заклинаний подымать труп. Если он труп, требующий мануальщины это уже фейл. Кто мне будет на управляющем одноплатнике жать эникей? И отвечать на вопросы fsck? И на сервере кстати тоже. Да и на десктопе - я проснувшись в каде порисовать собирался, а не с fsck интерфеситься. И вопрос в том какой масштаб задника. Если это 1 бэд в сто лет, DUP его зарулил и на этом все закончилось это одно. Если хардвар осыпается и его надо инить/менять - окей, и чем мне вон то знание древних поможет? Тем что спрячет от меня факап и позволит порушить больше данных? > если на картинке падают средства проверки - надо найти художника и выколоть Как там твои средства проверки ZFS'а на тему факапов с копиями копий поживают? Помнится там диагностика проблемы была весьма компромиссным костылем. > но все реальные случаи - почему-то именно с бырбырфэсе. Мде? А почему я тогда рекаверил данные с NTFS и EXT4? Если btrfs с умом юзать - он вообще нагибаться ну вот не хочет чего-то. И это... у EXT4 in place запись очень даже деструктивная, в отличие от вон того. Так что если что-то затерлось в EXT4 - это уже совсем навсегда и отменить вообще совсем никак нельзя. Этого физически более нет. А вот в btrfs можно попытаться и выцепить немного более старое состояние если ну вот реально приспичило. Запись же недеструктивана, а GC в общем случае приходит не сразу. > оно предназначалось для очень странного в те годы варианта быстрый журнал + > медленный сторадж. Полагаю его 20 лет никто не тестировал и не проверял даже > когда он появился. И оно предназначено вовсе не для защиты от крэша. А что мне вообще делать с файлом где новая голова и старый хвост предлагается? Большая часть софта ЭТО жрать не будет. Всякие сжатые форматы словят decode error - и байбай. > если не задать себе вдруг вопрос - где начало того конца которым начинаетя начало. У btrfs ответом на него является такая штука как "generation". Оно знает чего хочет (и насколько это актуально) - записи маркированы generation'ом. При серьезных расстыковках не станет маунтиться чтобы не разнести все. Мануально ессно есть ряд опций чтобы все же попытаться заякориться. Но это уже навороты и мануальщина. > (я, кстати, честно не знаю где у нее и как, Как минимум generation прописывается довольно много куда. Это нечто типа серийного номера очередного изменения, и по нему видно насколько это то что оно хотело. Если посмотреть логи офлайн вычитывалки и тому подобных продвинутых вещей - там бывает более подробно разрисовано как оно это видит - мол, это блоки такого-то файла, gen такой-то, но мы бы хотели gen такой-то, ищем дальше... > знаю про zfs, потому что приходилось чинить. Нет, не свою, помогать другим людям > разбирающимся в ней плохо. У меня btrfs тоже не разваливался. А другим... ну я вот одному гражданину пул спас, сказав что у него ssd осыпается. Он очень радовался что ему вовремя на факап указали. Btrfs это чинил и еще не осыпался, но по логам было понятно что девайс просится в мусорку. > А теперь представим что это была страничка базы данных и она не > совпадает с размером или алайментом блока... Базы по сути сами наполовину файлухи - и используют свою логику журналинга. Это 1 из причин появления NOCOW. Если кто хотел косплеить ФС, с кастомной семантикой - пусть и косплеит, зачем ему вообше мешать? А делать 1 и ту же работу (журналинг, чексуминг, ...) 2 раза - вообще неоптимально. Если кто хотел фичесет EXT4 - btrfs "до кучи" может это ему дать! Но вообще конкретику ессно смотреть надо. Не тот случай когда универсальные ответы вида "а что будет если" есть. В целом - ФС оказывается в более старом консистентном состоянии. А БД, если ее писал не совсем кретин, своей семантикой должна форсить сброс буферов и фиксацию на диске данных в критичные для нее моменты. Если оно так делало - по идее семантика сохранится, очевидный минус - синк занимает энное время, так что перфоманс БД на CoW с типовыми паттернами - такое себе. Поэтому там и есть фича прикинуться "а я типа тоже EXT4, вот вам inplace патчинг, все как вы любите".
	Ответить \| Правка \| Наверх \| Cообщить модератору


	251. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от нах. (?), 12-Дек-23, 09:50
	>> вообще-то иногда и коррекции (только никто в мире не умеет ее правильно применять. > Да я смогу и какимнить SHA256 например 1-бит ошибку замахать. все же щупал однокурсницу :-( > В контексте btrfs-а меня интересует фактическое поведение self heal практическое - kernel panic при попытке прочитать. > Я честно говоря такой джекпот даже на сыпучей флехе не выиграл пока. потому что опыт ограничен одной сыпучей флехой. А на деле оно портится в памяти. (поэтому от корректирующего кода действительно ноль пользы) > А на более нормальном оборудовании - какая вообще вероятность что у тебя на 2 разных дисках (или > даже одном но исправном) сектора не прочтутся? э... в реальном случае (один диск сдох совсем, второй из той же партии и того же возраста) - очень даже велика, но еще более вероятно что прочтутся, в обоих мусор, и это кого надо сектор (не данных) и что делать будииим? > В этом случае уже без гарантий. А вон там ext4 налетел на бэд под метаданными. Ну и вот чего он > смогет? смотря что за метаданные и что за бэд (не бывает у меня "бэдов", выкинь уже свою флэшку) смонтирует аварийно в r/o и будешь выковыривать файлы по одному, обходя поврежденное место, в самом крайнем случае. Но скорее всего fsck восстановит консистентное состояние, потеряешь только то что уже необратимо повреждено. За ТРИДЦАТЬ с-ка лет что я вожусь с этой хренью - ОДИН раз (и это - спасибо улучшайкерам, была бы там ext2/ext4 без журнала - вообще ничего бы не потерялось) восстановленное fsck оказалось проще выкинуть чем разбираться. > В целом - ФС оказывается в более старом консистентном состоянии. спасибо, вон там она оказалась в консистентном, но радости с этого не было никакой.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	253. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Аноним (240), 12-Дек-23, 19:04
	> все же щупал однокурсницу :-( Все чуть хитрее. Большую часть актуальных знаний по IT vs алго я получил путем штудирования лекций CS западных вузов, по частной инициативе, с уклоном в современный state of art и практические применения. Поэтому мои знания имеют уклон в практические кейсы. Я понимаю основы и меня нельзя напугать какой-нибудь "дистанцией хэмминга" или полиномиальной математикой, да даже то что ридасоломон на полях галуа делает. Тем не менее, я пожалуй признаю что погорячился насчет заяв что CRC совсем не алгоритм коррекции. Некое его применение в этом качестве и правда возможно, так что в этом смысле я пожалуй погорячился. > практическое - kernel panic при попытке прочитать. Я что-то сравнимое видел 1 раз. В тестах, с -rc ядрами. На специфичной конфиге. Кредитсы по итогам разбора полетов (да, я впрягся и этого бага с нами уже нет) - ушли господам из mm/ с их рефакторами - реФАКтор вышел. Btrfs-ники виноваты тем что у них вылезло. Наверное и где-то еще, просто "где баг нашелся - там и гасится". Btrfs-ники компетентно и быстро вывели на чистую воду, пнули господ mm/, те резко зафиксили, я через полдня уже вертел патч фиксящий все это великолепие. Подтвердил что трабл починен, комитнули в майнлайн, вот, отлично, релиз не профакапили. Люблю хэппи энд :P. > потому что опыт ограничен одной сыпучей флехой. Неа. Еще оно несколько раз вполне успешно парировало редкие рандомные бэды, а еще у меня появилась коллекция глюкастиков - от шнурка до проца. И даже, вот - я ж писал что чуваку с энтерпрайзным ssd пул от разлета спас. А фигли, гад делал примерно то же что и флеха, только активнее. Чувак думал что это баг btrfs. Оказалось - сыпящийся SSDшник. Я понаблюдал, он такой дажеко не 1, лучше всего на это любители bcache (не того который fs) нарываются. > А на деле оно портится в памяти. > (поэтому от корректирующего кода действительно ноль пользы) Прикинь, в моей коллекции есть и несколько битых модулей памяти. И кроме всего прочего - я пользуясь случаем и немного поизучал как именно failure mode выглядит. Это как-то так: оно обычно видит CSUM error, вопит в лог, читает 2 копию, фиксит. На самом деле это не очень надо было (на стораже данные норм чаще всего), но кроме всего прочего это чинит буфер в RAM и проч, апликухам левак не уходит. Но самое главное - кривой хардвар хайлайтится. Да, вот тут с теорвером уже не стоит в кошки-мышки играть, проиграть однажды уже вполне реально. Я даже видел пару типов которые такой джекпот выиграли. На самом деле - в "зале" есть пара граждан которые изумительно просекают это, и ор на флипнутый бит в деревьях детектят влет (там есть некий sanity check). И вот тут - если "everything failed" можно гада реально флипнуть хексэдитором, но это для тех кто понимает дизайн и может такие вещи. Актуально только если избыточности ну вот не было, иначе оно само починит метаданные из другой копии, проблема прозрачно аннулируется и никакого хардкора. При том даже на 1-дисковой конфиге оно с неких пор DUP для метаданных делает, послав всех экспертов с "SSD дедублицирует, блаблабла" в пень - real world эксперименты показали что выживаемость ФС с DUP как метаданные - улучшается. В общем ты имхо недооцениваешь мое любопытство по части странных ситуаций. Но разумеется ВСЕ возможные взбрыки btrfs я не видел и врядли увижу. Да что там, я и все баги EXT4 наизусть не знаю. > э... в реальном случае (один диск сдох совсем, второй из той же > партии и того же возраста) - очень даже велика, но еще > более вероятно что прочтутся, в обоих мусор, и это кого надо сектор (не данных) и что делать будииим? На практике - таки обычно недурно парирует. Даже, вот, отгрузку трухи протертым энтерпрайзным SSD выживало, чувак думал что это баг btrfs. Пришлось объяснить что это "хана его энтерпрайз SSDшнику", а вовсе не. > смотря что за метаданные и что за бэд Ну и с btrfs'ом все примерно так же. Тем более что метаданные почти всегда дублированы. EXT4 так не умеет, однако. > (не бывает у меня "бэдов", Угумс. И труху накопители не возвращают. А как ты с нтфс и EXT4 это проверял то? > выкинь уже свою флэшку) Зачем? Кому баг, кому фича - теперь это реалистичный стресстест косплеящий вон то, возврат гамна без IO error наверх. Я и кентовскую штуку погоняю так - когда он привинтит некоторые запчасти на место, сейчас это еще малость негуманно. > смонтирует аварийно в r/o и будешь выковыривать файлы по одному, обходя поврежденное > место, в самом крайнем случае. Но скорее всего fsck восстановит консистентное > состояние, потеряешь только то что уже необратимо повреждено. Вообще оно как бы да, неплохо чинится. Но технически это фейл: функциональность системы была потеряна, потребовалась мануальщина. Мне не надо жигуль с загаром, мне надо чтобы системы - работали. Пока это технически возможно. > За ТРИДЦАТЬ с-ка лет что я вожусь с этой хренью - EXT4 явно менее 30 лет... > ОДИН раз (и это - спасибо улучшайкерам, была бы там ext2/ext4 без > журнала - вообще ничего бы не потерялось) восстановленное fsck оказалось проще > выкинуть чем разбираться. Вот после каких-то таких прецедентов они кроме всего прочего приделали к журналу чексумы. Но между нами - это сейчас как обсуждение проблем джижка ржавых жигулей. > спасибо, вон там она оказалась в консистентном, но радости с этого не было никакой. Ну так я о чем. Когда btrfs консистентный, то и данные обычно все же - в юзабельном формате. А базы таки - кастомные зверушки. Ими вообще лучше не заниматься если не понимать основы их механики, журнала, commit/rollback и прочего, иначе горя хлебнуть можно. А если это понимать - окей, можно осмысленно стыковать фичи движка и ФС, не вижу особых проблем. И если кому надо NOCOW - пусть сам и косплеит ФС, от вон того останется только управление местом/аллокацией по сути. Но БД чаще всего именно этого на самом деле и хотели. Они б и на RAW раздел бы, если б не было столько гимора с его администрированием. А в случае сабжа - баг таки весьма нишевой вышел, бэкпортеры бэк-испортили, и весьма резво заметили :). Это даже не к EXT4 претензия как таковая.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	255. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от нах. (?), 12-Дек-23, 19:51
	> Все чуть хитрее. Большую часть актуальных знаний по IT vs алго я получил путем штудирования > лекций CS западных вузов боюсь что это уровень заборостроительного факультета. Я там вопрос задал - что надо спросить у гугля (на что он не ответит или даст только неправильные ответы) про itu-t crc ? Если бы ты нашел ту лекцию которую надо - ты бы знал на него ответ. И если бы тебя всерьез интересовала сохранность данных - ты был бы в ах...е от того на каких соплях и магических ритуалах вместо знаний построены технологии. > Я понимаю основы Чувак - основы - это вот рид-соломон. Его вообще никто не понимает, ни одна живая душа. Кроме может быть самих Рида с Соломоном но это неточно и живы ли они - сомнительно, обоим должно быть за 90. Чортова магия. Непонятная красивая матемагическая загогулина, неприменимая толком ни к какому реальному делу. На CS этому не учат, этому учат на мехмате, и то не всех. Приложили к делу - некто профессор Планк со ученики (и ученицы, но это тоже неточно). "всего" через 35 лет сумев ту писанину прочитать и придумать как ее употребить. Через ШЕСТЬ гребаных лет некто по имени Dung заметил ашиппочку. Обмишулились чуток - очень похоже что университетская типография просто листик на пол уронила, или он к предыдущему прилип. Сводящую все эти шаманские действия банально к х-ю. Вот это были - практики (ну старались, как могли). А ты - увы, в лучшем случае смог бы - скопипастить. Нет, это тоже не так легко и просто, и понадобился еще один чувак - некто Peter Anvin. Вот он уже оставил (и до сих пор валяющуюся в недрах kernel.org) внятную инструкцию - бери вот это, помножь вон на то, сложи вот с тем, и получившееся считай своими данными, раз уж часть массива накрылась. Небольшая проблемка была в том, что он это в первый раз сделал в 2002м году. А Ding нашел отклеившийся листик - в 2003м. Чуешь чем пахнет? P.S. давай проверим, читал ли ты хотя бы статью тех практиков, или сразу перешел к готовым рецептам. ЧТО в ней самое странное и на самом деле - страшное, в очередной раз вызывающее ужас от соплей на которых построена цивилизация ?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	265. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Аноним (265), 19-Дек-23, 06:23
	>> лекций CS западных вузов > боюсь что это уровень заборостроительного факультета. Меня интересуют "практические применения" и "детали реализации". Я этим пользуюсь для моих проектов - поэтому в курсе схем с неплохими соотношениями и интересными (мне) свойствами. Часть знаний optimized out, современный мир в 1 голову не лезет. > Если бы ты нашел ту лекцию которую надо - ты бы знал на него ответ. У меня ограниченный запас времени + дофига проектов которые я хочу попробовать. И перегруженный знаниями мозг ("фуллстэк" между хардом и софтом пушит меня за лимиты, но это и делает меня мощнее). Поискарь запросами? Только если gain стоит efforts! Пример: я запустил годный ридсоломон, даже на атмеге голимой ОК, сделав нехилый рефактор (и починив пару вулнов древних). Могу осмысленно параметризовать это (без лекций CS я б нихрена не понял). В паре с "странным форматом сигнала" превзошло самые дикие фантазии. Вон то расширит мои возможности так же? > И если бы тебя всерьез интересовала сохранность данных - ты был > бы в ах...е от того на каких соплях и магических ритуалах > вместо знаний построены технологии. Я частично видел. И даже сам смог некторые "ритуалы". После трансляций старинных рун из int в bin, без уверенности 100% эквивалентности... "signal acquired" сказало фирмваре =). Этого комбо никогда не существовало. Слишком примитивно для инопланетян, слишком сложно для землян. Мне стало интересно "а работает ли"? Я нашел ответы на свои вопросы. "В воздухе повисло присутствие". Теперь я знаю как это. В небольшом bias между рандомом и почти рандомом - бесконечность. Кстати, новомодный LDPC - научная версия "highly likely" вообще :P. Никаких ГАРАНТИЙ вообще IIRC нету. Зато соотношение DATA/FEC хорошее, за что и популяризовался. Правда в основном в эфирных делах. Меня больше это в контексте FEC интересовало. >> Я понимаю основы > Чувак - основы - это вот рид-соломон. Его вообще никто не понимает, > ни одна живая душа. Не все же такие мощные как те Древние. Обычный землянин с тех правил математики поделит на ноль. Но я смог отрефакторить за древними рунические письмена на древнем диалекте си, ничего не сломав и (после чтения paper'ов) дописав пару штук, посмотреть тонка ли у меня кишка. Заодно узнав на своем заду почему таблицы "с константами от богов" в рантайме считать плохая идея. Зато, вот, таблицы в RAM могу теперь генерить примерно как некоторые CRC, в фирмвари это выбор "flash size" VS "RAM usage". Для этого таки пришлось немного въехать в странноватую полиномиальную математику. > Кроме может быть самих Рида с Соломоном но это неточно и живы ли они - сомнительно, > обоим должно быть за 90. ЧСХ они изначально сформулировали свое добро заметно иначе чем это делают современные реализации. > Чортова магия. Непонятная красивая матемагическая загогулина, неприменимая толком ни > к какому реальному делу. Я прицепил эту загогулину корректировать ошибки, правда, по воздуху, в той черной магии как раз не выделяется, остальное получилось под стать :). И да, они в оригинале сформулировали это заметно иначе. Современные объяснения заметно отличаются, в реальном коде - еще больше отличаются. > На CS этому не учат, этому учат на мехмате, и то не всех. Остальные с ума сойдут от такой математики. Но вон тем не покажут как это эффективно делать на реальных микропроцессорах с разумными параметрами. Это знание вообще есть у считанных единиц Древних на всю планету. Которые как-то смогли в оба мира. Их немного. Кст в вике где-то есть объяснение декодирования ридсоломона на тупом примере, для самых маленьких, экстраполяция на мелких числах, графически, показывающая "core" идеи. ЧСХ - нет, ЭТО не в статье про ридсоломона, ибо нефиг :). Операции над полиномами тоже найти можно но тоже в одупляемом виде где-то в сторонке. Или, вот, лекциях CS западных вузов, более нацеленных на то чтобы студень мог если не накодить свой - так хоть осмысленно юзать и рефакторить чужое. С пониманием почему оно такое и что он делает. > или он к предыдущему прилип. Сводящую все эти шаманские действия > банально к х-ю. Это ты про одно из современных описаний RS как частного случая BCH чтоли? > Вот это были - практики (ну старались, как могли). А ты - > увы, в лучшем случае смог бы - скопипастить. Я таки - вот - рефакторнул и даже отсебятины немного докорябал. Хоть и очень примерно понимал что я делаю, но имеючи рунические таблицы древних я мог сравнить результат да посмотреть лажается мой код или нет (да, я никогда не настаивал что я эксперт в операциях над полиномами транслироваными в двоичную систему). > - некто Peter Anvin. Вот он уже оставил (и до сих > пор валяющуюся в недрах kernel.org) внятную инструкцию - бери вот это, > помножь вон на то, сложи вот с тем, и получившееся считай > своими данными, раз уж часть массива накрылась. Я как ни странно больше с парой других реализаций развлекался, они больше для передачи данных в неидеальном мире - а я именно этого и хотел. Для блочных дел - как я понимаю ридсоломон может быть весьма урезанный, там предполагается что все "erasures" известны. В случае comm мы далеко не всегда знаем где у нас erasures и там соответственно полное декодирование. > в 2002м году. А Ding нашел отклеившийся листик - в 2003м. > Чуешь чем пахнет? Каким-нибудь факапом. Но как я уже сказал - не понимаю почему ты уверен что я прошел тот же путь что и ты, изучая это все дабы не быть абизяной и понимать что я делаю и почему, и даже иметь возможнось read/write этого кода. Что так то полезно - минус 2 вулна за дидами с референсом отрицательных индексов и переполнениями int-ов :) > P.S. давай проверим, читал ли ты хотя бы статью тех практиков, или > сразу перешел к готовым рецептам. ЧТО в ней самое странное и > на самом деле - страшное, в очередной раз вызывающее ужас от > соплей на которых построена цивилизация ? Тех - это каких? CSовские лекции западных универов неплохо описывали именно то что я видел в фактической реализации. Это позволило довольно комфортно в ней шариться и я смог позволить себе рефактор и фикс вулнов, и даже оптимизации, понимая граничные условия и проч. А вот диды в этом деле слажали - и повесили пару вулнов. Что в коде потенциально кушающем random (или НеРандом) из эфира меня несколько напрягает. Почему-то.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	159. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Аноним (153), 10-Дек-23, 17:53
	> Мигрируй на бтрфс Там даже конвертор EXT4 -> btrfs есть. Но вот это - таки не рекомендуется. Это работает, но структура ФС неоптимальная, экзотичная и так можно получить странные баги.
	Ответить \| Правка \| К родителю #5 \| Наверх \| Cообщить модератору


	213. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от нах. (?), 11-Дек-23, 09:23
	>> Мигрируй на бтрфс > Там даже конвертор EXT4 -> btrfs есть. Но вот это - таки > не рекомендуется. Это работает, но структура ФС неоптимальная, экзотичная и так > можно получить странные баги. блжад, да в каком месте у вас хоть изредка бывает не так?!
	Ответить \| Правка \| Наверх \| Cообщить модератору


	242. "Выпуск Debian 12.3 отложен из-за проблемы, приводящей к повр..."	+/–
	Сообщение от Аноним (240), 11-Дек-23, 21:52
	> блжад, да в каком месте у вас хоть изредка бывает не так?! Чудак. Файлуха при этом врапает себя в свободное место имевшейся ФС. 1) Это довольно неоптимальная аллокация, делали не "как лучше" а "уж где нашлось место". Поэтому перфоманс такого комбо - ну вот как повезет. 2) Лэйаут ФС при этом весьма экзотичный, и если хотелось потестить код в редко используемых закоулках на странных комбо - это можно. Вот прям ща - оно, таки, вроде уже работает без особых приколов. Но с учетом 1) все равно очень на любителя комбо. 3) Если хочется побыковать на глючность фичи - окей, оно глючно по сравнению С КЕМ? Кто так вообще еще умеет? Я еще у кента какие-то зачатки этого видел. Ну он с его cow дизайном тоже может попытаться такие фортели в принципе. Для реализации такого пируэта надо CoW с write-anywhere структурой. Иначе номер не получится. Ведь надо втискиваться уж где есть место.
	Ответить \| Правка \| Наверх \| Cообщить модератору