The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

Оглавление

Релиз ядра Linux 6.2, opennews (??), 20-Фев-23, (0) [смотреть все]

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


164. "Релиз ядра Linux 6.2"  +/
Сообщение от Аноним (82), 20-Фев-23, 21:46 
ололололо, ты ещё не все грабли бтрфс собрал, давай, досвидания, увидимся в комментах под следующим релизом, а потом под следующим и так ещё лет 10
Ответить | Правка | Наверх | Cообщить модератору

189. "Релиз ядра Linux 6.2"  +/
Сообщение от DEF (?), 20-Фев-23, 23:26 
Тише, луддит. Не кипишуй. Я юзаю Btrfs с 2012 года и за все это время ни одного бита не потерял. Так что, если ты любитель собирать грабли там, где их нет - то я тут причем?
Ответить | Правка | Наверх | Cообщить модератору

266. "Релиз ядра Linux 6.2"  +/
Сообщение от Аноним (266), 21-Фев-23, 09:42 
Если диски, на которых была btrfs +/- часто подключались к ПК, то ты bit-rot и при любой другой конфигурации не заметил бы.
Ответить | Правка | Наверх | Cообщить модератору

191. "Релиз ядра Linux 6.2"  +/
Сообщение от DEF (?), 20-Фев-23, 23:33 
Свое протухшее железо обнови. Специально для тебя месседж от разрабов btrfs:

If you use unreliable hardware and don’t know about that, don’t blame the filesystem when it tells you.

Так что, ара, ты кто такой? Давай, досвиданья!

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

224. "Релиз ядра Linux 6.2"  +1 +/
Сообщение от Аноним (-), 21-Фев-23, 01:47 
Эти дятлы еще и dmesg не читают когда там система матюкается, игнорят кучу глюков компа от битой оперативки или глюкавого проца - а виновата потом ФС почему-то.

Btrfs в таких случаях хотя-бы жестко вопит в dmesg на тему CSUM ERROR - и тут уж сразу понятно чот дело тут не в ФС нихрена. А самодиагностика систем все же избавляет от кучи дурных проблем. Не, намного лучше когда ntfs или ext4 какой якобы-прекрасно работает - но только потом "почему-то" внезапно совсем сыпется и оказывается что вместо данных и метаданных там давно труха, просто это не замечали.

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

238. "Релиз ядра Linux 6.2"  +/
Сообщение от Аноним (238), 21-Фев-23, 03:49 
> а виновата потом ФС почему-то.

Конечно, ФС не виновата в проблемах процессора и оперативки.

> вместо данных и метаданных там давно труха

В них есть контрольные суммы для метаданных.

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

У дисков есть самодиагностика под названием S.M.A.R.T. Не платить за надёжность сверх NTFS/ext4 нормально в той же степени, что и собирать комп без ECC-памяти. Конечно, космический лучъ может поразить оперативку или какой-нибудь незащищённый контрольной суммой буфер внутри накопителя, но некоторые всё равно считают, что ZFS и ECC RAM - это слишком дорого. А Btrfs - особый случай, когда её исследовали в 2019, нашли 4 бага и отметили, что она не только хорошо обнаруживает ошибки, но и хорошо не поддаётся восстановлению после них.
>  It is the only file system where four of the six error modes can lead to a kernel crash or panic and subsequently a file system that cannot be mounted even after running btrfsck.
> https://www.usenix.org/system/files/atc19-jaffer.pdf

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

359. "Релиз ядра Linux 6.2"  +/
Сообщение от Аноним (-), 22-Фев-23, 21:47 
> В них есть контрольные суммы для метаданных.

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

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

> У дисков есть самодиагностика под названием S.M.A.R.T.

Рассказал про него тому кто на уровне продвинутого любителя data recovery с уклоном в линух умеет. Малаца.

> ECC-памяти. Конечно, космический лучъ может поразить оперативку или какой-нибудь
> незащищённый контрольной суммой буфер внутри накопителя,

И вот даже 1 раз в цать лет я видел вой про ECC error в кеше проца, кажется. Хоррошо что там ECC был и я узнал что в него видимо и правда какая-то частица прилетела. Потому что больше я такого не видел ни до ни после, уникальный эвент. Но если ECC и чексум не было... значит нам тихонько испортят что-то.

> но некоторые всё равно считают, что ZFS и ECC RAM - это слишком дорого.

У меня так то ECC RAM на десктопнике.

> не поддаётся восстановлению после них.

Поверьте, я ее себе восстановлю. И не нуждаюсь в вашей экспертизе. Более того я знаю где ее девы обитают и так то умею с ними весьма эффективно взаимодействовать. В -rc они мне отличный баг зафиксили до того как это в проде меня огрело бы. А вы можете цитировать мне всякий булшит, если хотите. ZFS? Не, спасибо. Out of tree ФС в ядре это кусок проблем. А я еще так то и на системном разделе всем этим пользуюсь, потому что снапшоты. И если оно отвалится от апгрейда кернела - это совершенно неприемлимо. А еще я умею в валидацию поведения моих систем, тесты на -rc и проч. И гасилово багов которые меня импактят, вплоть до бисекта а иной раз и патча. С zfs я такой номер вообще повторить не возьмусь, это для мазохистов.

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

427. "Релиз ядра Linux 6.2"  +/
Сообщение от Аноним (427), 25-Мрт-23, 13:35 
>If you use unreliable hardware and don’t know about that, don’t blame the filesystem when it tells you.

Неплохой такой перенос ответственности по-умолчанию на железо. Вот бы все разработчики системного ПО так писали.

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

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру