The OpenNET Project / Index page

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



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

Оглавление

Утверждён переход Fedora Desktop на Btrfs и замена редактора vi на nano, opennews (??), 16-Июл-20, (0) [смотреть все]

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


91. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +/
Сообщение от leap42 (ok), 16-Июл-20, 15:51 
ext старается спасти файлы очень сильно, но сама фс очень хрупкая, может часами чиниться и не починиться по итогу. перевел проблемные хосты по питанию в своё время на xfs, содержимое файлов стало теряться чаще (но это всё равно, у меня были бэкапы), а количество развалов самой фс сократилось с десятков раз до нуля. а ещё fsck в 20 раз быстрее.
Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

129. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +1 +/
Сообщение от Аноним (-), 16-Июл-20, 17:18 
У ext'а действительно неплохой fsck, с точки зрения _data recovery_ но для _эксплуатации_ систем в реальных условиях радости от этого мало: системы должны работать а не отскребаться от асфальта с убиением часов времени специалистов на это безобразие.

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

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

143. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +/
Сообщение от Аноним (27), 16-Июл-20, 17:33 
> но для _эксплуатации_ систем в реальных условиях радости от этого мало

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

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

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

193. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +/
Сообщение от Аноним (193), 16-Июл-20, 20:40 
> в "реальных условиях" если данных не жалко, а важно "работать" - система
> либо восстанавливает журнал, либо выводится в оффлайн,

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

> и вводится резервная, а эта переустанавливается заново, только и всего.

И все это вот прям с федорой, прям на десктопе? :)

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

Это на совсем уж крайний случай - когда данные все же очень надо и это именно data recovery а не эксплуатация уже.

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

Там офлайн чтец забавно сделан, равно как и структура ФС. Кроме всего прочего, на сторажах есть МНОГО валидных точек входа, начиная с которых можно попытаться распарсить иерархию. Возможно получив чуть более старый но валидный и читаемый вид оной, например. Ну вот не попало разрушение под более старые копии - и тогда номер прокатит. CoW же не разрушает данные и метаданные вот прямо сразу - и это дает лишние шансы на рекавери БЕЗ хексэдитора в случае когда все совсем плохо. Ext'ы разумеется этим не снабжены - если те метаданные которые есть не прокатили, это 100% облом уже.

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

244. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +1 +/
Сообщение от Аноним (27), 17-Июл-20, 07:51 
> И вот эта вот вторая часть балета бывает достаточно не прикольной.

ну так тебе "важно работать", или где?
Если это васян-локалхост, то постоит, пока его чинят.

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

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

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

> Там офлайн чтец забавно сделан, равно как и структура ФС. Кроме всего прочего, на сторажах есть
> МНОГО валидных точек входа, начиная с которых можно попытаться распарсить иерархию.

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

> CoW же не разрушает данные и метаданные вот прямо сразу

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

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

292. "Утверждён переход Fedora Desktop на Btrfs и замена редактора..."  +/
Сообщение от Аноним (-), 17-Июл-20, 20:22 
> ну так тебе "важно работать", или где?

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

> Если это васян-локалхост, то постоит, пока его чинят.

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

> способных разобраться в причинах) или для дальнейших разбирательств - в конторах победнее.

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

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

А вот и фиг. Фэйсбук с их юзкейсами неплохо прозвонил core системной механики файлухи. И неизбежно обезглючил его. Да, RAID56 это конечно не поможет - фэйсбук таким не пользуется в силу специфичных, скажем так, свойств и грабель RAID56 как технологии.

> Ему a) плевать на сохранность котиков

Неверно. Акционерам вовсе даже не плевать на отток юзерей. А если котиков пролюбливать - отток будет. Кто же будет грузить котиков только для того чтобы из пролюбили, аннулировав усилия? :)

> b) он то что ему ценно - обеспечивает дублированием и при том многократным, а чинить
> ничего не будет.

Не подтверждается git log, где чуваки с @facebook.com делают этсамое, бида-бида :P.

> А твой десктоп может и подождать твоего внимания.

А потом меня контрактор отымеет за слитые сроки и я получу меньше профита да еще обтеку репутационно. Оно мне надо? Я на линухе в отличие от др@черов локалхоста еще и работы работаю.

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

Не, я таки упер у энтерпрайзников ряд технологий показавшихся мне клевыми.
1) Я попробую откатить снапшот. Круто, быстро, через минуту все будет ЗБС, это обычный системный факап а не кончина блочного девайса.
2) Если не прокатило, ну, шыт, грузимся с бутявки, перераскатываем image системы, при том не raw а btrfs receive, который сильно компактнее и весь по делу. Минут через 10-15 будет как новое.

Что я, ламер все с нуля переконфигурять и софт 2 дня переустанавливать? :)

> Все так делают. Полный бэкап обычно не по карману и не по времени.

Я не заметил в btrfs send / (system) и /home (userdata) чего-то сложного, дорогого, да и места оно весьма умеренно. На внешний 2-терабайтник для бэкапов такого навалить можно еще несколько сотен раз и все-равно место останется.

> ну так копии суперблоков у нас - с 74го года.

Ну так там больше чем копии суперблоков. Нечто типа альтернативных view структур ФС. Чем тебе поможет копия суперблока если какое-нибудь описание экстентов ушло в астрал? А в btrfs этого самого можно попытаться из разных мест добыть, в надежде что GC еще не пришел за вон тем и вон этим и оно дескать вот с той точки возьмет да и распарсится. Это ж CoW - и он by design содержит некий ассортимент состояний, поскольку новое - "поправка" на старое, без разрушения старого. И если вон там не сработало, можно сгонять немного назад в прошлое и может быть сработает там. Или там. Или там. А в EXT состояние только одно. И если это не сработало - УПС. Приплыли, наш друг hex editor. Ну еще testdisk и photorec, однако результат в любом случае очень далек от идеала и многократно больше долботни чем если автоматический парсер смогет нащупать относительно валидные версии деревьев "на пожевать".

> Только очень редко помогает - настолько редко, что в ext4 число этих копий
> урезали на пару порядков.

Ну так правильно. Суперблоки далеко не все метаданные в ФС, мягко говоря. А как насчет собственно фактического описания размещения файлов? Это уже нифига не в суперблоке, и если это пролюбить то и файлы не прочитаются уже, только хексэдитором в ошметках копаться :P

> Целее будут и меньше обновлять критичных структур на каждый чих.

Палка о двух концах. На btrfs я при жестком зависоне контроллера флехи разок лишился 2 из 3 суперблоков. Ну вот сгруппировал падло что-то, стер большой erase block - и в этот момент повис. Профакав прилично хлама за присест, видимо (весь erase block/erase group который кантовал). Из третьей копии починилось, но вообще - close call. Остальное DUP ессно тоже зафиксил, куды он денется.

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

А таки у меня и на лаптопе бэд разок вылезал, в аккурат под метаданными. Было очень кстати что btrfs пробурчал "CSUM ERROR, corrected" вместо того что за этим обычно следует :). А в одноплатнике SD карта через годков 5 вот весело сыпанулась под libc6, и какая мне радость что это "всего 1 сектор" если оно не грузится и я подрываюсь в перди это устранять? :)

> CoW не панацея и не 100% - те самые точки входа статичны,
> иначе их невозможно будет найти -

Суперблоков опять же более 1 копии, для начального понимания чего это у нас такое вообще.

> где-то должна лежать таблица со ссылками на таблицы текущих актуальных блоков.

Ну как бы изначально - суперблоки. Однако потом, видите ли, начинает хотеться основные деревья в не очень убитом состоянии, если вопрос в том чтобы из ФС что-нибудь вынуть.

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

Нового то что в результате в дисковых структурах есть некая избыточность, которую не подгреб GC. Это дает больше шансов относительно успешно распарсить основные деревья, более-менее полно и автоматически вычитав большую часть данных. А в ext4 если вон тот набор метаданных не прокатил, это полный и окончательный финиш - дальше только хексэдитор и прочие photorec'и.

Так что на мой вкус, с учетом склонности к системокрушильным делам, странным экспериментам и дата рекавери, btrfs пока-что весьма приятно себя показывал, как по мне. Я имею заметить что те кто его делал - понимали что и зачем делают. И были неплохо в курсе failure modes железа, в отличие от всяких академиков.

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

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

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




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

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