The OpenNET Project / Index page

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



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

Оглавление

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

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


10. "В Fedora рассматривают возможность применения шифрования ФС ..."  +/
Сообщение от Аноним (10), 04-Апр-23, 14:22 
использую btrfs + luks несколько лет, полет нормальный. Баги btrfs наблюдаю только в интернетах, особенно в разделе "Комментарии". У себя багов btrfs не видал, но надеюсь наконец увидеть. Притронуться к этому единорогу, так сказать.
Ответить | Правка | Наверх | Cообщить модератору

26. "В Fedora рассматривают возможность применения шифрования ФС ..."  –1 +/
Сообщение от Аноним (26), 04-Апр-23, 14:44 
Вопрос не относится к теме поста, но все же задам его.
Как ситуация с btrfs на hdd обстоит? Сильно тормозит?
Ответить | Правка | Наверх | Cообщить модератору

37. "В Fedora рассматривают возможность применения шифрования ФС ..."  +4 +/
Сообщение от Аноним (10), 04-Апр-23, 15:04 
Помимо ssd, на btrfs + luks держу жесткий диск для кинца (не спрашивайте, зачем мне понадобилось шифровать кинцо). 2160p смотрится комфортно. Не, если начать прыгать по фильму туда-сюда, то конечно да, не сразу считывает нужные моменты. Но без нешифрованного btrfs/ext4 на том же девайсе трудно сказать, что именно тормозит -- традиционно неторопливый класс железа HDD или все-таки файлуха.
Ответить | Правка | Наверх | Cообщить модератору

131. "В Fedora рассматривают возможность применения шифрования ФС ..."  +/
Сообщение от пох. (?), 04-Апр-23, 20:23 
"но это же ж - п-ц!"

то есть у тебя НАСТОЛЬКО п-ц что банальный слайдер видео не отрабатывает мгновенно?!

Впрочем, да, cp лучше все же шифровать.

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

143. "В Fedora рассматривают возможность применения шифрования ФС ..."  +/
Сообщение от Аноним (10), 04-Апр-23, 21:03 
1920p реагирует на клики по слайдеру через треть секунды. 2160p (а я люблю видосы покачественнее, чтоб аж были видны все одноклеточные животные) может задумываться над кликами по 5 секунд в худшем случае. НЖМД, чего ты хотел?
Ответить | Правка | Наверх | Cообщить модератору

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

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

199. "В Fedora рассматривают возможность применения шифрования ФС ..."  +/
Сообщение от А (??), 05-Апр-23, 05:51 
1080p ты хотел сказать. И не благодари...
Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

176. "В Fedora рассматривают возможность применения шифрования ФС ..."  +1 +/
Сообщение от Вы забыли заполнить поле Name (?), 04-Апр-23, 23:19 
> не спрашивайте, зачем мне понадобилось шифровать кинцо. 2160p смотрится комфортно. Не, если начать прыгать по фильму туда-сюда, то конечно да, не сразу считывает нужные моменты.

Да ты сам рассказал, что за кинцо у тебя там раз прыгаешь при просмотре.

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

312. "В Fedora рассматривают возможность применения шифрования ФС ..."  +/
Сообщение от Аноним (312), 15-Апр-23, 20:16 
кoнcтитуция_рф_1993.mp4
Ответить | Правка | Наверх | Cообщить модератору

91. "В Fedora рассматривают возможность применения шифрования ФС ..."  +/
Сообщение от Аноним (91), 04-Апр-23, 17:16 
BTRFS для HDD - это чистой воды извращение. Лучше ZFS, а на худой конец EXT4 & XFS.
Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

130. "В Fedora рассматривают возможность применения шифрования ФС ..."  –2 +/
Сообщение от пох. (?), 04-Апр-23, 20:21 
ну да, ну да - для флэша-то ее 32x write amplification будет просто в самый раз.

нет, open(другой уж нет)zfs не лучше ничем и у тебя не останется даже призрачного шанса ее починить если "unable to import pool"

xfs+thin lvm или ext4+raw hdd - единственный на сегодня более-менее приемлемый выбор для тех чьи данные имеют ненулевую ценность но не оправдывают ежечасный бэкап.

Ну или ntfs. Если больше читать чем писать - то даже и не хуже. С шифрованием правда не все гладко.

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

196. "В Fedora рассматривают возможность применения шифрования ФС ..."  +1 +/
Сообщение от Аноним (196), 05-Апр-23, 02:44 
Вы не поверите... ZFS к SSD относится намного бережнее, чем BTRFS. И не окирпичивается самым случайным образом, в отличии от сабжа. И размер блока регулируется, и позволяет еще много чего, в отличии от сабжа. Не файловая система, а мечта! Не вижу у нее конкурентов от слова "совсем".
Ответить | Правка | Наверх | Cообщить модератору

211. "В Fedora рассматривают возможность применения шифрования ФС ..."  +/
Сообщение от пох. (?), 05-Апр-23, 11:01 
ну не знаю - с моей точки зрения оба хуже.
write amplification у них  примерно равны. Случайным не окирпичивается, окирпичивается неслучайным.
Но зато у того fsck, а у этой вендоутилита за деньги и несовместимая с новыми гениальными идеями.
Размер блока совсем не та деталь которую мне интересно менять. Вот отключение CoW там где он не нужен - поинтересней будет.


Каравай-каравай, каку хочешь - выбирай.

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

232. "В Fedora рассматривают возможность применения шифрования ФС ..."  +/
Сообщение от Аноним (196), 05-Апр-23, 17:04 
С отключенным CoW в BTRFS - особого смысла нет Ни csum, compression, snapshots... EXT4, XFS будет и быстрей, и надежнее данной файловой системы. Что до WA - он разный. К тому же, новая политика в отношениее metadata=dup - крайне быстро изнашивает SSD. Вдвое быстрее, чем было до этого. Натыкался даже на то, что за год ресурс падал более, чем на 50%. Когда практически все в один голос утверждают(спецы в том числе), что BTRFS - плохая файловая система... вам не приходил в голову что, может быть, так оно и есть?
Ответить | Правка | Наверх | Cообщить модератору

234. Скрыто модератором  +/
Сообщение от ivan_erohin (?), 05-Апр-23, 19:15 
Ответить | Правка | Наверх | Cообщить модератору

261. "В Fedora рассматривают возможность применения шифрования ФС ..."  +/
Сообщение от пох. (?), 07-Апр-23, 13:31 
> С отключенным CoW в BTRFS - особого смысла нет

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

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

так эскобаржпг же ж... То есть приходило, но что у нас безусловно хорошее то?

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

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

135. "В Fedora рассматривают возможность применения шифрования ФС ..."  +/
Сообщение от mikhailnov (ok), 04-Апр-23, 20:41 
После множества снапшотов начинает сильно тормозить, видимо, из-за фрагментации
Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

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

38. "В Fedora рассматривают возможность применения шифрования ФС ..."  +/
Сообщение от Вася (??), 04-Апр-23, 15:05 
у меня сдохла разок. Причем именно в тот, когда я упарывался по некоторым полезным скриптцам.
Итоги: btrfs пошла в лес, бекаплюсь почаще.
Остальные FS годами в порядке
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

48. "В Fedora рассматривают возможность применения шифрования ФС ..."  –7 +/
Сообщение от DEF (?), 04-Апр-23, 15:26 
Тухлодырое железо смени на нормальное, у которого нормально работает Flush.
Ответить | Правка | Наверх | Cообщить модератору

52. "В Fedora рассматривают возможность применения шифрования ФС ..."  +7 +/
Сообщение от Вася (??), 04-Апр-23, 15:40 
жалкое блочное устройство не достойно носить эту совершенную файловую систему? сделай-ка ты сам flush с такими выводами
Ответить | Правка | Наверх | Cообщить модератору

51. "В Fedora рассматривают возможность применения шифрования ФС ..."  +1 +/
Сообщение от DEF (?), 04-Апр-23, 15:32 
>Остальные FS годами в порядке

FS "в порядке" - а данные битые. У ext4, xfs нету чексум на данные.

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

54. "В Fedora рассматривают возможность применения шифрования ФС ..."  +1 +/
Сообщение от Вася (??), 04-Апр-23, 15:42 
и тем не менее чексуммы были, а данных не было
Ответить | Правка | Наверх | Cообщить модератору

102. "В Fedora рассматривают возможность применения шифрования ФС ..."  +/
Сообщение от Аноним (102), 04-Апр-23, 18:04 
Что именно битое? Говорите точнее.
Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

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
Добавить, Поддержать, Вебмастеру