файловая система для архивирования

У меня есть некоторые сложные данные только для чтения в моей файловой системе. Он содержит тысячи снимков определенных ревизий репозитория SVN и результаты регрессионных тестов. Одинаковые файлы между моментальными снимками уже дублируются с помощью жестких ссылок. Таким образом, емкость хранилища не должна быть большой, но она по-прежнему потребляет много inode, и это делает fsck мучительно долгим для моей основной файловой системы.

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

Если это не медлительность fsck, вы пробовали ext4? Они добавили несколько функций, которые делают fsck очень быстрым , не глядя на неиспользуемые inode :

Fsck - очень медленная операция, особенно первый шаг: проверка всех inode в файловой системе. В Ext4 в конце таблицы inode каждой группы будет храниться список неиспользуемых inode (с контрольной суммой для безопасности), поэтому fsck не будет проверять эти inode. В результате общее время fsck увеличивается от 2 до 20 раз, в зависимости от количества используемых inode (http://kerneltrap.org/Linux/Improving_fsck_Speeds_in_Ext4). Следует заметить, что fsck, а не Ext4, создаст список неиспользуемых inode. Это означает, что вы должны запустить fsck, чтобы получить список созданных неиспользуемых инодов, и только следующий запуск fsck будет быстрее (вам необходимо передать fsck для преобразования файловой системы Ext3 в Ext4 в любом случае). Есть также функция, которая участвует в этом ускорении fsck - «гибкие группы блоков»

Btrfs имеет встроенную поддержку снимков, поэтому вам не придется использовать жесткие ссылки для дедупликации. Вы можете воссоздать текущую настройку, создав файловую систему btrfs и загрузив ее с самой ранней версией, которая вам нужна, и сделав снимок, а затем развернув репозиторий вперед на каждый момент времени, к которому вам нужен снимок, и сделав снимок на каждом шаг. Это должно быть более эффективным, чем жесткие ссылки, и проще в настройке.

Я также думаю (хотя я далеко не уверен в этом), что squashfs прозрачно дедуплицирует файлы, поэтому, даже если он не обрабатывает жесткие ссылки, вы все равно увидите преимущества. Если вам никогда не нужно изменять данные в файловой системе, то, вероятно, стоит использовать squashfs, так как fsck может быть заменен на md5sum;)

Я бы предпочел XFS, так как у меня очень хороший опыт работы с этой файловой системой. Но я действительно рекомендую вам сделать тест со своими данными и всеми предлагаемыми файловыми системами.

Я знаю несколько магазинов, которые используют DataDomain именно для этой цели.

Ваш архивный скрипт может быть очень простым (например, tar или rsync и cron), и вам не нужно беспокоиться об управлении жесткими ссылками или каталогами, которые не могут быть жестко связаны в большинстве файловых систем. Нет необходимости в дополнительных копиях, кроме как для экономии полосы пропускания. Вся магия происходит под слоем блока. Нередко размещать виртуальные данные объемом 15-20 ТБ, используя только 1-2 ТБ реального дискового пространства. У вас еще останется много резервных копий на диске.

Данные будут передаваться через NFS или iSCSI, но я не уверен, что это проблема

Когда FreeBSD получит ZFS v23, дедупликация будет доступна для всех остальных.