company_banner

NILFS2 — пуленепробиваемая файловая система для /home

  • Tutorial


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

Если вы — хостер или владелец сайта, то, наверное, сталкивались со взломами пользовательских аккаунтов или своего сайта. В таких случаях важно восстановить хронологию, найти способ проникновения и уязвимость, которую использовал злоумышленник.

Для решения подобных проблем прекрасно подойдёт файловая система NILFS2.

Она присутствует в ядре Linux, начиная с версии 2.6.30.

Особенностью данной файловой системы является то, что она подобна системе контроля версий: вы всегда можете откатить состояние системы назад и посмотреть на то, какой она была некоторое время назад.

Для обеспечения этого функционала вам не нужно настраивать Cron-скрипты, делать снепшоты и т.п. Файловая система NILFS2 делает это всё сама. Она никогда не переписывает старые данные и всегда пишет в новые области диска, если достаточно свободного дискового пространства. В полном соответствии с принципом Copy-on-Write.

Фактически, любое изменение файла влечёт за собой автоматическое создание нового снимка файловой системы, поэтому вы можете использовать эту ФС как машину времени и отматывать назад состояние файлов.

История


NILFS2 была разработана в недрах Nippon Telegraph and Telephone Corporation, фактически, государственной (оно имеет контрольный пакет) и крупнейшей телекоммуникационной компании Японии. А конкретнее в лаборатории CyberSpace Laboratories под руководством Ryusuke Konishi.

Для чего конкрентно она разрабатывалась — неизвестно, однако, можно предположить, что подобная ФС, с её функционалом “машины времени” идеальна для хранения данных, в которых может возникнуть желание поковыряться спецслужбам, чтобы повторно проиграть всю картину СМС, емейлов и т.п…

NILFS2 также, потенциально, очень ценный инструмент для служб внутренней безопасности, так как позволяет восстановить все удалённые письма в почтовой базе данных, вскрыть косяки сотрудников, которые впоследствии могут попытаться их замаскировать, удалив или изменив свои файлы.

Как можно отследить всю историю переписки
В Linux на серверах (а именно туда и стоит ставить NILFS2 для целей внутренней безопасности) для хранения почтовых сообщений очень часто используется файловый способ хранения е-мейлов. Так называемый формат Maildir. Достаточно поставить Courier Mail Server и сконфигурировать хранение писем в Maildir. Другой формат mbox представляет из себя большой текстовый файл, который легко парсится на отдельные сообщения.

Если же почтовый сервер использует базу данных, то NILFS2 даст возможность восстановить точный хронометраж изменений базы и возможность восстановить базу на любой из этих моментов. А дальше нужно воспользоваться инструментами БД, чтобы посмотреть что в ней было на тот момент времени…

Однако что-то пошло не так. То ли правительство Японии передумало за всеми следить (а-ля принцип Яровой), то ли производительность NILFS2 на традиционных HDD оказалась ниже плинтуса, и NILFS2 была выпущена под GPL лицензией и очень быстро вошла в ядро Linux, так как особых претензий к коду, написанному высококвалифицированными японцами, у разработчиков ядра Linux не было.

На что похожа NILFS2?


С точки зрения использования: на систему контроля версий SVN. Каждый чекпоинт ФС — это коммит, который делается автоматически без ведома пользователя при любом изменении: будь то удаление, изменение содержимого файла или прав доступа. Каждый коммит имеет номер, который линейно увеличивается.

С точки зрения программиста: на циклический буфер. Файловая система копит изменения и записывает их в кусок равный примерно 8 МБ (2048 * 4096, где 2048 — число элементов в блоке, а 4096 — размер страницы памяти). Весь диск поделен на такие чанки. Запись идёт последовательно. Когда заканчивается свободное место, то самые старые снимки удаляются, а чанки перезаписываются.

Основные плюшки NILFS2


  • Версионность!!!
  • Процедура восстановления ФС после сбоя элементарна: при загрузке ищется последний чанк, имеющий верную контрольную сумму, и на него устанавливается суперблок. Это практически моментальная операция.
  • В связи с тем, что запись всегда идёт линейно, то:

    • может показывать хорошие результаты при работе на SSD, с медленной случайной записью.
    • NILFS2 экономит ресурс SSD, так как почти отсутствует фактор мультипликации записи.
      Точнее говоря, он не более 2.
      Дело в том, что при циклической перезаписи всего диска NILFS2 будет переносит неизменяемые данные в новые куски (чанки).

      Если мы имеем на диске 10% неизменяющихся данных, то мы получим 10% прирост записи при 1 полной перезаписи. Ну и 50% прирост при 50% заполненности устройства на 1 полную перезапись диска.

      Максимальный коэффициент усиления записи 2. Это очень мало с учётом того, что всё пишется последовательно. В целом мультипликация записи будет меньше, чем у обычной фрагментированной ФС с сектором 4096 байт. (На мысли наведено комментом).

  • Потенциальная простота реализации репликации на удалённую NILFS2 ФС

NILFS2 для /home


В Unix-подобных ОС, как правило, присутствует папка /home, в которой хранятся данные пользователей. Различные программы сохраняют в этой папке свои настройки, относящиеся к конкретному пользователю.

А кто, как не пользователи, чаще всего косячит? Поэтому, как говорится, сам Бог велел использовать на /home NILFS2.

Тем более, что с повсеместным распостранением SSD мы теперь можем не волноваться насчёт сильной просадки при использовании CoW файловых систем.

Да, снимки ФС (снепшоты) мы можем сколько угодно часто создавать и в ZFS и BTRFS, но всегда есть риск, что потерянное изменение файла окажется между снимками. И снимки ещё нужно администрировать: удалять старые. В NILFS2 всё это происходит автоматически, буквально каждые несколько секунд.

Я создал логический том с помощью lvcreate (в группе томов nvme, тонкий пул thin). Я рекомендую создавать именно на томе lvm, так как в последствии он может быть легко расширен. Рекомендую иметь 50% свободного места на диске с NILFS2 для приличной глубины версионности.

lvcreate -V10G -T nvme/thin -n home

и отформатировал его в NILFS2:

mkfs.nilfs2 -L nvme_home /dev/nvme/home

mkfs.nilfs2 (nilfs-utils 2.1.5)
Start writing file system initial data to the device
      Blocksize:4096  Device:/dev/nvme/home1  Device Size:10737418240
File system initialization succeeded !!

После этого нужно скопировать все данные с текущего /home.

Я это сделал сразу после загрузки компьютера, до входа в свой аккаунт, из-под пользователя root. Если бы я зашёл под своим пользователем, то какие-нибудь программы открыли бы сокеты и файлы в папке моего пользователя /home/user, что сделало бы чистое копирование затруднительным. Как известно, домашняя папка для пользователя root обычно находится по пути /root, поэтому на разделе /home никакие файлы не откроются.

mkdir /mnt/newhome
mount -t nilfs2 /dev/nvme/home /mnt/newhome
cp -a /home/. /mnt/newhome

По поводу последней строки см. статью.

Далее правим /etc/fstab, в которой монтируется файловая система для /home, на

/dev/disk/by-label/nvme_home /home nilfs2    noatime 0 0

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

Виды снимков в NILFS2.


Обычный снимок без иммунитета к удалению называется чекпоинт (checkpoint или точка восстановления).
Снимок с защитой от автоудаления называется снепшот (snapshot), далее просто снимок.

Просмотр чекпойтов делается с помощью команды lscp

Просмотр снимков (снепшотов) lscp -s

Мы можем и сами создавать снимки и чекпоиты в любой момент с помощью:

mkcp [-s] устройство

Восстанавливаем данные.


NILFS позволяет нам монтировать сколько угодно старых снимков параллельно с работой с основной ветвью ФС. Но только в режиме для чтения.

Устроено всё так. Обычные чекпоинты, которые делает NILFS2, могут быть ей автоматически удалены в любой момент (когда кончится дисковое пространство или по правилам nilfs_cleanerd), поэтому перед монтажом мы должны перевести чекпоинт в снепшот или, по-русски говоря, зафиксировать снимок.

chcp ss номер_чекпоинта

После этого мы может примонтировать снимок, например, так:

mount -t nilfs2 -r -o cp=номер_чекпоинта /dev/nvme/home /mnt/nilfs/номер_чекпоинта

После чего мы копируем восстанавливаемые файлы из снимка в /home.
А впоследствии снимаем флаг неудалимости со снимка, чтобы в будущем автоматический сборщик мусора мог удалить устаревшие данные:

chcp cp номер_чекпоинта

Утилиты для NILFS2


А вот с этим беда. Да, конечно, мы можем создавать ФС, менять её размер он-лайн, просматривать список чейпоинтов, делать и удалять их. Пакет nilfs2-utils предоставляет минимальный джентельменский набор.

Поскольку NTT свернула финансирование, то нет быстрых низкоуровневых утилит, которые позволяют выводить историю изменений файлов, делать diff между снимками.

Моя утилита n2u


Чтобы заполнить этот вакуум я написал свою утилиту n2u, которая умеет выводить историю изменений конкретного файла/директории:

n2u log filename

Вывод примерно такой:

          CHECKPOINT        DATE     TIME     TYPE          SIZE  MODE
             1787552  2019-11-24 22:08:00    first          7079    cp
             1792659  2019-11-25 23:09:05  changed          7081    cp

Она работает довольно быстро для избранного способа реализации: ищет различия между файлами методом бисекции, быстро монтируя и сравнивая файл/директорию в разных снимках.

Можно задать диапазон чекпоинтов с помощью ключа -cp CP1:CP2 или -cp {YEAR-MM-DD}:{YEAR-MM-DD}.

Также можно посмотреть разницу между чекпоинтами для определённого файла или директории:

n2u diff -r cp1:cp2 filename

Можно вывести всю хронологию изменений: все разницы между чекпоинтами определенного файла/директории:

n2u blame [-r cp1:cp2] filename

Интервал дат в в этой команде также поддерживается.

Клич к разработчикам


На Хабре много спецов. Прошу, допилите NILFS2. Сделайте репликацию, низкоуровневый быстрый diff между ревизиями, reflink и другие плюшки!

Ссылки


Официальный сайт NILFS.

Репозитории:
NILFS2.
NILFS2 утилиты и модули.

Рассылки:
Е-мейл рассылка разработчиков NILFS2. Идентификатор для подписки linux-nilfs.
Архив рассылки.

Руководство по настройке nilfs_cleanerd.
Сравнительные тесты производительности EXT4, Btrfs, XFS & NILFS2.


Благодарности:

  • Разработчикам NILFS2: Ryusuke Konishi, Koji Sato, Naruhiko Kamimura, Seiji Kihara, Yoshiji Amagai, Hisashi Hifumi and Satoshi Moriai. Other major contributors are: Andreas Rohner, Dan McGee, David Arendt, David Smid, dexen deVries, Dmitry Smirnov, Eric Sandeen, Jiro SEKIBA, Matteo Frigo, Hitoshi Mitake, Takashi Iwai, Vyacheslav Dubeyko.
  • Компаниям Amblin Entertainment и Universal Pictures за чудесную серию фильмов «Назад в будущее». Первая картинка поста взята из фильма «Назад в будущее — 3».
  • Компании RUVDS за поддержку и возможность публикации в своем блоге на Хабре.

P.S. Замеченные ошибки направляйте в личку. Повышаю за это карму.



Вы можете поэкспериментировать с NILFS2, заказав виртуальную машину у RUVDS по купону ниже. Для всех новых клиентов бесплатный тестовый период 3 дня.

RUVDS.com
1 204,83
RUVDS – хостинг VDS/VPS серверов
Поддержать автора
Поделиться публикацией

Комментарии 80

    +1
    клич к разработчикам

    и


    нет ссылки на репо проекта
      +2
      Добавил в статью.
      +2
      Про ZFS было? Вопрос же ещё в поддержке сообщестовм, наличии знаний, опыте не только у разрабов, но и у сообщества.
        +4
        Во времена SSD дисков советовать файловую систему, не поддерживающую TRIM несколько странно. Сейчас есть btrfs, которая также имеет snapshot`ы и поддерживает TRIM.
          +2
          1. В документации указано, что TRIM поддерживается.
          2. Для NILFS2 из-за последовательной природы записи TRIM не даёт никакого выигрыша.
          3. Фишка NILFS2 в том, что снепшоты делаются (а старые удаляются) автоматически каждые несколько секунд и позволяют проиграть состояние всей ФС во времени.
            +1
            Ура, это произошло.
            Тем не менее в ToDo list написано:
            * Optimization for silicon disks (e.g. SSD)

            То есть, что-то там ещё не докрутили.
              0
              Ну какая последовательная запись?
              Если у вас один файл и вы его постоянно перезаписываете — будет последовательная запись.
              Если у вас тысячи файлов и меняется регулярно сотня — все равно приходите к обычному состоянию диска.

              А нет, там с этим всё норм. Постоянна перезапись данных, которые не меняются. Досвидания ресурс ССД.

              Отдельно доставило «Спецслужбы могли хотеть смотреть старые email и SMS». Там, что использовалась файловая БД? Врядли. Учитывая что классические БД — это хранилище поверх файловой системы — пофиг что там умеет файловая система, организация файлов в БД всё равно не позволит с этим нормально работать.
                0
                Постоянна перезапись данных, которые не меняются. Досвидания ресурс ССД.

                Я такого не писал. Я писал, что ФС подобна циклическому буферу, т.е. весь ССД наоборот последовательно переписывается. Это равносильно идеальному выравниванию износа, что значительно продлевает срок службы ССД.

                Отдельно доставило «Спецслужбы могли хотеть смотреть старые email и SMS». Там, что использовалась файловая БД? Врядли.

                В Linux на серверах (а именно туда и стоит ставить NILFS2 для целей внутренней безопасности) для хранения почтовых сообщений действительно ОЧЕНЬ ЧАСТО используется файловый способ хранения емейл. Так называемый формат Maildir. Другой формат mbox представляет из себя большой текстовый файл, который легко парсится на отдельные сообщения.

                пофиг что там умеет файловая система, организация файлов в БД всё равно не позволит с этим нормально работать.

                NILFS2 даст возможность восстановить точный хронометраж изменений базы и возможность восстановить базу на любой из этих моментов. А дальше нужно воспользоваться инструментами БД, чтобы посмотреть что в ней было на тот момент времени…
                  +1
                  Это равносильно идеальному выравниванию износа, что значительно продлевает срок службы ССД.

                  строго говоря, это неверное утверждение. Т.к. маппинг логических блоков (LBA) в физические страницы микросхем памяти — это задача контроллера SSD и как он это делает — это тайна за семью печатями.


                  В Linux на серверах (а именно туда и стоит ставить NILFS2 для целей внутренней безопасности) для хранения почтовых сообщений действительно ОЧЕНЬ ЧАСТО используется файловый способ хранения емейл. Так называемый формат Maildir. Другой формат mbox представляет из себя большой текстовый файл, который легко парсится на отдельные сообщения.

                  LOL. Хранить почту в БД — видимо, такой вариант не рассматривается? Намекну, что почтовики не ограничиваются только лишь postfix-sendmail-exim-courier.

                    0
                    строго говоря, это неверное утверждение. Т.к. маппинг логических блоков (LBA) в физические страницы микросхем памяти — это задача контроллера SSD и как он это делает — это тайна за семью печатями.


                    С точки зрения практики — это верное утверждение, так при любых тестах любой ССД будет писать быстрее при последовательном заполнении блоков LBA. Что говорит именно об уменьшении фактора мультипликации записи, что и экономит ресурс. На 3dnews есть тест на ресурс ССД. Они там последовательно пишут и достигают петабайтных показателей на дешёвых ССД именно по этому.

                    LOL. Хранить почту в БД — видимо, такой вариант не рассматривается? Намекну, что почтовики не ограничиваются только лишь postfix-sendmail-exim-courier.


                    Если стоит задача держать максимально под контролем переписку пользователей, то нужно поставить именно тот почтовый сервер, который максимально просто позволит достичь этой цели.

                    Во-вторых. Даже если стоит почтовый сервер, который хранит письма в БД, с помощью NILFS2 всё равно можно восстановить старую БД и прочитать письма средств, которые умеют работать с этой БД.
                      +1

                      База данных — это не один файл. Вы почему-то думаете, что все почтовые сервера хранят данные в чем-то типа sqllite. Это не так. И NILFS2 совершенно не гарантирует, что если БД почтового сервера размазана по нескольким файлам — снапшот будет консистентный. Очевидно. И коли речь идет о БД для почтового сервера, то там есть свои способы "вернуться к старой версии БД" и "прочитать старые письма" (я уж не говорю о том, что Вы почему-то переоцениваете важность этой задачи, тем более, что для ее решения есть другие технические средства вроде DPI и сниффинга трафика).


                      На 3dnews есть тест на ресурс ССД. Они там последовательно пишут и достигают петабайтных показателей на дешёвых ССД именно по этому.

                      можете аргументировать свое мнение? Более того — с дешевыми ССД это вообще очень интересная история, когда они сначала работают ОЧЕНЬ быстро, а потом при заполнении данными скорость деградирует до неприлично низких значений. Поэтому… давайте не будем о дешевых ССД?

                        0
                        База данных — это не один файл.
                        Вот например в Thunderbird — это 1 файл на каждую почтовую папку.

                        Если у корпорации стоит задача следить за сотрудниками, то будет подобрано именно такое решение, с которым проблем не возникнет.

                        можете аргументировать свое мнение?
                        Только логически. Я подозреваю, чтобы попасть в тест с такими щадящими условиями производители дешёвых дисков приплачивают 3dnews. Этот ресурс в целом живёт за счёт рекламы от производителей железа, как я понимаю.
                          0
                          Вот например в Thunderbird — это 1 файл на каждую почтовую папку.

                          только вот маленькая деталь — thunderbird — это не почтовый сервер, а клиент.


                          Я подозреваю, чтобы попасть в тест с такими щадящими условиями производители дешёвых дисков приплачивают 3dnews. Этот ресурс в целом живёт за счёт рекламы от производителей железа, как я понимаю.

                          тогда тем более их тестам доверия нет, не правда ли?

                            +1
                            только вот маленькая деталь — thunderbird — это не почтовый сервер, а клиент.

                            Это был просто пример того, что БД — это необязательно несколько файлов. Тем более можно и пользовательские /home все посадить на NILFS2. И это разумно не только с точки зрения безопасников.

                            тогда тем более их тестам доверия нет, не правда ли?
                            Логика обмана другая. Тесты вопроизводимые, а иначе можно разрушить свою репутацию. А вот методика плохая, завышающая результаты. И за попадание в тестирование скорее всего берутся деньги.
                              0
                              Это был просто пример того, что БД — это необязательно несколько файлов

                              Пример неудачный. Про 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 слишком много мусора, который не нужно снапшотить.

                                +1
                                Я на практике держу /home на nilfs2. Всё хорошо работает. В среднем примерно могу на 2-3 месяца назад откатиться. Несмотря на мусор.
                      +1
                      LOL. Хранить почту в БД — видимо, такой вариант не рассматривается? Намекну, что почтовики не ограничиваются только лишь postfix-sendmail-exim-courier.


                      LOL. Ну а в другого вида почтовиках — имеет смысл использовать другие решения. Но это в почтовиках, что не голую файловую систему используют. (с) Капитан Очевидность.
                      +2
                      Волшебство, не иначе.
                      Мы последовательно пишем файлы 1 2 3 4 5, файлы 1 2 4 5 изменились, 3 — нет. Когда цикл дойдет до 3 — он его вынужден будет скопировать. И будет его так копировать постоянно. Просто гоняя файл который не изменяется на каждый цикл.
                        –1
                        Наверное. Но в целом мультипликация записи будет всё равно меньше, чем у обычной фрагментированной ФС с сектором 4096 байт.

                        Если мы имеем на диске 10% неизменяющихся данных, то мы получим 10% прирост записи при 1 полной перезаписи.
                        Ну и 50% прирост при 50% заполненности устройства.

                        Максимальный коэффициент усиления записи 2. Это очень мало с учётом того, что всё пишется последовательно.
                        0
                        Я такого не писал. Я писал, что ФС подобна циклическому буферу, т.е. весь ССД наоборот последовательно переписывается.

                        Для эффективной работы SSD должно оставаться свободное пространство, иначе скорость записи упадёт в разы.


                        Это равносильно идеальному выравниванию износа, что значительно продлевает срок службы ССД.

                        В SSD используется таблица трансляции. Контроллеру плевать, что вы последовательно пишете данные.

                          0
                          Для эффективной работы SSD должно оставаться свободное пространство, иначе скорость записи упадёт в разы.


                          1. Это верно только для обычных ФС.
                          2. NILFS2 поддерживает TRIM (хоть он ей и не особо нужен) и свободное место есть всегда.

                          В SSD используется таблица трансляции. Контроллеру плевать, что вы последовательно пишете данные.


                          Уже десятый раз отвечаю. Не плевать. Во всех тестах на запись у любых SSD всегда последовательная запись побеждает любой вид случайной записи.
                            +1

                            И откуда же у NILFS2 возьмётся свободное место, если данные пишутся циклически? т.е. диск всегда на 100% занят данными.


                            Уже десятый раз отвечаю. Не плевать. Во всех тестах на запись у любых SSD всегда последовательная запись побеждает любой вид случайной записи.

                            Зависит от размера блока.

                              +1
                              В этом буфере есть дыра, которая тоже циклически двигается.
                              Размер дыры может быть увеличен nilfs_cleanerd при исчерпании свободного места.
                                +1

                                Ну вот теперь хоть немного понятнее стало.

                                +1
                                Зависит от размера блока.

                                А Вы какой блок имеете в виду? Тот, который к блочному устройству относится и поддерживается FTL? Или тот, который в NAND?
                                  +1

                                  Размер блока записываемых данных и его связь с размером блока в NAND.

                                    +1
                                    Размер блока обычно фиксирован для блочного устройства, нет? И это логические блоки, как они раскиданы по NAND знает только проприетарный FTL. Я даже не знаю, можно ли драйверу SSD сказать, что сейчас будет писаться большой-прибольшой кусок и лучше это делать сразу на свободный блок NAND желательно выделив непрерывный диапазон номеров логических блоков.
                                      0
                                      У многих SSD стоит RAM-буфер и контроллер, когда видит, что в ram-буфере есть непрерывная последовательность сам выделяет непрерывный блок.
                                        0
                                        И?
                                        +2
                                        Размер блока обычно фиксирован для блочного устройства, нет?

                                        Причём тут вообще блочное устройство? Есть кластер файловой системы, если логический сектор устройства, есть страница NAND, есть блок NAND, состоящий из страниц. У каждой из этих сущностей свой размер.


                                        И это логические блоки, как они раскиданы по NAND знает только проприетарный FTL.

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


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


                                        В остальных случаях возможны варианты. Один сценарий — случайная запись маленькими кусками данных, но в свободное пространство — в этом случае контроллер просто дописывает данные в пустые страницы, и случайная запись по скорости может достигать линейную.


                                        И совсем другой сценарий — случайная запись маленькими кусками данных поверх других данных. Так как контроллер не может переназначать отдельные страницы, то он будет вынужден перезаписывать блоки целиком, а это уже долго. Скорее всего, он запишет данные в новый блок, при этом данные из старого блока все равно нужно копировать.


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

                                        Нельзя. Контроллер SSD сам понимает, что происходит. Современные контроллеры умные — имеют и RAM, и SLC-кэш. Они быстро пишут данные в свободные ячейки, а затем уже в фоне занимаются консолидацией данных.

                                          +1
                                          Плюс следует добавить, что размер страницы и размер блока у NAND-а могут меняться в зависимости от чипа, что превращает оперирование «блоками»/«страницами» на уровне «ФС для NAND без умного контроллера» в полноценный АД с режимом «промахнулся — угробил».
                          –1
                          1. Для NILFS2 из-за последовательной природы записи TRIM не даёт никакого выигрыша.

                          TRIM не для этого. Мне кажется, что Вы просто не поняли зачем TRIM нужен.

                          +1
                          А еще btrfs имеет неявные подводные камни, особенно для SSD. ValdikSS
                          +1
                          А сразу при установке системы нельзя выбрать NILFS32 для /home?
                            +2
                            Зависит от дистрибутива.
                            +1
                            Она никогда не переписывает старые данные и всегда пишет в новые области диска, если достаточно свободного дискового пространства.

                            А что она делает, когда свободного места недостаточно (что бывает в 90% случаев)?
                              +1
                              Она начинает перезаписывать последовательно самые старые куски.
                              Т.е. самые старые снимки удаляются.
                                +1
                                Правильно. Но меня это не интересует, т.к. «достаточно свободного пространства» я уж и не помню, когда видел. Я спрашиваю, что она делает, когда его недостаточно. Про это в статье ничего нет.
                                  +1
                                  Ну, немного есть. Я там говорил про циклический буфер.

                                  Добавил в статью:
                                  «Когда заканчивается свободное место, то самые старые снимки удаляются, а чанки перезаписываются.»
                                    0

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


                                    Еще очевидно, что производительность у файловой системы NILFS2 будет не фонтан. Т.е. она не будет СУПЕРмедленная. Но и не супербыстрая. Ее скорость будет примерно одинаково плохая всегда. Почему? Да потому что чтобы записать НОВЫЙ блок — нужно каким-то образом достать содержимое файла из старого блока. Эта проблема похожа на историю, когда SSD не может перезаписать единичный байт в странице памяти микросхемы NAND. А приходится писать страницу целиком. А они нынче могут быть бооооольшие.

                                      –1
                                      Да потому что чтобы записать НОВЫЙ блок — нужно каким-то образом достать содержимое файла из старого блока. Эта проблема похожа на историю, когда SSD не может перезаписать единичный байт в странице памяти микросхемы NAND. А приходится писать страницу целиком. А они нынче могут быть бооооольшие.


                                      Нужен ССД с очень быстрым случайным чтением, чтобы быстро читать предыдущие блоки. Например, прекрасно подойдёт Samsung PM1725 с миллионом IOPS (бу версию можно купить за разумные деньги). А запись всегда линейная и происходит довольно шустро.
                                    +1
                                    Если говорить о SSD, то ещё худо-бедно можно поверить, но какие-нибудь никогда не изменяемые старые фотки, музыкальную коллекцию, фильмы, клипы и прочий крупняк можно же держать на HDD, размер и цена на которые уже несколько лет позволяет вообще не запариваться про объём свободного места. Я уже лет 6 не знаю такой беды, как «нет свободного места» на домашней машине. На серверах бывало, да. Но там же не я данные продуцирую, а всё предприятие. Пользователей много. Они стараются. Поэтому случается время от времени там-сям. Но в заголовке статьи ведь свой родной /home
                                      +1
                                      У меня только HDD и места постоянно катастрофически не хватает.
                                    +5

                                    Вы знаете, я узнав про 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? Тоже поддерживает постоянные снепшоты и кажется сделанной гораздо более качественно.

                                      –1
                                      Dragonfly BSD — пока для меня это экзотика. Мои сервера под Linux, поэтому я и дома использую Linux.

                                      Думаю, имеет смысл написать какой-то скрипт, который будет раз в день (например, по завершении работы) делать снимок NILF2 и удалять самый старый снимок.

                                      Я нашёл подробное руководство по настройке nilfs_cleaner.
                                        +1

                                        Как только встаёт вопрос "ой, надо писать скрипты для автоматизации", то сразу же появляется более простой ответ — zfs всё это и так может, разве что скрипты нужны для автоматизации создания/удаления снапшотов.


                                        p.s. А вы не в курсе, что там у RuVDS (который вы рекламируете) с "виртуалкам за 30 рублей"? Постоянное "виртуалки недоступны, оставьте свой email" — прошло уже пара месяцев, а воз и ныне там, нету… ну так хоть убрали бы тогда рекламу, раз нет возможности.

                                          0
                                          В корпоративном блоге все посты просто обязаны выходить с рекламой, так как фирма платит Хабру приличные деньги за него.

                                          Насчёт виртуалок по 30 руб ничего не подскажу. Я передам ваше пожелание менеджерам RUVDS.
                                            –1
                                            что там у RuVDS (который вы рекламируете) с «виртуалкам за 30 рублей»? Постоянное «виртуалки недоступны, оставьте свой email» — прошло уже пара месяцев
                                            Тариф за 30 рублей мы подключили в конце августа. Тариф очень популярен и не только в России, за 3 прошедших месяца мы уже 5 раз закупали новое оборудование под него и каждый раз оно заканчивается за несколько часов. Сейчас в первую очередь мы удовлетворяем заявки по предзаказу. Поэтому всем желающим предлагаем оставить email на странице заказа и мы пришлем вам письмо, когда тариф вновь станет доступен.
                                              +1
                                              Поэтому всем желающим предлагаем оставить email на странице заказа

                                              Что я и сделал, почти сразу после выхода вашей статьи.
                                              Жаль, что очередь столь большая, что растянулась на 3+ месяцев :(
                                                0
                                                Добрый день. В настоящее время тариф за 30 рублей доступен для заказа.
                                                  0
                                                  Вы уверены?
                                                  У вас сайт, похоже, сломался — при переходе по вашей ссылке висит красивый баннер «нет свободных ресурсов» :)
                                                    0
                                                    Попробуйте еще раз, все работает.
                                                      0
                                                      Вот сейчас получилось, спасибо — зарегистрировался, запустил сервер и даже обновил :)

                                                      Остаётся единственный вопрос — а как у вас с поддержкой IPv6?
                                                      Нигде не нашел об этом информации.
                                                        0
                                                        Мы предоставляем каждому серверу 1 выделенный адрес IPv4. IPv6 в настоящее время не поддерживаем.
                                                          0
                                                          Для виртуалки за $0.5/мес это вполне нормально.

                                                          Но даже за $5/мес не иметь IPv6 сейчас — уже серьёзный недостаток по сравнению с конкурентами.
                                                          Для сравнения — Hetzner для виртуалки за ~3.5 Eur выдаёт автоматически 1 IPv4 адрес и блок /64 адресов IPv6.
                                              –1
                                              А ZFS будет нормально работать со 100 000 снепшотов, как это умеет делать NILFS2?

                                              И какую нагрузку будет создавать деланье снепшота каждые несколько секунд?

                                              Если есть специализированный инструмент, то не вижу целесообразности делать свой велосипед.
                                                +1
                                                А ZFS будет нормально работать со 100 000 снепшотов, как это умеет делать NILFS2?

                                                Сомневаюсь, хотя не проверял.

                                                И какую нагрузку будет создавать деланье снепшота каждые несколько секунд?

                                                Я не могу представить задачу, под которую понадобиться делать снапшоты в таком режиме. Возможно проблема именно в этом.
                                                  –1
                                                  Ну вот это и цель NILFS2. В любой момент можно отмотать историю назад, восстановить данные или разобраться с тем, что произошло.
                                                    –1
                                                    А что у вас за цель?
                                                    Я реально не представляю, ЧТО именно вы собираетесь делать.

                                                    Выглядит как механизм создания транзакций для БД, у которой транзакционность не поддерживается.
                                                      –1
                                                      Ну так об этом вся статья. Это создание тотального undo для всей файловой системы с целью отката всех нежелательных вмешательств, отката случайных удалений и изменений файлов сделанных самостоятельно, расследование фактов корпоративного шпионажа, восстановление хронологии хакерских вмешательств и т.п.
                                                        0

                                                        Эта задача решается по-другому и без привлечения такого странного решения.
                                                        Условно — ну, пользователь очень активен и перезаписывает файлы постоянно. История снапшотов Вашей ФС тупо не вытянет сколько-либо большую глубину изменений. Чтобы логирование работало в режиме анального зонда — это надо запрещать админа на хосте и ставить агента для слежки. И чтоб он почти в реалтайме передавал данные на центральный сервер. Так работают многие модули, вроде СТАХАНОВЕЦ
                                                        Ну, или сбой ФС или диска — и вся история слежки слетела. ИБшники прям будут счастливы.
                                                        Еще добавлю, что полные снапшоты зачастую нафиг не нужны. ОК, я здесь немного лукавлю — у меня, например, на ноуте btrfs на системном диске и перед обновлением софта автоматически снимается слепок системы. Но это не так часто — раз, два — это реально имеет ценность. А снапшот условной помойки в node_modules в хомяке юзера… ну, такое......

                                                          +1
                                                          Эта задача решается по-другому
                                                          Я упомянул 5 задач.

                                                          История снапшотов Вашей ФС тупо не вытянет сколько-либо большую глубину изменений.

                                                          Откуда такое мнение? Явно вы не пользовались NILFS2. У меня на хомяке по максимуму вытягивала полгода с разрешением в 3-5 секунд в моменты активной работы. При уровне свободного пространства 70-80%.

                                                          Пользователь должен специально забивать свою папку. В таком случае глубина падает до пары дней.

                                                          Потенциально очень несложно сделать удалённую репликацию NILFS2. Так что одно не исключает другого.

                                                          Лично я несколько раз восстанавливал файлы случайно удалённые самим собой. Очень удобно.

                                                          То что для вас помойка, для юзера может быть ценнейшей вещью.
                                                            –1

                                                            Давайте конкретный вопрос, чтобы не было разночтений и недопонимайни — умеет ли NILFS2 работать с разной настройкой глубины хранения снапшотов для разных файлов? Тогда признаю — все не так плохо, как я думаю.


                                                            Явно вы не пользовались NILFS2

                                                            А нужно? Для моих задач хватает ext4/btrfs

                                                              –1
                                                              История снапшотов Вашей ФС тупо не вытянет сколько-либо большую глубину изменений.


                                                              Для того, чтобы так говорить НУЖНО иметь опыт использования.

                                                              Можно задать глубину защиты всей ФС. Можно выставить любое число от секунды до десятилетий. Весь вопрос в ёмкости накопителя.

                                                              Вначале я делал специальный раздел для важных файлов и защищал его с помощью NILFS2, а потом надоело и поставил целиком на /home и всё ок.
                                          +1
                                          Скорость скорее всего записи тогда начинает падать. Потому что старые куски ещё нужно найти
                                            +1
                                            Они идут последовательно. NILF2 — она как циклический буфер. Но скорость будет уменьшаться из-за перекомпоновки. В старых кусках есть актуальные данные, которые будут переноситься в новые куски при очистке старых. Тоже последовательно.

                                              0

                                              NILF2 — как она относится к ресайзу? ext2/ext3/ext4 прекрасно растягиваются, если, например, поставили более емкий диск.

                                                +1
                                                Тоже прекрасно растягивается. Только вчера делал.
                                        +1

                                        интресно было бы посмотреть на сравние скорости, как сказалось версионность на доступности

                                          +1
                                            +1

                                            сверху же можно еще и шифрование добавить которое и так убирает большую скорость

                                              +2

                                              Современные процессоры могут шифровать AESом со скоростью более 3 Гигабайт в секунду на каждое ядро.

                                          +4
                                          Кмк zfs с частыми снапшотами будет юзабельней nilfs2.
                                            +3

                                            Вспомнил одну шутку — настроил я однажды автосинхронизацию папки с данными outlook'а (файлы .ost) на хранилище с версионностью файлов, т.к. это были старые архивы, в которые никто не писал.


                                            Через два дня гиговые (в общей сложности) .ost файлы выжрали 20Gb хранилища. Оказалось, что outlook зачем-то что-то пишет в файлы и в хранилище создалась куча версий файлов.


                                            Это я к тому, что автосоздание версий — зло, если его применять бездумно.
                                            К примеру, что будет с этой FS, если на ней разместить лог web сервера или (что более вероятно) временную папку кеша сессий того же php?

                                              +1
                                              если на ней разместить лог web сервера или (что более вероятно) временную папку кеша сессий того же php?

                                              Так не похоже, что она для этого и была создана.....

                                                +1
                                                Использование такой ФС в таких целях будет «умным» настолько же, насколько использование btrfs на SD карте в rw режиме для папки /home в домашнем пк.
                                                +1

                                                Так /home это помойка там и .cahce и. node_modules и прочие файлы о предназначении которых можно только догадываться :)

                                                  +1

                                                  На time machine маковскую похоже. Тоже инкрементальные копии и возможность увидеть версии файла/папки за разное время. Только TM это средство резервного копирования, а не ФС.

                                                    0
                                                    Процедура восстановления ФС после сбоя элементарна: при загрузке ищется последний чанк, имеющий верную контрольную сумму, и на него устанавливается суперблок. Это практически моментальная операция.

                                                    Нетривиальный вопрос. Был сбой. Произошло автовосстановление. Как восстановить те данные, которые оказались в поврежденных коммитах? Насколько я понял из статьи — история записи в NILFS2 линейная, а не древовидная. Следовательно, все последующие коммиты после восстановления и последующей записи будут потеряны. Либо все хуже. Предположим, было разветвление истории (прямо как в фильте "Назад будущее"). Мы это не заметили, а потом точка ветвления — коммит — был удален сборщиком мусора.
                                                    Как в таком случае поведет себя ФС?
                                                    Ну, и повторюсь, что явно же, что NILFS2 не страхует от повреждения самого накопителя и могут быть неучтенные баги в работе самой ФС. Поэтому бекапы она не заменяет. От слова совсем. И я не вижу из статьи есть ли механизмы контроля целостности и восстановления уже записанных данных. Типа ZFS SCRUB-механизма.

                                                      +1
                                                      При сбое теряются данные за последние 1-5 секунд. Механизмы восстановления их пока не реализованы.

                                                      Сборщик мусора удаляет только те данные, которые были удалены или перезаписаны в дальнейшем. Данные, которые не изменились он переносит в другие блоки (так я понял).

                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                    Самое читаемое