The OpenNET Project / Index page

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



"Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19"
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Присылайте удачные настройки в раздел примеров файлов конфигурации на WIKI.opennet.ru.
. "Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19" +/
Сообщение от Аноним (174), 06-Дек-18, 17:59 
> держи нас в курсе, админ локалхоста

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

> оно происходит только в случае, когда там уже все плохо и том
> и так разнесен в хлам.

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

> Причем его для этого надо запускать специальным образом, о чем оно раньше
> (я лет пятнадцать уже не пользуюсь) даже внятно и не говорило,
> а высовывало вместо этого табличку "заплати $25 правильным пацанам - они
> тебе починят". То есть довести до этого надо постараться.

У авторов амула оно вообще ничего не спрашивало - том перестал монтироваться требуя fsck. При попытке fsck он был доломан окончательно и сервак вынужденно ушел в даун на переустановку оси. Ну и вот лично мне системные тулсы которые работают как-то так - скажем прямо, "не очень". Я как бы допускаю мысль что Рейзер сумасшедший гений, и что у него и его команды есть крутые решения. Но, честно, для решения годного для продакшна роялит общий букет свойств. В том числе и какой-то план на случай если все обломалось. Идея недеструктивно вычитать нужные файлы из подубитой ФС мне как-то более симпатична - если не получится, можно попробовать снова. Ничего не испортив. А вот когда fsck рейзера разгромит том - undo самого по себе нет.

Кста, когда я чиню fsck'ом файлухи (это чаще всего небольшое data recovery в частном порядке), это таки reflink-копия образа обычно. Таки на этом самом btrfs'е. Хотя-бы потому что из него хранилку  на потребный размер ненапряжно делать, есть сжатие, умеет reflinks, так что можно работать как бы с "копией" образа но весить будет только отличия от бэкапного образа. Хотя формально как бы две чушки на эн терабайт. При этом я конечно закладываюсь что btrfs меня не подведет в этой механике, но по другому undo на терабайтных файликах вообще сложновато.

> Но правильные пацаны одно, а Шишкин - совсем-совсем другое, и issues там
> пока совершенно unknown. Нехай другие по ним потопчутся, я, пожалуй, пешком постою.

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

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

Как-то так он и сделан. Быстрый в некоторых специфичных допущениях, если файлы огромные и разложить на несколько устройств правильно. Файлуха для редактирования нежатого видео в общем, чего еще от SGI ожидалось? :). А разлапистые иерархии с кучей мелочи например там не рулят. И фрагментированый торент может удаляться добрых 5 минут. Ну в общем работа с метаданными у них - довольно специфичная. И даже потуги редхата это подразогнать - подразогнали, но все-равно, довольно специфичненько.

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

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

> надо -  ZIL под понятно какой fs и тоже понятно
> что он собой представляет и какие есть особенности (а они есть)

Ну а меня вот вполне устраивает что btrfs'ина сделает мне CoW и в общем случае запись будет однократной. А то что за это иногда где-то в фоне GC будет подгребать мусор - на удивление он тихий, мирный, проблем не создает. В каких-то специфичных ворклоадах наверное можно на проблемы нарваться, но для дба сделали nodatacow, а остальным вроде и так ок. В том числе мне и моей сра... кошке, простите, лаптопу, например.

> в целом - в 2005м работала, дальше не тестировали. Вполне логично, но
> опеннет, трудами неадекватов у руля, не место для лекций.

Да я и без лекций переживу - я в состоянии принять для себя решения сам. И отдуться за них потом. Даже если ситуация окажется отличной от идеала.

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

Оглавление
Выпущен патч, решающий проблему с ext4 в ядре Linux 4.19, opennews, 05-Дек-18, 09:53  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



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

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