The OpenNET Project / Index page

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



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

Оглавление

В ядре Linux 6.3 всплыла проблема, приводящая к повреждению метаданных ФС XFS, opennews (??), 26-Май-23, (0) [смотреть все]

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


60. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от Аноним (60), 27-Май-23, 09:57 
у Меня тут выключали свет ежедневно. Половину года... Дак вот btrfs - при пропадании питания вообще проблемы не видит. прблемы у тех кто пытается использовать встроенный raid про который пишут четко в документациях что он НЕ РАБОТАЕТ.
Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

79. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от n00by (ok), 27-Май-23, 11:06 
В таком эксперименте важно, что в момент отказа происходит. Когда читаете Опеннет, данные на диск не пишутся, скорее всего. Интереснее позапускать btrfs balance и defrag и повыдёргивать шнур из розетки.
Ответить | Правка | Наверх | Cообщить модератору

108. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от DEF (?), 27-Май-23, 12:18 
Я более 1000 раз делал хард-ресет при интенсивной записи в БД - ФС и данные ни разу не скорраптились. Да и тебе уже сказали - свое железо тестируй и кури мануалы. Ну и руки не забудь выпрямить.
Ответить | Правка | Наверх | Cообщить модератору

135. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от n00by (ok), 27-Май-23, 14:30 
> Я более 1000 раз делал

А я изучал метрологию и понимаю, что эта цифра придумана только что.

> Да и тебе уже сказали - свое железо тестируй

Ты напрасно говоришь о себе во множественном числе - веса это не придаёт, а показывает слабость позиции.
Железо с тех пор работает.

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

270. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от Аноним (-), 29-Май-23, 03:53 
> А я изучал метрологию и понимаю, что эта цифра придумана только что.

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

Представляете, лучше уронить железку у себя эн раз и посмотреть не развалится ли, чем это самое случится у кастомера и если это сколь-нибудь массово - вот это будет настоящей ж...й! И вот тут у btrfs так то плюс: fsck вообще нет, так что и интерактив с юзером для починки не требуется.

P.s. F2FS кстати на тесте с power loss - разваливается влет. А EXT4 достаточно минимального сбоя чтения и система полностью в дауне. Один несчастный бэд под метаданными или системной либой все выносит в хлам. Такая вот занимательная метрология.

> Железо с тех пор работает.

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

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

310. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от n00by (ok), 30-Май-23, 08:46 
Я уверен, что DEF ничего не считал, и тесты не проводил. Иначе он бы и написал "какого-то такого порядка", а не 1000.
Ответить | Правка | Наверх | Cообщить модератору

330. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от Аноним (-), 31-Май-23, 05:02 
> Я уверен, что DEF ничего не считал, и тесты не проводил.

А я немного отличаю этот ник от ноля и по накопленному опыту он вроде в ФС и около разбирается несколько выше среднего по опеннету. И в каких-то вещах пришел к выводам похожим на мои.

> Иначе он бы и написал "какого-то такого порядка", а не 1000.

Не знаю как он а я мог бы и ровно 1000 циклов влепить. Допустим просто накодив фирмвару МК с таким циклом и посадив его GPIO -> RESET# одноплатника. И получит система 1000 нештатных ресетов, дешево и сердито.

На эту тему, моя имха...
- Ext4, XFS - "а что вы хотели от фс без full журнала?". Наповал обычно не мрет но консистентность состояний файлов понятно где. В Ext4 полный журнал можно, но скорость будет ацтой из-за двойной записи. CoW появился как воркэраунд этой проблемы ;).
- F2FS норовит с позором развалиться. Да так что даже fsck собрать не всегда может. Впрочем в автоматических применениях интересных мне, сама нужда fsck и интерактива - проблема. И это довольно странно для флешовой фс которая так то для околоэмбедовки больше. Даже в смарте показывать хомяку fsck - малоперспективно, имхо.
- Btrfs хз, ни разу таким методом не убился, ему ребуты вообще довольно похрен и fsck при этом не надо, cow при этом как максимум потеряет некие свежие записи. У них это и на данные и на метаданные распостраняется и чего б ему при этом дохнуть - кто б его знает.
- JFS - хз, не тестировал особо. Он медленный и печальный, на него все уже забили.
- Рейзер3 разносит тома fsck'ом и это у них "known issue", даже описаны варианты как этот issue вызвать. Это делает их fsck крайне стремным тулом. А других рейзеров вообще в майнлайне нет, для меня это showstopper.

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

337. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от n00by (ok), 31-Май-23, 15:48 
>> Я уверен, что DEF ничего не считал, и тесты не проводил.
> А я немного отличаю этот ник от ноля и по накопленному опыту
> он вроде в ФС и около разбирается несколько выше среднего по
> опеннету. И в каких-то вещах пришел к выводам похожим на мои.

Потому что он где-то что-то прочёл и эту инфу разносит. Инфа необязательно неверна, но это банальная вера, а не знания, полученные в результате опыта.

>> Иначе он бы и написал "какого-то такого порядка", а не 1000.
> Не знаю как он а я мог бы и ровно 1000 циклов
> влепить. Допустим просто накодив фирмвару МК с таким циклом и посадив
> его GPIO -> RESET# одноплатника. И получит система 1000 нештатных ресетов,
> дешево и сердито.

"Ровно 1000 циклов". А не "более 1000 раз". Ну то есть, откуда он знает, что более 1000? Считал? И как он столько насчитал?) Когда погрешность всегда плюс-минус.

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

350. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от Аноним (-), 01-Июн-23, 02:50 
> Потому что он где-то что-то прочёл и эту инфу разносит.

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

> Инфа необязательно неверна, но это банальная вера, а не знания, полученные
> в результате опыта.

Опыт тоже штука специфичная. Если вы конечно широко внедрили и попрыгали по граблям от души - там можно делать какие-то выводы. Если были шансы статистику набрать и вообще сунуться немного в тему. А если по паре кейсов делать выводы, можно довольно далеко зайти - а потом окажется что рандом прикололся или что там еще. Это же касается и быстрых выводов без детальных исследований что реально имело место быть. Откуда и пожелание деталей на развал btrfs, например. Для понимания "confidence" данных. Если вы когда-нибудь ставили эксперименты то знаете что иногда можно откушать откровенно бредовых данных, достаточно далеких от истинного состояния дел. В этом случае придется изучить ситуацию лучше и понять что реально не так. Иначе грош таким данным цена в базарный день, имхо.

> "Ровно 1000 циклов". А не "более 1000 раз". Ну то есть, откуда
> он знает, что более 1000? Считал? И как он столько насчитал?)
> Когда погрешность всегда плюс-минус.

Я тоже total count не знаю, даже если я в каком-то кейсе прогнал ровно эн, я не трекаю абсолютную сумму. Зато вот например наобум взятый SSD - злопамятный, цуко, и кажет unsafe shutdown count 107. На нем была btrfs с самого начала, сколько-то там лет. И ничего, живой.

Unsafe shutdown count это так то - "слет питания без подачи команды на standby режим". И между нами, само это по себе может привести к серьезному факапу, когда фоновая активность фимрвари девайса типа GC и т.п. столкнется с слетом питания - и в хучшем случае - улетом чего-то размером с erase group (десятки мегов) вникуда, и если это случится (имеет полное право согласно спекам стандартов), это в принципе запроектная авария для любой известной мне ФС, если не было избыточности на другом девайсе. А если кому это не нравится, нехай UPS юзает или ноут с батарейкой дескать. Ну вот такая вот оптимизация - фирмвара живет своей жизнью и может иметь свою линию поведения. И даже профакать данные если вы нарушили протокол взаимодействия. Который вот такой - вы явно уведомляете накопитель о намерении снять питание и только посое этого имеете право питание снять. Это часть спеков стандартов. Если вы это не обеспечили, это вообще-то ваш факап, так то. И там один большой UNDEFINED что случится. Но, вот, этому экспонату 107 раз повезло. Однако вы же понимаете что это без гарантий? И если на 108 раз он пролюбит большой сегмент и фс развалится - ну, окей, у SSD есть некоторые специфичные особенности, не очень приятные с точки зрения файлух. Это частично касается и "черепицы".

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

88. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от DEF (?), 27-Май-23, 11:17 
Не работают только parity-raid'ы, а mirror-raid'ы - работают.
Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

304. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от Аноним (-), 30-Май-23, 03:38 
> Не работают только parity-raid'ы, а mirror-raid'ы - работают.

Более того, поскольку там у метаданных и данных могут быть разные схемы хранения, ничему не противоречит метаданные как RAID1(может даже C3) а данные как RAID 5 или 6 - и вот такое комбо даже не страдает write hole'ом. А т.к. основной объем обычно данные, то эффективность по использованию места более-менее как у RAID5/6. Это сами разработчики такой финт придумали. Вроде реально работает, так сразу не разваливается.

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

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

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




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

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