Comments 80
клич к разработчикам
и
нет ссылки на репо проекта
2. Для NILFS2 из-за последовательной природы записи TRIM не даёт никакого выигрыша.
3. Фишка NILFS2 в том, что снепшоты делаются (а старые удаляются) автоматически каждые несколько секунд и позволяют проиграть состояние всей ФС во времени.
Тем не менее в ToDo list написано:
* Optimization for silicon disks (e.g. SSD)
То есть, что-то там ещё не докрутили.
Если у вас один файл и вы его постоянно перезаписываете — будет последовательная запись.
Если у вас тысячи файлов и меняется регулярно сотня — все равно приходите к обычному состоянию диска.
А нет, там с этим всё норм. Постоянна перезапись данных, которые не меняются. Досвидания ресурс ССД.
Отдельно доставило «Спецслужбы могли хотеть смотреть старые email и SMS». Там, что использовалась файловая БД? Врядли. Учитывая что классические БД — это хранилище поверх файловой системы — пофиг что там умеет файловая система, организация файлов в БД всё равно не позволит с этим нормально работать.
Постоянна перезапись данных, которые не меняются. Досвидания ресурс ССД.
Я такого не писал. Я писал, что ФС подобна циклическому буферу, т.е. весь ССД наоборот последовательно переписывается. Это равносильно идеальному выравниванию износа, что значительно продлевает срок службы ССД.
Отдельно доставило «Спецслужбы могли хотеть смотреть старые email и SMS». Там, что использовалась файловая БД? Врядли.
В Linux на серверах (а именно туда и стоит ставить NILFS2 для целей внутренней безопасности) для хранения почтовых сообщений действительно ОЧЕНЬ ЧАСТО используется файловый способ хранения емейл. Так называемый формат Maildir. Другой формат mbox представляет из себя большой текстовый файл, который легко парсится на отдельные сообщения.
пофиг что там умеет файловая система, организация файлов в БД всё равно не позволит с этим нормально работать.
NILFS2 даст возможность восстановить точный хронометраж изменений базы и возможность восстановить базу на любой из этих моментов. А дальше нужно воспользоваться инструментами БД, чтобы посмотреть что в ней было на тот момент времени…
Это равносильно идеальному выравниванию износа, что значительно продлевает срок службы ССД.
строго говоря, это неверное утверждение. Т.к. маппинг логических блоков (LBA) в физические страницы микросхем памяти — это задача контроллера SSD и как он это делает — это тайна за семью печатями.
В Linux на серверах (а именно туда и стоит ставить NILFS2 для целей внутренней безопасности) для хранения почтовых сообщений действительно ОЧЕНЬ ЧАСТО используется файловый способ хранения емейл. Так называемый формат Maildir. Другой формат mbox представляет из себя большой текстовый файл, который легко парсится на отдельные сообщения.
LOL. Хранить почту в БД — видимо, такой вариант не рассматривается? Намекну, что почтовики не ограничиваются только лишь postfix-sendmail-exim-courier.
строго говоря, это неверное утверждение. Т.к. маппинг логических блоков (LBA) в физические страницы микросхем памяти — это задача контроллера SSD и как он это делает — это тайна за семью печатями.
С точки зрения практики — это верное утверждение, так при любых тестах любой ССД будет писать быстрее при последовательном заполнении блоков LBA. Что говорит именно об уменьшении фактора мультипликации записи, что и экономит ресурс. На 3dnews есть тест на ресурс ССД. Они там последовательно пишут и достигают петабайтных показателей на дешёвых ССД именно по этому.
LOL. Хранить почту в БД — видимо, такой вариант не рассматривается? Намекну, что почтовики не ограничиваются только лишь postfix-sendmail-exim-courier.
Если стоит задача держать максимально под контролем переписку пользователей, то нужно поставить именно тот почтовый сервер, который максимально просто позволит достичь этой цели.
Во-вторых. Даже если стоит почтовый сервер, который хранит письма в БД, с помощью NILFS2 всё равно можно восстановить старую БД и прочитать письма средств, которые умеют работать с этой БД.
База данных — это не один файл. Вы почему-то думаете, что все почтовые сервера хранят данные в чем-то типа sqllite. Это не так. И NILFS2 совершенно не гарантирует, что если БД почтового сервера размазана по нескольким файлам — снапшот будет консистентный. Очевидно. И коли речь идет о БД для почтового сервера, то там есть свои способы "вернуться к старой версии БД" и "прочитать старые письма" (я уж не говорю о том, что Вы почему-то переоцениваете важность этой задачи, тем более, что для ее решения есть другие технические средства вроде DPI и сниффинга трафика).
На 3dnews есть тест на ресурс ССД. Они там последовательно пишут и достигают петабайтных показателей на дешёвых ССД именно по этому.
можете аргументировать свое мнение? Более того — с дешевыми ССД это вообще очень интересная история, когда они сначала работают ОЧЕНЬ быстро, а потом при заполнении данными скорость деградирует до неприлично низких значений. Поэтому… давайте не будем о дешевых ССД?
База данных — это не один файл.Если у корпорации стоит задача следить за сотрудниками, то будет подобрано именно такое решение, с которым проблем не возникнет.
можете аргументировать свое мнение?Только логически. Я подозреваю, чтобы попасть в тест с такими щадящими условиями производители дешёвых дисков приплачивают 3dnews. Этот ресурс в целом живёт за счёт рекламы от производителей железа, как я понимаю.
Вот например в Thunderbird — это 1 файл на каждую почтовую папку.
только вот маленькая деталь — thunderbird — это не почтовый сервер, а клиент.
Я подозреваю, чтобы попасть в тест с такими щадящими условиями производители дешёвых дисков приплачивают 3dnews. Этот ресурс в целом живёт за счёт рекламы от производителей железа, как я понимаю.
тогда тем более их тестам доверия нет, не правда ли?
только вот маленькая деталь — thunderbird — это не почтовый сервер, а клиент.
Это был просто пример того, что БД — это необязательно несколько файлов. Тем более можно и пользовательские /home все посадить на NILFS2. И это разумно не только с точки зрения безопасников.
тогда тем более их тестам доверия нет, не правда ли?Логика обмана другая. Тесты вопроизводимые, а иначе можно разрушить свою репутацию. А вот методика плохая, завышающая результаты. И за попадание в тестирование скорее всего берутся деньги.
Это был просто пример того, что БД — это необязательно несколько файлов
Пример неудачный. Про SQLite я писал выше. И потом сами же говорите, что архив почты Thunderbird — это несколько взаимосвязанных файлов. Где логика? Ну, и дальше дискутировать по этому вопросу как-то не особо интересно, а то мы скатимся до вопросов вроде "а что такое база данных" и чем "архив почты" отличается от "полноценной СУБД"
Тем более можно и пользовательские /home все посадить на NILFS2
Про /home внизу уже были комментарии.
https://habr.com/ru/company/ruvds/blog/477388/#comment_20936850
https://habr.com/ru/company/ruvds/blog/477388/#comment_20936502
https://habr.com/ru/company/ruvds/blog/477388/#comment_20936620
и т.д.
Кратко — в home слишком много мусора, который не нужно снапшотить.
LOL. Хранить почту в БД — видимо, такой вариант не рассматривается? Намекну, что почтовики не ограничиваются только лишь postfix-sendmail-exim-courier.
LOL. Ну а в другого вида почтовиках — имеет смысл использовать другие решения. Но это в почтовиках, что не голую файловую систему используют. (с) Капитан Очевидность.
Мы последовательно пишем файлы 1 2 3 4 5, файлы 1 2 4 5 изменились, 3 — нет. Когда цикл дойдет до 3 — он его вынужден будет скопировать. И будет его так копировать постоянно. Просто гоняя файл который не изменяется на каждый цикл.
Если мы имеем на диске 10% неизменяющихся данных, то мы получим 10% прирост записи при 1 полной перезаписи.
Ну и 50% прирост при 50% заполненности устройства.
Максимальный коэффициент усиления записи 2. Это очень мало с учётом того, что всё пишется последовательно.
Я такого не писал. Я писал, что ФС подобна циклическому буферу, т.е. весь ССД наоборот последовательно переписывается.
Для эффективной работы SSD должно оставаться свободное пространство, иначе скорость записи упадёт в разы.
Это равносильно идеальному выравниванию износа, что значительно продлевает срок службы ССД.
В SSD используется таблица трансляции. Контроллеру плевать, что вы последовательно пишете данные.
Для эффективной работы SSD должно оставаться свободное пространство, иначе скорость записи упадёт в разы.
1. Это верно только для обычных ФС.
2. NILFS2 поддерживает TRIM (хоть он ей и не особо нужен) и свободное место есть всегда.
В SSD используется таблица трансляции. Контроллеру плевать, что вы последовательно пишете данные.
Уже десятый раз отвечаю. Не плевать. Во всех тестах на запись у любых SSD всегда последовательная запись побеждает любой вид случайной записи.
И откуда же у NILFS2 возьмётся свободное место, если данные пишутся циклически? т.е. диск всегда на 100% занят данными.
Уже десятый раз отвечаю. Не плевать. Во всех тестах на запись у любых SSD всегда последовательная запись побеждает любой вид случайной записи.
Зависит от размера блока.
Размер дыры может быть увеличен nilfs_cleanerd при исчерпании свободного места.
Зависит от размера блока.
А Вы какой блок имеете в виду? Тот, который к блочному устройству относится и поддерживается FTL? Или тот, который в NAND?
Размер блока записываемых данных и его связь с размером блока в NAND.
Размер блока обычно фиксирован для блочного устройства, нет?
Причём тут вообще блочное устройство? Есть кластер файловой системы, если логический сектор устройства, есть страница NAND, есть блок NAND, состоящий из страниц. У каждой из этих сущностей свой размер.
И это логические блоки, как они раскиданы по NAND знает только проприетарный FTL.
Страницы не могут быть перетасованы между блоками. Они всегда остаются внутри одного блока. Косвенная адресация используется только для блоков, т.к. таблица трансляции на уровне страниц была бы очень тяжёлой и неэффективной.
Так что если размер данных при случайной записи будет кратен размеру блока, и данные будут выровнены по границе блока, то скорость будет соответствовать линейному доступу.
В остальных случаях возможны варианты. Один сценарий — случайная запись маленькими кусками данных, но в свободное пространство — в этом случае контроллер просто дописывает данные в пустые страницы, и случайная запись по скорости может достигать линейную.
И совсем другой сценарий — случайная запись маленькими кусками данных поверх других данных. Так как контроллер не может переназначать отдельные страницы, то он будет вынужден перезаписывать блоки целиком, а это уже долго. Скорее всего, он запишет данные в новый блок, при этом данные из старого блока все равно нужно копировать.
Я даже не знаю, можно ли драйверу SSD сказать, что сейчас будет писаться большой-прибольшой кусок и лучше это делать сразу на свободный блок NAND желательно выделив непрерывный диапазон номеров логических блоков.
Нельзя. Контроллер SSD сам понимает, что происходит. Современные контроллеры умные — имеют и RAM, и SLC-кэш. Они быстро пишут данные в свободные ячейки, а затем уже в фоне занимаются консолидацией данных.
- Для NILFS2 из-за последовательной природы записи TRIM не даёт никакого выигрыша.
TRIM не для этого. Мне кажется, что Вы просто не поняли зачем TRIM нужен.
Она никогда не переписывает старые данные и всегда пишет в новые области диска, если достаточно свободного дискового пространства.
А что она делает, когда свободного места недостаточно (что бывает в 90% случаев)?
Т.е. самые старые снимки удаляются.
Добавил в статью:
«Когда заканчивается свободное место, то самые старые снимки удаляются, а чанки перезаписываются.»
А что случается, когда свободное место в принципе заканчивается? Как при этом деградирует эффективность работы ФС? Очень многие пользователи, например, из своего хомяка делают помойку медиафайлов. А потом удивляются — почему все плохо работает.
Очевидно, что NILFS хорошо подходит только для часто изменяющихся данных, т.к. именно в этом кейсе может хорошо пригодиться история с чекпойнтами.
Еще очевидно, что производительность у файловой системы NILFS2 будет не фонтан. Т.е. она не будет СУПЕРмедленная. Но и не супербыстрая. Ее скорость будет примерно одинаково плохая всегда. Почему? Да потому что чтобы записать НОВЫЙ блок — нужно каким-то образом достать содержимое файла из старого блока. Эта проблема похожа на историю, когда SSD не может перезаписать единичный байт в странице памяти микросхемы NAND. А приходится писать страницу целиком. А они нынче могут быть бооооольшие.
Да потому что чтобы записать НОВЫЙ блок — нужно каким-то образом достать содержимое файла из старого блока. Эта проблема похожа на историю, когда SSD не может перезаписать единичный байт в странице памяти микросхемы NAND. А приходится писать страницу целиком. А они нынче могут быть бооооольшие.
Нужен ССД с очень быстрым случайным чтением, чтобы быстро читать предыдущие блоки. Например, прекрасно подойдёт Samsung PM1725 с миллионом IOPS (бу версию можно купить за разумные деньги). А запись всегда линейная и происходит довольно шустро.
Вы знаете, я узнав про NILFS2 тоже подумал, что нашёл "серебряную пулю", которая просто автоматически будет хранить состояния ФС за последнее время. Но нет! Когда свободных сегментов становится меньше %, чем указано в /etc/nilfs_cleanerd.conf:min_clean_segments приходит nilfs_cleanerd и начинает чистить старые checkpoints. И чиститит, чистит… Казалось бы должен остановиться на /etc/nilfs_cleanerd.conf:max_clean_segments, но фигвам! Он оставляет только чекпойнты за /etc/nilfs_cleanerd.conf:protection_period, который по-умолчанию 1 час.
Возникает соблазн поднять protection_period побольше для сохранения истории. Но по-видимому при этом будет возрастать риск нарваться на кончившееся место, потому что более молодые чем protection_period чекпойнты nilfs_cleanerd не будет чистить никогда.
А ещё эта NILFS2 не поддерживает ни ACL, ни xattr.
А ещё у меня на прошлой неделе бросовый раздел с nilfs2 настолько сломался (впрочем это единственный раз, когда я такое наблюдал), что ядро очень сильно заклинивало, до необходимости перезагрузки при попытке что-нибудь на него записать.
Вы смотрели на файловую систему hammer из dragonfly BSD? Тоже поддерживает постоянные снепшоты и кажется сделанной гораздо более качественно.
Думаю, имеет смысл написать какой-то скрипт, который будет раз в день (например, по завершении работы) делать снимок NILF2 и удалять самый старый снимок.
Я нашёл подробное руководство по настройке nilfs_cleaner.
Как только встаёт вопрос "ой, надо писать скрипты для автоматизации", то сразу же появляется более простой ответ — zfs всё это и так может, разве что скрипты нужны для автоматизации создания/удаления снапшотов.
p.s. А вы не в курсе, что там у RuVDS (который вы рекламируете) с "виртуалкам за 30 рублей"? Постоянное "виртуалки недоступны, оставьте свой email" — прошло уже пара месяцев, а воз и ныне там, нету… ну так хоть убрали бы тогда рекламу, раз нет возможности.
Насчёт виртуалок по 30 руб ничего не подскажу. Я передам ваше пожелание менеджерам RUVDS.
что там у RuVDS (который вы рекламируете) с «виртуалкам за 30 рублей»? Постоянное «виртуалки недоступны, оставьте свой email» — прошло уже пара месяцевТариф за 30 рублей мы подключили в конце августа. Тариф очень популярен и не только в России, за 3 прошедших месяца мы уже 5 раз закупали новое оборудование под него и каждый раз оно заканчивается за несколько часов. Сейчас в первую очередь мы удовлетворяем заявки по предзаказу. Поэтому всем желающим предлагаем оставить email на странице заказа и мы пришлем вам письмо, когда тариф вновь станет доступен.
Поэтому всем желающим предлагаем оставить email на странице заказа
Что я и сделал, почти сразу после выхода вашей статьи.
Жаль, что очередь столь большая, что растянулась на 3+ месяцев :(
У вас сайт, похоже, сломался — при переходе по вашей ссылке висит красивый баннер «нет свободных ресурсов» :)
И какую нагрузку будет создавать деланье снепшота каждые несколько секунд?
Если есть специализированный инструмент, то не вижу целесообразности делать свой велосипед.
А ZFS будет нормально работать со 100 000 снепшотов, как это умеет делать NILFS2?
Сомневаюсь, хотя не проверял.
И какую нагрузку будет создавать деланье снепшота каждые несколько секунд?
Я не могу представить задачу, под которую понадобиться делать снапшоты в таком режиме. Возможно проблема именно в этом.
Я реально не представляю, ЧТО именно вы собираетесь делать.
Выглядит как механизм создания транзакций для БД, у которой транзакционность не поддерживается.
Эта задача решается по-другому и без привлечения такого странного решения.
Условно — ну, пользователь очень активен и перезаписывает файлы постоянно. История снапшотов Вашей ФС тупо не вытянет сколько-либо большую глубину изменений. Чтобы логирование работало в режиме анального зонда — это надо запрещать админа на хосте и ставить агента для слежки. И чтоб он почти в реалтайме передавал данные на центральный сервер. Так работают многие модули, вроде СТАХАНОВЕЦ
Ну, или сбой ФС или диска — и вся история слежки слетела. ИБшники прям будут счастливы.
Еще добавлю, что полные снапшоты зачастую нафиг не нужны. ОК, я здесь немного лукавлю — у меня, например, на ноуте btrfs на системном диске и перед обновлением софта автоматически снимается слепок системы. Но это не так часто — раз, два — это реально имеет ценность. А снапшот условной помойки в node_modules в хомяке юзера… ну, такое......
Эта задача решается по-другомуЯ упомянул 5 задач.
История снапшотов Вашей ФС тупо не вытянет сколько-либо большую глубину изменений.
Откуда такое мнение? Явно вы не пользовались NILFS2. У меня на хомяке по максимуму вытягивала полгода с разрешением в 3-5 секунд в моменты активной работы. При уровне свободного пространства 70-80%.
Пользователь должен специально забивать свою папку. В таком случае глубина падает до пары дней.
Потенциально очень несложно сделать удалённую репликацию NILFS2. Так что одно не исключает другого.
Лично я несколько раз восстанавливал файлы случайно удалённые самим собой. Очень удобно.
То что для вас помойка, для юзера может быть ценнейшей вещью.
Давайте конкретный вопрос, чтобы не было разночтений и недопонимайни — умеет ли NILFS2 работать с разной настройкой глубины хранения снапшотов для разных файлов? Тогда признаю — все не так плохо, как я думаю.
Явно вы не пользовались NILFS2
А нужно? Для моих задач хватает ext4/btrfs
История снапшотов Вашей ФС тупо не вытянет сколько-либо большую глубину изменений.
Для того, чтобы так говорить НУЖНО иметь опыт использования.
Можно задать глубину защиты всей ФС. Можно выставить любое число от секунды до десятилетий. Весь вопрос в ёмкости накопителя.
Вначале я делал специальный раздел для важных файлов и защищал его с помощью NILFS2, а потом надоело и поставил целиком на /home и всё ок.
интресно было бы посмотреть на сравние скорости, как сказалось версионность на доступности
Вспомнил одну шутку — настроил я однажды автосинхронизацию папки с данными outlook'а (файлы .ost) на хранилище с версионностью файлов, т.к. это были старые архивы, в которые никто не писал.
Через два дня гиговые (в общей сложности) .ost файлы выжрали 20Gb хранилища. Оказалось, что outlook зачем-то что-то пишет в файлы и в хранилище создалась куча версий файлов.
Это я к тому, что автосоздание версий — зло, если его применять бездумно.
К примеру, что будет с этой FS, если на ней разместить лог web сервера или (что более вероятно) временную папку кеша сессий того же php?
если на ней разместить лог web сервера или (что более вероятно) временную папку кеша сессий того же php?
Так не похоже, что она для этого и была создана.....
Так /home это помойка там и .cahce и. node_modules и прочие файлы о предназначении которых можно только догадываться :)
На time machine маковскую похоже. Тоже инкрементальные копии и возможность увидеть версии файла/папки за разное время. Только TM это средство резервного копирования, а не ФС.
Процедура восстановления ФС после сбоя элементарна: при загрузке ищется последний чанк, имеющий верную контрольную сумму, и на него устанавливается суперблок. Это практически моментальная операция.
Нетривиальный вопрос. Был сбой. Произошло автовосстановление. Как восстановить те данные, которые оказались в поврежденных коммитах? Насколько я понял из статьи — история записи в NILFS2 линейная, а не древовидная. Следовательно, все последующие коммиты после восстановления и последующей записи будут потеряны. Либо все хуже. Предположим, было разветвление истории (прямо как в фильте "Назад будущее"). Мы это не заметили, а потом точка ветвления — коммит — был удален сборщиком мусора.
Как в таком случае поведет себя ФС?
Ну, и повторюсь, что явно же, что NILFS2 не страхует от повреждения самого накопителя и могут быть неучтенные баги в работе самой ФС. Поэтому бекапы она не заменяет. От слова совсем. И я не вижу из статьи есть ли механизмы контроля целостности и восстановления уже записанных данных. Типа ZFS SCRUB-механизма.
NILFS2 — пуленепробиваемая файловая система для /home