Причина, по которой я спрашиваю, заключается в том, что я использую rsnapshot для резервного копирования с отдельным резервным диском raid1 ext3 / backups. К сожалению, удаление резервных копий (происходит каждые 4 часа) занимает до часа! rm -rf /backups/server/hourly.5 займет очень много времени, в то время как все, что он делает, это удаление жестких ссылок, поскольку большинство данных заполнено жесткими ссылками.
ZFS прекрасна, но я думаю о BtrFS, XFS или, возможно, просто ext4 для нового сервера резервного копирования. ZFS вообще не подходит для производственной среды в среде Linux, так что это не вариант, хотя кажется, что это лучшая fs. На этот раз я буду использовать BackupPC на CentOS или Debian в качестве программного обеспечения вместо rsnapshot. Я рассматривал Bacula, но похоже, что у него нет никаких преимуществ перед BackupPC, но его сложнее настроить и требуется установить агент.
Мне нужна ФС, которая быстро удаляет жесткие ссылки. Я не понимаю, почему это должно занять час, ведь с данными все равно ничего не происходит.
Общие советы по резервному копированию приветствуются, но я думаю, что если я использую backuppc, raid1 для резервного копирования с файловой системой, которая является быстрой и готовой к производству, у меня будет хорошая среда резервного копирования.
Я использую ext4 для своей файловой системы. Попробуйте использовать relatime (относительное время) для минимизации обновлений inode в каталоге при удалении файлов.
Запись Raid обычно медленнее, чем чтение, поскольку должно быть записано несколько дисков. Это усугубляется тем, что пишут в журналах. Вы можете попробовать использовать внешний журнал на отдельном наборе дисков.
Удаление файлов из каталогов с большим количеством файлов обычно происходит значительно медленнее, чем удаление файлов из каталогов с меньшим количеством файлов. Я считаю, что это связано с написанием большего количества блоков каталогов. Однако для исправления этого требуется исправление выделения в каталогах, для которых выполняется резервное копирование. Каталоги с большим количеством файлов вызвали у меня проблемы со многими приложениями.
XFS удаляет файлы, по крайней мере, в O(1), а семья ext (mumble) находится в O(log n) (n - размер файла). Я не знаю, как это означает удаление множества ссылок, но это только начало.
Некоторое время назад я установил BackupPC на Debian Lenny с RAID1 и LVM, и я выбрал Reiserfs (установленный с noatime вариант). Я бы предпочел использовать ext4, но в то время поддержка Ленни ext4 была еще немного ... новой. В BackupPC FAQ рекомендовал использовать Reiserfs вместо ext3, вот и все.
Во всяком случае, пока все хорошо, никаких проблем. Reiserfs был очень солидным. Как работает BackupPC, вам, вероятно, не нужно особо беспокоиться о производительности удаления файлов / жестких ссылок. Это связано с тем, что BackupPC выполняет свои задания по очистке отдельно (но, если необходимо, одновременно) с резервным копированием и восстановлением. У меня никогда не было проблем с тем, что задание по очистке выполнялось слишком долго или иным образом мешало нормальной работе.
В моем случае более важным фактором является то, насколько эффективно файловая система обрабатывает множество небольших файлов. Судя по всему, Reiserfs очень хорош для этого, поскольку он минимизирует внутреннюю фрагментацию за счет так называемого «блочного подраспределения» (или «упаковка хвоста"). Тем не менее, если бы мне пришлось выбирать сегодня снова, я бы, вероятно, выбрал ext4. Преимущества использования той же FS, которую используют большинство разработчиков ядра Linux, вероятно, перевешивают любые незначительные технические преимущества, которые дает нишевая FS (например, Reiserfs). может посоветовать.