btrfs обкакалась

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

Какой-то там русский специалист поливал ее говном – наверное он был прав все таки.

Причём система в нормальное состояние не возвращается

Даже если переподключить своп с помощью swapoff -a и swapon -a?

русский специалист

Ты про эдуарда шишкина что ли?

Ты ж зюзевод, можно поставить вкуснейшее LTS-ядро и кайфовать

Какой-то там русский специалист поливал ее говном

Если про Эда, то он, в принципе, всё и всегда поливает говном. Вообще не показатель, короче.

«Хозяйка - &дь, салат - говно, котлеты из конины …» by Эд Шишкин

Может и так, но тут он, похоже, был прав.

Хорошая идея, но я что-то об этом не подумал.

Кстати, я не знал, что в Сузе Tumbleweed есть LTS ядро. Я за какими-то фичами гнался в новом ядре, вот и догнался )

ext4 недавно портила данные, баг попал даже в LTS-версии ядра. Косяки в дизайне? XFS недавно портила данные. Тоже дизайн хреновый? Btrfs, что характерно, данные не портит, дисковый формат, в отличие от двух других названных, стабилен и настолько совместим в обе стороны, насколько возможно. При этом регулярно вылазит говнокод типа того, что в ОП или того случая, когда бесконечно дефрагментировались файлы нулевого размера, убивая диски. Из этих двух зол я предпочту говнокод, который хотя бы данные не портит, в любой день недели.

Может и так, но тут он, похоже, был прав.

Два раза в сутки сломанные часы тоже показывают правильное время.

Недавно появилось, теперь собирают, в Slowroll оно по дефолту должно быть.

Откатился на 6.9.9

Чисто в качестве идеи: а может на другую FS откатиться? Ну очевидно же, что это далеко не первый и явно не последний раз. Или это специально, чтоб скучно не было?

Вспомнился бородатый анекдот:

Кошка рассказывает своим подругам:
Представляете, вчера иду по соседнему двору, вдруг меня поймали местные коты и изнасиловали. Сегодня снова иду по этому двору - меня опять поймали и изнасиловали. Завтра опять пойду…

btrfs она багучая, но фичастая. И хочется, и колется.

Чисто в качестве идеи: а может на другую FS откатиться?

Только ext4, только стабильность 😐

ext4 тоже периодически обсирается.

Если пользоваться стабильными релизами ядра, то вполне окей. На нестабильных (то есть не LTS с минорной версией больше 10-15) тоже маловероятно столкнуться с проблемами, но шансы есть.

Many other projects have CI tests that are required to pass before a new release can ship. If that had been the case for LTP, this regression would have been avoided. What’s more, the problem was reported to affect 6.1.64 during its -rc period, but no action was taken to fix that release. 6.1.64 was released with the problem four days later.

Ахах. Типикал линукс.

Я за какими-то фичами гнался в новом ядре, вот и догнался )

Так может все таки ядро есть виновником твоей проблемы?

Да уже перетёрли в рассылке. В следующей 6.10.x будет откат.

Говорят, он пофиксен в 6.11-rc4

Не, это не фикс, это лажа. Он не работает.

Du просто подсчитывает занимаемое место. Если и обычный запустить на sudo du -sh /home он повиснет из-за огромного числа файлов. Мне сдаётся твои темы - это троллинг тупостью

Раз в неделю что-то случается с btrfs, зачем вы (все) её используете? :D

(для тех кто ей использует специально вылавливать баги и всё такое вопросов нет)

Хотя с другой стороны как ещё улучшать если не перебрать все грабли лбом. Зато потом будет норм =)

Может и так, но тут он, похоже, был прав.

Раньше тоже так считал. Но на дистанции создалось впечатление, что это случайное совпадение, ибо btrfs оказалась говном, а Шишкин все поливает им же.

6.10 вообще какое-то неудачное. Снова отломали часть усб-устройств (делают это не менее периодично, чем ломают и так не очень здоровую btrfs).

Если и обычный запустить на sudo du -sh /home он повиснет из-за огромного числа файлов

На ext4@lvm@dm-crypt@nvme ничо не виснет)

Речь про btrfs и алгоритм работы утилит типа du. Выполняется она долго. А та что часть btrfs ещё и по особому работает расчитывая не просто место, инкрементируя размер всех файлов, а «немного» сложнее от чего выполняться может на порядок больше

Интересно, чем обусловлено такое переусложение.

Может тогда лучше разнести фичи по слоям? lvm, dm-crypt, вот это всё.

ext4@lvm@dm-crypt

Где же в этом бутерброде контроль целостности данных?

Может быть коровой? :-) даже при обычном вызове cp в btrfs по умолчанию не происходит реального копирования данных.

но разумеется все отправлявшие пострадавших на linuxatemyram.com сделают вид, что они не причём

контроль целостности данных

(криптографический) хеш данных - это не про целостность.

Аутентификация этим хэшем — вполне себе гарантия целостности. Только его там по умолчанию нет, а если включить, то это будет печально, как и многие другие вещи в бутербродах из device-mapper и традиционных ФС.

Аутентификация этим хэшем — вполне себе гарантия целостности

Аутентификация - это гарантия (твоим словам). Причем это криптографическая «гарантия», которая про «люди не знают обратной функции». Это про незнание, а не про целостность.

Вот например я «знаю» и специально записываю данные, которые имеют коллизии хешей. Какие здесь гарантии?

Где же в этом бутерброде контроль целостности данных?

Где-то на уровне dm-crypt. За более чем десять лет ни разу данные не терялись и фс не корраптилась на самых жестких сценариях вроде пропадания питания в режиме «вот те раз, и так каждые три минуты» (забытый файл-сервер как-то простоял в таком режиме все выходные, когда упс заглючило).

не использую dm-crypt и подобного, с аналогичным количеством отрезаний, тоже ничего не корраптилось. журналируемые фс, чё

отрезаний

отрубаний(системы)

Где-то на уровне dm-crypt

Там этого нет. Есть в dm-integrity, который удваивает запись в полноценном режиме работы (но режим с bitmap не так плох, справедливости ради). В случае повреждения данных на диске dm-crypt не выдаст ошибку I/O, он просто успешно расшифрует мусор.

За более чем десять лет ни разу данные не терялись и фс не корраптилась

У меня тоже, но вот такие вещи в принципе бывают: наткнулся на сбойные сектора на очередном nvme ssd

Плюс такая вещь, как ошибки в оперативной памяти, которые могут испортить данные в файлах. Но здесь уже ни Btrfs, ни ZFS ничего не обещают, хотя в документации Btrfs упоминается, что часть ошибок в RAM она обнаружить сможет. На практике, конечно, никаких гарантий. У меня с посыпавшейся памятью Btrfs успешно записала битые файлы с корректными CRC.

Это про незнание, а не про целостность.

Authenticated encryption позволяет понять, корректны ли данные. Были они повреждены случайно или умышленно — значения не имеет.

Вот например я «знаю» и специально записываю данные, которые имеют коллизии хешей.

Удачи в поиске коллизий к какой-нибудь SHA256.

Какие здесь гарантии?

Примерно как с уникальностью UUID — достаточные для конкретной области.

Только reiser4 без багов

Удачи в поиске коллизий к какой-нибудь SHA256.

Допустим, у меня есть два и более блоков данных с однаковым sha256 (не важно как я их получил), как мне сохранить эти данные в «файловой системе поддерживающей целостность на гарантии отсутсвия таких коллизий»? Мне дадут обналичить кошелек Сатоси и обвалить курс?

Колбасы в дореволюционные времена зватся сервилатом могли, если в них присутствовала конина. Хочу котлеты из конины

Ну, если твои «два и более блоков данных» имеют одинаковый sha256 учитывая границы экстентов и псевдослучайную соль, которая подмешивается при хэшировании — я думаю, тебе нужно переставать сидеть на LOR и идти стричь бабло, работая предсказателем будущего.

Да нет там никакого переусложнения, st_blocks точно так же хранится в иноде, как и всё остальное. Просто кому-то очень уж охота нанести чушь.

То есть, если у меня есть такие «бесценные» данные, то их нельзя сохранить и прочитать(!) в этой файловой системе. Эта файловая система не для «бесценных» даннных, только для «ценных», и ценность данных измеряется не субьектом, а объектом хранящим данные.

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

Выкладывай уже свои разные блоки с одинаковым SHA256. Большие не обязательно, 512 байтов хватит 😂

ext4 недавно портила данные
XFS недавно портила данные

————

Btrfs
когда бесконечно дефрагментировались файлы нулевого размера, убивая диски.
убивая диски

————

Из этих двух зол я предпочту говнокод, который хотя бы данные не портит

Ниче так предпочтение. Или данные на убитом диске уже не данные и поэтому этот баг можно не причислять к порче данных?

У тебя нет таких данных, и ни у кого нет. Иди гуляй уже, и на досуге почитай, что такое «соль».

P.S.: Это не Git, эта файловая система не content-addressable. Коллизия хэшей между двумя экстентами, даже если г-дь б-г снизойдёт до земляшки и она случится, абсолютно ни на что не повлияет.

Или данные на убитом диске уже не данные и поэтому этот баг можно не причислять к порче данных?

Можно. На этот случай у тебя есть резервные копии. В случае с порчей данных на ФС без контроля целостности у тебя с большой вероятностью резервные копии уже содержат эти же битые данные.

всё это ваше сжатие в фс развод в итоге

что такое «соль»

Сколько соли надо 4 литровую кастрюлю борща?

Какие объективно измеримые гарантии дает «соление» с sha256, по сравнению, например, c CRC или кодом Рида-Соломона?