The OpenNET Project / Index page

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



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

Оглавление

Отставка сопровождающего файловую систему XFS, opennews (??), 02-Авг-23, (0) [смотреть все]

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


53. "Отставка сопровождающего файловую систему XFS"  –1 +/
Сообщение от Аноним (163), 02-Авг-23, 16:17 
Но... в zfs НЕТ никакого fsck... ни онлайн, ни офлайн.

"destroy the pool and restore from backup" (c) горе-разработчик iX

Он над этим собрался поработать? Ну п-ц вашим данным.

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

110. "Отставка сопровождающего файловую систему XFS"  +/
Сообщение от Аноним (-), 02-Авг-23, 23:38 
> Но... в zfs НЕТ никакого fsck... ни онлайн, ни офлайн.

Там scrub есть. А в XFS даже такого - нет. Извините, ребутать сервер чтобы чекнуть что данные в порядке и диски не битые как-то напряжно.

> "destroy the pool and restore from backup" (c) горе-разработчик iX
> Он над этим собрался поработать? Ну п-ц вашим данным.

Учитывая что у редхата сбежали все блочники и ФСщики - имеет все шансы на успех.

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

116. "Отставка сопровождающего файловую систему XFS"  +/
Сообщение от пох. (?), 02-Авг-23, 23:58 
> Там scrub есть.

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

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

кто-то из Великих в свое время сравнил идею запускать fsck на смонтированной fs с попыткой хирургической операции на прыгающем пациенте.

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

134. "Отставка сопровождающего файловую систему XFS"  +/
Сообщение от Аноним (-), 03-Авг-23, 02:31 
> это распространенное чайничье заблуждение. scrub не исправляет (и даже не
> проверяет!) логические ошибки.

Я в курсе что это не онлайн fsck мистер умник. Но у XFS нет даже и такого. Там вообще так по простому вроде бы нельзя прогнать read test на used регионе пространства и посмотреть насколько сие живое. А без этого потуги мимикрии под вон тех смотрятся жалко. Потому что не будет даже намека на способность онлайн-парирования "мелких" факапов ("self heal") в нормальном виде. Конечно это линух и натянуть сову на глобус если очень уж хочется всегда можно, вопрос в том как это будет выглядеть.

> все что он делает - пересчитывает контрольные суммы. Совершенно бесполезный и ненужный
> на исправном железе процесс.

Ты явно не в курсе, что у совершенно исправного железа есть такой параметр как "read error rate". Что странно для такого великого инженера. Может ты и про MTBF не слышал? А при современных емкостях железок и погоне за емкостью, даже ценой хлипкости - это не пустое соображение. Черт знает насчет ZFS, а в btrfs сие инициирует и рекавери посыпавшейся копии из избыточности, если она есть. Если это был "мелкий" осыпон, единственное достижение это self heal проблемы. И ты врядли захочешь узнать о вон том неотремапленом бэде когда другой девайс вылетел, данные понадобились, ых, ых, ых... FAIL?! Но да, ты кажется так и не понял как эти звездные крейсера правильно пилотировать, и зачем там эта штука.

> кто-то из Великих в свое время сравнил идею запускать fsck на смонтированной
> fs с попыткой хирургической операции на прыгающем пациенте.

Чекать консистентность структур по живой ФС и правда гимор на всю голову. Хотя в какомнить btrfs и т.п. - можно и попытаться, на чуть устаревшем view. Но все равно гимор.

А еще прикольно верить в чудеса, но fsck не может починить ВСЕ мыслимые виды разрушений. Если метаданные пролюблены - то уж пролюблены. В CoW дизайне можно попытаться сгонять в прошлое в надежде что там еще не было ЭТОГО - и может получиться. Но это зависит от характера разрушений.

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

167. "Отставка сопровождающего файловую систему XFS"  +/
Сообщение от пох. (?), 03-Авг-23, 10:18 
> Но у XFS нет даже и такого.

у xfs есть офлайн. И он вполне работает. А у zfs - удалите пул и создайте заново (c)
У btrfs вроде бы есть но по отчетам - не работает толком.

> Ты явно не в курсе, что у совершенно исправного железа есть такой параметр как "read error rate".

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

> Может ты и про MTBF не слышал?

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

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

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

> А еще прикольно верить в чудеса, но fsck не может починить ВСЕ мыслимые виды разрушений.

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

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

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

211. "Отставка сопровождающего файловую систему XFS"  +/
Сообщение от Аноним (-), 04-Авг-23, 05:10 
> у xfs есть офлайн. И он вполне работает.

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

> А у zfs - удалите пул и создайте заново (c)
> У btrfs вроде бы есть но по отчетам - не работает толком.

У их дизайнов есть кое-что общее: при крахе по задумке вообще не должно как-то серьезно портиться. Если вдруг это случается, железо работает за пределами допущений типичной файлушной семантики сброса буферов, это с любой фс может стать проблемой. Борьба с запредельно кривым железом просто не основной сценарий, вариантов этой кривизны очень много. И таки по состоянию на сейчас вон тот аспект в железе все же обычно работает. Хотя как last resort конечно инструмент такого плана неплохо бы.

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

Это кто сказал? У FEC вероятность прощелкать сбой и вернуть кривые данные как якобы-валидные - отлична от 0. В этом случае второй уровень чексум оказывается очень кстати. Он другой и вероятность что и для него это тоже валидно - низкая. А вот любители обычных RAID в этом месте могут скушать интересных ништяков.

> Либо блок перечитается пока не прочитается правильно, точнее, пока его
> не удастся восстановить правильно (у prml дисков блоки НИКОГДА не читаются правильно,

В конечном итоге вопрос справился FEC или нет. Иногда FEC думает что справился - но реально это полный левак. Который сходится как решение алгоритма FEC, так что нате вам! На мелком диске читаемом раз в сто лет ты не доживешь до этого момента. А если постоянно читать терабайтами... таки можешь и дожить уже.

> читается невообразимая каша) и это совершенно нормально для современных дисков,

Ну не "невообразимая" - и FEC все же парирует ограниченное число сбоев потому что много места под FEC жаба душит отдавать.

> либо вернется ошибка, либо, чаще всего - повиснет нахрен.

Ну вообще оно обычно 1 из эн вариантов:
1) Вернет за обозримое время какой-то хлам. Который толи сошелся как решение FEC, толи просто "уж что вышло" даже если FEC не сошелся. Зависит от дури фирмвари.
2) Честно сооб IO Error.
3) Надолго задумается, делая чертову кучу повторов чтения. Совсем виснет редко, обычно у соята терпение кончается и тот начинает истерить. Для этого в винчах сделали набор команд SCT, позволяет указать фирмвари что нам таймаут операции не пофиг (иначе RAID считает девайс отпавшим, etc).

> я в отличие от тебя не только слышал, а знаю что означает.

Странно, а про read error rate вот совсем по нулям.

> Нет, твои волшебные поделки не умеют это обрабатывать.

Да вот btrfs при правильном подходе орет "csum failed ... corrected". А на жестаках в RAID я в отличие от всяких - умею фичи SCT настраивать. Оно как раз для вот этого, чтоб в таймаут по "якобы взвису" не уходить.

> пустое. Все равно твое ведро не сможет обработать.

Что оно не сможет обработать? Оно либо IO error поймает либо ФС заметит csum failed, оба случая ведут к перезаписи проблемного блока. До кучи такая логика и ремапу проблемного региона косвенно способствует.

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

Я и без супербогов в состоянии наруливать системные аспекты, типа SCT фич, так что и у меня не виснет в общем случае. Поэтому могу получить такой же результат как ты но в разы дешевле. И соломку я стелить научился не хуже вон тех. А просто потому что понимаю как оно унутрях и откуда гадостей ждать.

> Причем внутри клон zfs. Просто разработчикам платят именно за это, а не за
> докер в докере под докером.

Вот с непонятной проприетарой от супербогов за дофига денег ты там сам как нибудь и танцуй. А я и сам на олимп при нужде прогуляться могу.

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

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

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

Если это будет проблема, читать btrfs можно и офлайн. К тому же тыкаясь в разные точки входа. А в новых версиях вроде и онлайново маунтить прошлые generation научили. В надежде что разрушения всплывшие вон там - еще не затрагивали вон те варианты view энной давности.

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

Ну как бы я вот разок заметил бэд под системной либой. На эмбедовке. Очень не понравилось. С тех пор там btrfs с DUP - он такое парирует в 2 счета. Стало лучше чем было. А твой zfs так вообще не умеет просто и без гимора, он вообще не делался для таких кейсов. А хранилка прекрасно но стоит больше одноплатника и кастомеры не поймут-с.

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

220. "Отставка сопровождающего файловую систему XFS"  +1 +/
Сообщение от пох. (?), 04-Авг-23, 11:48 
> А ты радостно вырубишь продовые системы и будешь с оптимизмом гонять это, на многотерабайтных
> массивах то?

пока не будет поводов - не буду, нахрена мне ненужные проверки? Я не верю в ваши мифы и легенды про самомодифицирующиеся байтики на дисках.

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

>> никогда не доходят до операционной системы.
> Это кто сказал?

опыт.

> Да вот btrfs при правильном подходе орет "csum failed ... corrected".

а у меня не орет. Видно, что-то делаю неправильно.

А вот виснуть и портить данные - да, умеет.

> Что оно не сможет обработать? Оно либо IO error поймает либо ФС заметит csum failed

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

> Я и без супербогов в состоянии наруливать системные аспекты, типа SCT фич

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

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

235. "Отставка сопровождающего файловую систему XFS"  +/
Сообщение от Аноним (-), 05-Авг-23, 05:29 
> пока не будет поводов - не буду, нахрена мне ненужные проверки?

Это как pkunzip.zip - без чексум ты это не заметишь и будешь уверен что все ЗБС. Но на современных объемах данных и скоростях магия количеств серьезно нагибает теорвер vs "read error rate".

> Я не верю в ваши мифы и легенды про самомодифицирующиеся байтики на дисках.

Себе противоречишь. То не читает корректно никогда - то не верю в легенды. Почитай тогда как FEC работает и не тупи. Вероятность что нечто совершенно левое будет посчитано корректным решением для FEC отличается от ноля. На достаточно большом числе попыток может и проскочить. А у некоторых железок фирмвар предпочитает отдать прочитаный буфер как есть даже если FEC облажался, хз почему.

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

Поэтому онлайновый scrub с фоновым приоритетом и имеет некое право на жизнь. И таки я видел случаи когда он таки реально репайрил единичные сбои. Бывает. Хоть и весьма редко на нормальном железе. Заодно самодиагностикой подрабатывает.

> Обычный fsck а не какие-то проверки ненужного ненужно "по всей площади".

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

> опыт.

А мой опыт вот - видал несколько бэдов заруленых btrfs'ом по именно той механике. И?

> а у меня не орет. Видно, что-то делаю неправильно.

Зависит от железа, количества инстансов оного и много чего еще. В норме он конечно орать и не должен. Но случаи бывают разные. И вот раз в дохрена лет даже на ноуте случайный бэд вылез. Ну как вылез так и аннулировался. Btrfs починил данные, винч ремапнул сектор при очередной записи, и оно и дальше работало себе долго и счастливо. Так намного лучше имхо.

> А вот виснуть и портить данные - да, умеет.

В моих конфигах, вот, не виснет. А если попробует - быренько познакомится с дебагером. Если конечно это не про тормозной отклик винчей при налете на бэды, таймаут на это через команды SCT рулится, это причина их появления если что. А у некоторых серий "для RAID" оно даже активно по дефолту.

> либо повиснет, перезагрузится ресетом и убьет даже те данные которые ничем не
> виноваты, просто под руку попали. Велкам ту рил волд Нео, жри
> хрючево - осетрина твоя была воображаемой.

У меня таких страстей почему-то не бывает. Толи баги меня боятся, знают что ядебагер достану, толи я идиотских действий типа out of tree модулей рушаших память и плохо тестированых не гоняю, но вон то в моих конфигах не характерно.

> ты как обычно в состоянии рассказывать сказочки своего локалхоста или вовсе чтение
> викивракии. Про sct он прочитал, ох б-жечки ж мой (а ничего
> что в доступных тебе дисках нет никакого sct десять лет как?

Вообще-то набор команд SCT поддерживался практически всеми более-менее новыми дисками которые я видел (да, я любопытный и тыкаю палочкой в девайсы). А нет его либо в антиках либо в твердотельных где он нахрен не вперся, там и retry сильно быстрее и много попыток смысла делать меньше.

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

Знание как сделать чтобы ни...я не работало - еще менее полезное. Почему-то :). Хотя если тебя к конкурентам засылать - то, конечно, ЗБС.

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

160. "Отставка сопровождающего файловую систему XFS"  +/
Сообщение от Минона (ok), 03-Авг-23, 08:51 
Пох, ну ты не прав.
Скруб не только пересчитывает кс.
Если в процессе пересчета кс на зеркальном или raidz пуле на одном из дисков обнаружиться битый сектор, то данные будут перезаписаны в исправный.
Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

168. "Отставка сопровождающего файловую систему XFS"  +/
Сообщение от пох. (?), 03-Авг-23, 10:23 
Это не имеет отношения к scrub. Если не совпало - как и при обычном чтении, попытается прочитать другую копию (и перезаписать неправильную). Если ее нет или она тоже битая, как всегда - давайте повиснем, что-ли? Или крэшнемся, тоже интересно.
А сам scrub просто "обычное чтение" и вызывает, волшебного там нет ничего.

А нужно совершенно другое - внешняя утилита проверки что прочитался не мусор, структуры заполнены правильно и по указателю лежит что-то похожее на то что там должно быть, и если нет - попытка найти где же оно осталось (в случае zfs вполне реальная, просто откатившись на предыдущую txg) и восстановить. Независимо от того, совпадают ли у мусора контрольные суммы (может оно в памяти уже было такое и сумма-то совпадает).
Ну б-ть, это умела ms-dos 1.1


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

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

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




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

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