The OpenNET Project / Index page

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



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

Оглавление

В Fedora рассматривают возможность применения шифрования ФС по умолчанию, opennews (ok), 04-Апр-23, (0) [смотреть все]

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


59. "В Fedora рассматривают возможность применения шифрования ФС ..."  +/
Сообщение от Аноним (26), 04-Апр-23, 15:49 
> Баги btrfs наблюдаю только в интернетах

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

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

65. "В Fedora рассматривают возможность применения шифрования ФС ..."  –3 +/
Сообщение от Самый умный из вас (?), 04-Апр-23, 16:07 
Шишкины сказки
Ответить | Правка | Наверх | Cообщить модератору

145. "В Fedora рассматривают возможность применения шифрования ФС ..."  +/
Сообщение от maximnik0 (?), 04-Апр-23, 21:09 
>Шишкины сказки

Которые легко проверяются.Сейчас с включенным сжатием и простым однообразным мелким заполнением (типа dd=11 )не сломаешь фс,сработает сжатие,человек проверял.А без зжатия дела плохо,метаданные растут как тесто на дрожжах (была статья где человек проверял слова Шишкина).Также если работать  на индексацию с sqlite c очень мелкими блоками журнала без опции nocowdata ,вы охренеете посмотрев на метаданные.Скорее всего фс не поломаете,т.к сейчас при нехватке места под методанные нарезаеться еще блоки для них ,но хорошего мало.

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

188. "В Fedora рассматривают возможность применения шифрования ФС ..."  +/
Сообщение от Самый умный из вас (?), 05-Апр-23, 00:50 
Проблемы подвержены 10мб-ные ссд-шки?
Ответить | Правка | Наверх | Cообщить модератору

198. "В Fedora рассматривают возможность применения шифрования ФС ..."  +/
Сообщение от maximnik0 (?), 05-Апр-23, 05:31 
>Проблемы подвержены 10мб-ные ссд-шки?

Не знаю,на 10 мгб мне не удалось поставить btrfs, возникает ошибка нет места :-)
Зачем троллить ? Ясно дело что проверяется информация на 1 Тб размерах жёстких дисках, меньше лет 5 как хрен купишь кроме как б.у.С ssd  чуть по другому работает фс, там на хлам в метаданных можно не обращать внимания пока не развалиться фс, фрагментация не ощущается.

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

147. "В Fedora рассматривают возможность применения шифрования ФС ..."  +/
Сообщение от maximnik0 (?), 04-Апр-23, 21:24 
> с множеством файлов малого размера, когда метаданные весят больше самих данных и происходит заполнение хранилища "несуществующими" данными.

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

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

185. "В Fedora рассматривают возможность применения шифрования ФС ..."  +2 +/
Сообщение от Аноним (185), 05-Апр-23, 00:14 
Вставлю и я свои пять копеек.
Что было: был vps на ssd (иопсов было достаточно, выше 3-5к стабильно), oracle linux 7 с ядром UEKR5, в котором поддержка btrfs от оракла, диск около 700ГБ.
На основе этого я сделал бэкап-сервер нескольких немаленьких магазинов на битриксах, в среднем сайт содержал 1-3М файлов. Старожилы помнят, что битрикс из коробки имеет около 100к файлов, на его фоне какой-нибудь вордпресс с 200 файлами - микро CMS. В сумме по всем сайтам было что-то около 20М файлов, это навскидку, потому что btrfs не показывает кол-во inodes, их нет в этой фс. Профиль файлов был от 2кб (php битрикса) до 400кб - оптимизированные пикчи товаров.

Что я хотел: весело и просто организовать бэкап на основе btrfs с сжатием lzo (есть и zstd, но чую zstd кушает достаточно оперативы) и использованием *снапшотов*. Для этого ничего сложного нет, замаунтить раздел с опцией compress-force=lzo, и создать subvolume, в который будут помещаться файлы бэкапов, и этот сабволюм будем подвергать снапшотам.

Что я получил: первое время было классно. Все сливается, все сжимается, экономия пространства, все снапшотится - красота. Но после пары месяцев, когда пришлось удалять старые бэкапы (потому что места заканчивалось), обнаружил интересные неприятные особенности. Первое время удаления все удалялось относительно быстро, ядерные процессы btrfs-transaction и btrfs-cleaner отрабатывали по паре минут, но вроде все чистили и успокаивались. А потом начался сущий кошмар - после 2-х месяцев удаения (то есть этот бэкап сервер уже где-то месяцев 6 в эксплуатации) btrfs-transaction и btrfs-cleaner начали работать по десятку часов. Проблема в том, что когда они работают, они насилуют дисковую подсистему в отсечку. Поскольку VPS, ко мне поступила инфа, что 24 часа в день насиловать диск не стоит. И все закончилось тем, что бэкапилка со снапшотами сломалась - удаление старых не успевало отработать до поступения новых.

Итог: пошел по тупому пути, сделал ext4 с 1млрд inode-ов, оператива с подобного кол-ва инодов в шоке, но вроде как нормально работает связка ext4 + снапшоты rsync hardlinks. Бэкапы надежно сливаются, хранятся без насторожительных сообщений в dmesg, удаление также не вызывает проблем (не быстрое, все-таки каждый inode удаляется, но не более 1-2 часов на все про все). Все-таки классическая ФС ext4. Народ будет писать про bacula/bareos, borg и прочее. Но для них нужны нормальные сервера, а не вот это вот все бич-бэкапы.

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

210. "В Fedora рассматривают возможность применения шифрования ФС ..."  +/
Сообщение от Минона (ok), 05-Апр-23, 10:45 
> сделал ext4 с 1млрд inode-ов

Ну блин... шляпа 7 думаешь просто так XFS форсит?
Надо было её делать.

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

212. "В Fedora рассматривают возможность применения шифрования ФС ..."  +/
Сообщение от пох. (?), 05-Апр-23, 11:05 
> и успокаивались. А потом начался сущий кошмар - после 2-х месяцев
> удаения (то есть этот бэкап сервер уже где-то месяцев 6 в
> эксплуатации) btrfs-transaction и btrfs-cleaner начали работать по десятку часов. Проблема

а пинок в сторону btrfs balance не был попробован по незнанию или не помог?

Потому что это вот оно на первый взгляд.

(на второй это может быть неконтролируемый рост метаданных в которых она утонула и тогда не лечится)

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

240. "В Fedora рассматривают возможность применения шифрования ФС ..."  +/
Сообщение от Аноним (185), 06-Апр-23, 01:58 
Возможно, ты имеешь в виду rebalance и scrub?

Вот я с этим вопросом и вышел в инет,
С запросом гугла "slow btrfs-cleaner" я пришел на стековерфлоу,
Там были предложения по rebalance-у и scrub.
Ребаланс немного не то, это для btrfs в режиме raid (да-да, и это он тоже умеет),
Но и он был запущен - а куда деваться. Толку 0.
Скруб тоже был запущен - это помогло *замедлить* разрастание metadata,
Не убрать, а сократить. Метадата так же росла по мере обновления бэкапв.

Кстати, забыл, после ext4 я начал интересоваться по тегу filesystem for small files,
И ответ был дан так же на стековерфлоу - старая-добрая reiserfs.
Благо есть elrepo, и модуль реизерфс для стокового ядра EL7.
И в общем по моим тестам, очень неплохо показывает себя в моем кейсе (reiserfs + rsync-hardlinks snapshot), там где ext4 занимал 400гб данных, рейзерфс где-то 330гб - мелочь, а приятная экономия.
Единственное, что у него какая-то механика хеширования имен файлов,
И в дефолтном методе r5 есть коллизии, а в улучшенном tea такой проблемы нет.
Сделал на tea, проблем не заметил.
Теперь кусаю локти как воткнуть reiserfs в следующий Oracle Linux 8,
На следующем проекте.

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

235. "В Fedora рассматривают возможность применения шифрования ФС ..."  +/
Сообщение от ivan_erohin (?), 05-Апр-23, 19:22 
> после 2-х месяцев удаения (то есть этот бэкап сервер уже где-то месяцев 6 в эксплуатации)

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

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

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

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




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

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