The OpenNET Project / Index page

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



"В ядре Linux 6.3 всплыла проблема, приводящая к повреждению метаданных ФС XFS"
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Присылайте удачные настройки в раздел примеров файлов конфигурации на WIKI.opennet.ru.
. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..." +/
Сообщение от Аноним (346), 31-Май-23, 23:08 
> А почистить метаданные ?

Смотря что иметь в виду под очисткой. Обычно под них выделяется 1 или несколько block group, которых потом хватает с энным запасом на рандомные флуктуации. И при обычной работе оно там себе и живет. Если data/metadata ratio радикально не меняется, пустым block groups от метаданных в ощутимом количестве браться не откуда особо.

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

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

Ну да. Однако это реально _мелкие_ файлы (немного менее 4 кило, вообще, конфигуряемо вроде даже). И их количество при типовом использоваини без сильных флуктуаций опять же. Какие-то резкие флуктуации, вот именно мелочи - откуда, опять же?

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

У меня есть и несколько SSD которые вообще никогда не дефрагались, все равно резво работают, им в разумной степени похрен да и лишние записи дефрагера им не подарок. У сабжа есть опции типа ssd, ssd_spread и discard=async. Для большей части ssd это то что доктор прописал. Можно еще commit=N добавить взяв N побольше (более 300 даст варнинг, это в секундах). Чем реже "точки консистентности", тем меньше записей и они оптимальнее. Но взамен больше свежезаписаных данных будет отброшено при крахе.

На механике дефраг разумеется полезен. Насколько именно - зависит от забитости и характера записей. А вот ребаланс - обычно не особо нужен, если не делали чего-то реально странное. Сами по себе чанки блочных групп расположены линейно, при аллокации они обычно не сносятся, и потому они не субъект для фрагментации сами по себе. Если много пустых образовалось, там да, имеет смысл. Но раз в месяц? Ну разве что если там реально хаотичная и активная файлопомойка.

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

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

Это примерно так:
- Если не очень популярная ФС и много воплей, значит там не вытоптали грабли пока еще. Для этого нужна толпа. Потому что разработчики все и вся в сложном дизайне не предусмотрят.
- Если популярная ФС и много воплей, это лишь магия количеств. Ну а у btrfs сейчас уже дофига пользователей. Один только фэйсбук поляну слонами вытоптал, напустив миллиард пользователей. Так что если оно у кого-то сыпется, возможно проблема на их стороне а не в коде этой штуки. Вот чего сейчас хватает так это глюкавого железа и юзеров которые не читают системные логи вплоть до момента когда все жестко помрет от bit rot. Тольо тогда уже поздняк.

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

Оглавление
В ядре Linux 6.3 всплыла проблема, приводящая к повреждению метаданных ФС XFS, opennews, 26-Май-23, 23:36  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



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

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