The OpenNET Project / Index page

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



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

Оглавление

Автор Bcachefs представил патчи для исправления ФС, разрушенных недавней ошибкой, opennews (??), 08-Апр-24, (0) [смотреть все]

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


78. "Автор Bcachefs представил патчи для исправления ФС, разрушен..."  +/
Сообщение от Аноним (78), 09-Апр-24, 07:00 
всегда читая новости про любую ФС делаю ставку, что в коментах напишут как потеряли данные на btrfs. Ставка всегда выигрывает, уже в архив мемов наверно можно.
Ответить | Правка | Наверх | Cообщить модератору

92. "Автор Bcachefs представил патчи для исправления ФС, разрушен..."  +/
Сообщение от нах. (?), 09-Апр-24, 09:28 
> всегда читая новости про любую ФС делаю ставку, что в коментах напишут
> как потеряли данные на btrfs

ну зачем обязательно терять-то? Неужели тебя недостаточно радует "места дофига но его - НЕТ", с перспективой копирования пятерочки терабайтов куда-нибудь тудой, а весь мир подождет?

Ентер-прайс куолити, не хрен собачий - орацл, новел и кто там еще не дадут соврать!

Жаль они еще vmware в концессию не пригласили... а, стоп, у них у самих неплохо fsck вышел который ничего не чинит.

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

103. "Автор Bcachefs представил патчи для исправления ФС, разрушен..."  +/
Сообщение от Аноним (-), 09-Апр-24, 10:37 
> ну зачем обязательно терять-то? Неужели тебя недостаточно радует "места дофига но его
> - НЕТ", с перспективой копирования пятерочки терабайтов куда-нибудь тудой, а весь
> мир подождет?

Они в новых кернелах вообще по этому поводу сдедали ... авто-GC почти пустых block groups, откосплеив идею кента с buckets.

> Ентер-прайс куолити, не хрен собачий - орацл, новел и кто там еще не дадут соврать!

Судя по гитхабу ZFS - даже не врут, у тех на гитхабе куда более злой трэш.

> Жаль они еще vmware в концессию не пригласили... а, стоп, у них
> у самих неплохо fsck вышел который ничего не чинит.

А нафиг им vmware или vmware'у - btrfs? Да и скушали уже вашу вмвару.

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

110. "Автор Bcachefs представил патчи для исправления ФС, разрушен..."  +/
Сообщение от maximnik0 (?), 09-Апр-24, 18:38 
>места дофига но его - НЕТ

Починили этот баг,уже давно, 8 лет должно быть.У ext4 не хватало инод, а у btrfs места, что сбивало с толку.А на самом деле Были напиленные полоски -страйпы: данные_методанные.Но при работе с мелкими файлами ( пишуться в методанные) или очень мелкими изменениями в БД без режима отключения COW  кончалось место на страйпе с методанными,хорошо если балансировка помогала.Сейчас добавили возможность выделение дополнительного объема для страйпа с методанными - да, это косяк разработчиков ,они не учли что методанные в COW могут нарастать нетипично быстро,что фоновая балансировка обгадиться.
Сам напаривался на этот косяк- потом в течение 5 лет проверял на приложение либрусек когда починят.Есть ещё косяк с удалением-созданием мелких файлов (баг Шишкина) - но с включенной компрессией баг сглаживается, и только специально можно будет вывести эту фс.Опять же при отключенных квотах для юзера.

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

112. "Автор Bcachefs представил патчи для исправления ФС, разрушен..."  +/
Сообщение от нах. (?), 09-Апр-24, 23:35 
> У ext4 не хватало инод

нехватка инод - это не "места дофига", это иноды кончились. Видно в df, легко отслеживается и освобождается командой rm без плясок с бубном (и решаемо при создании fs даже при статических inodes). Тут - баг by design, подпертый костыликом. И неважно насколько "давно" - важно сколько лет с этим багом жили (примерно тоже восемь). Да и костылик кривоват.

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

Можно проэкстраполировать о чем и в каком количестве не успел подумать единственный затраханный автор новой fs... ну и отойти подальше, чтоб не засыпало обломками.
(С математическим образованием у него тоже явно все плохо - судя по (опять!) выбору btree без приведения доказательств. По этой же причине работающего EC не ждите, там все куда сложнее, это в мире всего три человека понимали.)

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

116. "Автор Bcachefs представил патчи для исправления ФС, разрушен..."  +/
Сообщение от maximnik0 (?), 10-Апр-24, 08:20 
>По этой же причине работающего EC не ждите, там все куда сложнее, это в мире всего три человека понимали.)

Прошу пояснительную бригаду - похоже про эту тему 10 человек вообще читали.

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

121. "Автор Bcachefs представил патчи для исправления ФС, разрушен..."  +/
Сообщение от нах. (?), 10-Апр-24, 09:29 
>>По этой же причине работающего EC не ждите, там все куда сложнее, это в мире всего три человека понимали.)
> Прошу пояснительную бригаду - похоже про эту тему 10 человек вообще читали.

erasure codes

Можно ты воспользуешься поиском и я не буду в пятнадцатый раз пересказывать на каких ужасных соплях держится (но это неточно!) ВСЯ современная рэйд-технология?

(а французишку вздумавшего всерьез ворошить эту тему - убили и съели!)

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

123. "Автор Bcachefs представил патчи для исправления ФС, разрушен..."  +/
Сообщение от maximnik0 (?), 10-Апр-24, 12:01 
Расшифровали понял.
>это в мире всего три человека понимали

Но это не точно, есть в Петербурге разработчики, они рэйд для реального времени сделали,для видиохостингов . Статья на Хабре называлась
<Как разработчики сидели в Петербурге и тихо ели грибы, а потом написали ОС для систем хранения данных>

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

129. "Автор Bcachefs представил патчи для исправления ФС, разрушен..."  +/
Сообщение от нах. (?), 10-Апр-24, 18:54 
точно, точно - от тех троих есть пруф. (Ну и от лягушатника вроде тоже но я не видел, может врутъ!)

> Статья на Хабре называлась

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

Математику изучать пол-жизни для этого не нужно.

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

119. "Автор Bcachefs представил патчи для исправления ФС, разрушен..."  +/
Сообщение от Аноним (-), 10-Апр-24, 09:17 
>>места дофига но его - НЕТ
> Починили этот баг,уже давно, 8 лет должно быть.У ext4 не хватало инод,

При том вот это вот - как я понимаю абсолютно фатально. Ибо динамическую аллокацию инод оно не умеет. И если с data/metadata ratio не угадали - все, это полный болт, лечится только пересозданием ФС как я понимаю.

> отключения COW  кончалось место на страйпе с методанными,хорошо если балансировка помогала.

На самом деле суть проблемы опять же сводится к data/metadata ratio, а точнее к его резкому изменению. Btrfs аллоцирует место на девайсах чанками, называемыми block group. Типично оно весит около гига. В нем или данные, или метаданные. Есть режим mixed bg, когда в чанк и то и другое можно, спецом для мелких девайсов. Но в нормальном виде он не рекомендуется. А если соотношение данных и метаданных РЕЗКО меняется - и место уже аллоцировано под bg конкретных типов, возможна ситуация когда место есть, но - "неправильного типа". Как то хотели скажем данные, а есть - в метаданных. Или наоборот.

Баланс это лечит, делая радикальный GC и расчищая сколько-то места в совсем-unallocated, без конкретного типа и block groups на нем. Так что можно выделить под нужный тип места.

Кент посмотрел на это дело, и идею переиграл. Сделав аллокацию места относительно мелкими buckets по несколько мегов, которые его фс в фоне может GC'ить прямо по ходу дела. И соответственно у него этой проблемы - меньше. Btrfsники посмотрели на это дело - и несколько кернелов назад сделали - тадам - примерно такой же фоновый GC, который при случае целенаправленно расчищает почти пустые block groups. Чтобы это опять стало свободным местом без его конкретного предназначения. Что зело лучше чем мануальный пинок ребаланса. Такое вот тягание идей друг у друга. А почему нет?!

> COW могут нарастать нетипично быстро,что фоновая балансировка обгадиться.

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

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

Ну как бы специально можно любую ФС нагнуть. XFS например хтонически не любит кучу фрагментов, если качнуть торент без преаллокации на ...цать гигз - он стираться будет дольше чем качался, блин. А ext4... последний который у меня был, оказался довольно фрагментирован, его дефраг оказался не очень эффективен, и я нашел несколько очень раздутых дир, в которых были десятки-сотни тысяч файлов, и даже после стирания оных - дира не деаллоцируется, как и сказал пох. Более того - работа с такой дирой становится очень тормозной. В других ФС я не наблюдал этот эффект. Чисто EXT4'й прикол.

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

124. "Автор Bcachefs представил патчи для исправления ФС, разрушен..."  +/
Сообщение от maximnik0 (?), 10-Апр-24, 12:09 
>Ибо динамическую аллокацию инод оно не умеет.

С помощью бубна и LVM это можно поправить. Но вообще-то Ари для аллокации инод было написано.На linux.org один из участников кернел групп под расстрельный список давал на тестирование утилиту для увеличения количества инод.Отказались от утилиты, т.к риск потери информации оказался слишком большим, особенно на фрагментированной фс.

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

128. "Автор Bcachefs представил патчи для исправления ФС, разрушен..."  +/
Сообщение от Аноним (-), 10-Апр-24, 14:18 
>>Ибо динамическую аллокацию инод оно не умеет.
> С помощью бубна и LVM это можно поправить.

Получится хорошая иллюстрация на тему "given enough thrust pigs fly just fine" имхо.

> Но вообще-то Ари для аллокации инод было написано.

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

> от утилиты, т.к риск потери информации оказался слишком большим, особенно на
> фрагментированной фс.

Одна из проблем in-place дизайнов состоит в том что практически любой факап...
1) Может быть достаточно фатален, если лезет достаточно глубоко в дебри.
2) Многие продвинутые операции очень стремные.
3) Отыграть что либо взад - крайне сложно. Потому что изначально это не было предусмотрено совсем, старое состояние может быть уже разрушено.

В этом смысле cow где сперва делается копия (возможно, с изменением схемы хранения и проч) а потом на нее "перевешивается указатель" если все прокатило - в целом менее дурацкая операция, к тому же как правило прощающая случай "не прокатило". У меня как-то слетело питание при рестрайпе RAID на btrfs в другую схему. Ну, перезагрузился - да запустил заново, оно и доделалось. Можно вообще не рестрайпить явно а только дефолт сменить, новые записи будут в новой схеме. И только. А что было бы на более классическом дизайне при таком фортеле я даже представить не берусь. Фанаты сратисов и LVM могут посмотреть что там, если не лениво сетапить операцию - при том что оно потенциально может сдохнуть, вероятно, если не повезет.

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

131. "Автор Bcachefs представил патчи для исправления ФС, разрушен..."  +/
Сообщение от maximnik0 (?), 10-Апр-24, 23:21 
>Чисто EXT4'й прикол.

Но я уже несколько раз писал,разработчики костыль сделали чтобы это дело поправить.
sudo fsck.ext4 -fD

Где D optimize_extens.
Принудительно перестраивает таблицу экстентов когда из за риска потери информации это не делает фс, а дальше освободив экстенты,проверяется иноды и тоже чистятся. ( Это дело можно поправить на новых ядрах, но переписывать старый код multiblock allacator побоялись)

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

134. "Автор Bcachefs представил патчи для исправления ФС, разрушен..."  +/
Сообщение от Аноним (-), 11-Апр-24, 03:40 
>>Чисто EXT4'й прикол.
> Но я уже несколько раз писал,разработчики костыль сделали чтобы это дело поправить.
> sudo fsck.ext4 -fD

Угу, особенно "удобно" обнаружить что-то такое при работе систем которые шатдаунить, тем более надолго - нежелательно. Или там на рутфс каком. Или к вопросу о том почему современные ФС пытаются делать большинство "длинных" сервисных операций онлайн. Вон даже XFS пытается доказать что он "типа не антик". Правда туговато online scrub идет, но все же.

> Принудительно перестраивает таблицу экстентов когда из за риска потери информации это не
> делает фс, а дальше освободив экстенты,проверяется иноды и тоже чистятся.

А риск потери информации при этом остается?

> ( Это дело можно поправить на новых ядрах, но переписывать старый код
> multiblock allacator побоялись)

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

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

139. "Автор Bcachefs представил патчи для исправления ФС, разрушен..."  +/
Сообщение от maximnik0 (?), 11-Апр-24, 08:10 
>А риск потери информации при этом остается?

Гораздо меньше,в разумных пределах.При проверке диска писать на диск может только сам fsck , т.е последовательный доступ.Ставиться метка что диск нуждается в проверке если на этом этапе питание ребут.Для fsck создаётся журнал операции,т.е все сделано чтобы данные не потерять.100% гарантии может дать только Спортлото....т.к даже на самой обычной операции головка винчестера может промахнуться и не тот сектор записать.

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

144. "Автор Bcachefs представил патчи для исправления ФС, разрушен..."  +/
Сообщение от Аноним (-), 11-Апр-24, 16:18 
>>А риск потери информации при этом остается?
> Гораздо меньше,в разумных пределах.

И все же на мой вкус это все как-то многовато внимания к 1 тазику при желании всяких автопилотных операций. Где хочется чтобы просто работало и не делало мозг.

Да и на десктопе и ноуте - я работы работаю, а полдня fsck гонять в мои планы чаще всего не входит, так что фича очтак себе. И XFS с потугами онлайн scrub начал что-то подозревать. А это видимо помрет таким. А то что кто-то к таким ритуалам привык - ну, ок, могут жевать крутилки на эн терабайт fsck'ом, конечно. Это же их даунтаймы.

> если на этом этапе питание ребут.Для fsck создаётся журнал операции,т.е все
> сделано чтобы данные не потерять.100% гарантии может дать только Спортлото....т.к даже

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

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

Ну это все же экзотика. И там если оно реально так - винт у вас в обозримом времени даст дуба, снеся сервометки. Без которых он не жилец - по ним "навигация" делается и если запись промахивается, упс, девайс в обозримом будущем - умрет.

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

146. "Автор Bcachefs представил патчи для исправления ФС, разрушен..."  +/
Сообщение от maximnik0 (?), 11-Апр-24, 22:23 
>полдня fsck гонять

Это что за объемы....4 Тб диск у меня проверяется 6 минут, при этом заполнен был на 85%.
Надеюсь все таки допилят verity для включение в ext4. :-)

>Ну это все же экзотика.

С современной плотностью записи ?То то же  надёжность и "моточасы" падают у жёстких.

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

152. "Автор Bcachefs представил патчи для исправления ФС, разрушен..."  +/
Сообщение от Аноним (-), 14-Апр-24, 15:45 
> Это что за объемы....4 Тб диск у меня проверяется 6 минут, при
> этом заполнен был на 85%.

От содержимого еще зависит и ряда других факторов. А если несколько больших винчей в RAID... ну в общем не особо масштабируемое решение получается. С дурацикими дайнтаймами.

> Надеюсь все таки допилят verity для включение в ext4. :-)

Ну, лично мне оно уже...

> С современной плотностью записи ?То то же  надёжность и "моточасы" падают у жёстких.

1) Моточасам относительно пофиг - моторчик тот же самый, плюс минус.
2) Желание чтобы чексумы подстраховывали - в том числе и на случай если FEC/фирмварь/etc сделает какую-то фигню. А чем чаще оно прочло какой-то мусор, тем вероятнее что случится неведома фигня, в том чсиле и выгрузка шумов океанов марса.

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

154. "Автор Bcachefs представил патчи для исправления ФС, разрушен..."  +/
Сообщение от maximnik0 (?), 15-Апр-24, 23:57 
>1) Моточасам относительно пофиг - моторчик тот же самый, плюс минус.

А износ муфт скольжения или подшипников?Раньше пару микрон люфт было по хрен,сейчас уже вынуждена электронника головку отслеживать,иначе запишет не туда.То есть сейчас с радиальным небольшим биением спокойно могут записывать жесткие- видел презентацию рекламу WD -по краям 2 считывающие головки,там много преимуществ такого размещения,отслеживание краев соседних дорожек одно из них.Специальная микропрограмма высчитывает траекторию эллипса и делает корректировки.А без этого ресурс жестких оказался на 18-30% меньше.

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

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

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




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

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