Какая файловая система Linux наиболее эффективна для хранения большого количества маленьких файлов (HDD, а не SSD)?

43

У меня есть дерево каталогов, которое содержит много маленьких файлов и небольшое количество больших файлов. Средний размер файла составляет около 1 килобайта. В дереве 210158 файлов и каталогов (это число было получено при запуске find | wc -l).

Небольшой процент файлов добавляется / удаляется / переписывается несколько раз в неделю. Это относится как к маленьким файлам, так и к (небольшому количеству) больших файлов.

Файловые системы, которые я пробовал (ext4, btrfs), имеют некоторые проблемы с размещением файлов на диске. В течение более длительного промежутка времени физическое расположение файлов на диске (вращающийся носитель, а не твердотельный диск) становится более случайным. Негативным следствием этого случайного распределения является то, что файловая система становится медленнее (например: в 4 раза медленнее, чем новая файловая система).

Существует ли файловая система Linux (или метод обслуживания файловой системы), который не страдает от этого снижения производительности и способен поддерживать стабильный профиль производительности на вращающемся носителе? Файловая система может работать на Fuse, но она должна быть надежной.

linux filesystems performance
источник
Если вы знаете, какие файлы будут большими / не будут меняться очень часто, а какие будут небольшими / часто меняющимися, вам может потребоваться создать две файловые системы с различными параметрами, более подходящими для каждого сценария. Если вам нужно, чтобы они были доступны, так как они были частью одной и той же структуры, вы можете сделать некоторые трюки с помощью mount, символических ссылок.
Марцин
Я очень удивлен, узнав, что btrfs (с функцией копирования при записи) был вялым для вас в течение определенного периода времени. Мне любопытно поделиться с вами результатами, возможно, помогая друг другу в новом направлении настройки производительности с ним.
Nikhil Mulley
В Linux есть новая версия zfs для животных, доступная в собственном режиме и в виде реализаций предохранителей, на случай, если вы захотите взглянуть.
Nikhil Mulley
Я попробовал zfs на Linux один раз, был довольно нестабильным. Удалось полностью заблокировать файловую систему довольно часто. Коробка будет работать, но любой доступ к ФС будет зависать.
Патрик
Аналогичная запись serverfault.com/questions/6711/...
Нихилу Mulley

Ответы:

47

Спектакль

Я написал небольшой тест ( источник ), чтобы выяснить, какая файловая система лучше всего работает с сотнями тысяч маленьких файлов:

  • создать 300000 файлов (от 512B до 1536B) с данными из / dev / urandom
  • переписать 30000 случайных файлов и изменить размер
  • прочитать 30000 последовательных файлов
  • прочитать 30000 случайных файлов

  • удалить все файлы

  • синхронизировать и удалять кеш после каждого шага

Результаты (среднее время в секундах, меньше = лучше):

Using Linux Kernel version 3.1.7
Btrfs:
    create:    53 s
    rewrite:    6 s
    read sq:    4 s
    read rn:  312 s
    delete:   373 s

ext4:
    create:    46 s
    rewrite:   18 s
    read sq:   29 s
    read rn:  272 s
    delete:    12 s

ReiserFS:
    create:    62 s
    rewrite:  321 s
    read sq:    6 s
    read rn:  246 s
    delete:    41 s

XFS:
    create:    68 s
    rewrite:  430 s
    read sq:   37 s
    read rn:  367 s
    delete:    36 s

Результат: в
то время как Ext4 показывал хорошую общую производительность, ReiserFS очень быстро читал последовательные файлы. Оказалось, что XFS работает медленно со многими небольшими файлами - вы не должны использовать его для этого случая использования.

Проблема фрагментации

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

дальнейшее чтение

В Arch Wiki есть несколько замечательных статей, посвященных производительности файловой системы:

https://wiki.archlinux.org/index.php/Beginner%27s_Guide#Filesystem_types

https://wiki.archlinux.org/index.php/Maximizing_Performance#Storage_devices

taffer
источник
4
Вы должны указать, какую версию ядра вы используете для сравнения. XFS получила некоторые очень существенные улучшения скорости в одном из последних ядер (думаю, что это был 2.6.31, но не цитируйте меня по этому поводу).
Патрик
1
btrfs внутренне делает трюк с lvm. Он выделяет меньшие порции диска и помещает файлы в эти порции, а затем выделяет другой порцию диска только тогда, когда существующие порции заполняются.
Псуси
1
Это верно для любой файловой системы. Вот почему приложения используют такие вещи, как fsync ().
psusi
2
@taffer, это так. Транзакции имеют тот же эффект, что и журнал в других файловых системах: они защищают метаданные fs. Теоретически они могут использоваться приложениями так, как вы описываете, но в настоящее время нет API, позволяющего приложениям открывать и закрывать транзакции.
Псуси
1
@taffer Ваш "недавний тест" относится к апрелю 2015 года, старше трех лет и использует XFS только с опциями по умолчанию. Это предшествует xfsprogs 3.2.3, что делает XFS v5 по умолчанию и все преимущества, которые он приносит. Он также не был отформатирован с -m finobt = 1, который меняет игру для производительности XFS с небольшими файлами и большими обновлениями метаданных. Нет, серебряных пуль нет, но основывать свое мнение на старых тестах нецелесообразно, особенно если основные функции, изменяющие производительность, были проигнорированы, недоступны или отключены.
Джоди Ли Брухон
7

Я использую ReiserFS для этой задачи, он специально предназначен для обработки большого количества маленьких файлов. Об этом легко прочитать на вики-сайте funtoo.

ReiserFS также имеет множество функций, специально предназначенных для улучшения производительности небольших файлов. В отличие от ext2, ReiserFS не выделяет место для хранения в фиксированных k или четырех k блоках. Вместо этого он может выделить точный размер, который ему нужен.

Baarn
источник
1
Есть проблемы со стабильностью и с ReiserFS - поэтому RH и SuSE отказались от этой FS. Из принципа (BTree-based-FS) BTRFS должны быть сопоставимы.
Нильс
0

XFS известен тем, что очень хорошо работает в подобных ситуациях. Это часть того, почему мы используем его на своей работе для наших почтовых магазинов (которые могут содержать сотни тысяч файлов в одном каталоге). Он имеет лучшую отказоустойчивость, чем ReiserFS, используется гораздо шире и, как правило, является очень зрелой файловой системой.

Кроме того, XFS поддерживает онлайн-дефрагментацию. Хотя он использует метод отложенного размещения, который приводит к меньшей фрагментации (по сравнению с другими файловыми системами) для начала.

Патрик
источник
20
XFS известен тем, что очень хорошо работает в подобных ситуациях. [нужная цитата]
таффер
8
Хм, xfs особенно известен противоположностью: очень хорошо работает с большими файлами, но не очень хорошо с маленькими! Посмотрите, например, на этот исчерпывающий тест (или перейдите прямо к выводу на стр. 10 ^^): ilsistemista.net/index.php/linux-a-unix/…
Левит
1
@ Левит Я думаю, что вы неправильно читаете этот отчет. Отчет очень ясно показывает, что XFS работает очень хорошо для случайного ввода-вывода. Но кроме этого, в отчете не рассматривается тип сценария в этом вопросе, множество файлов. Случайный ввод-вывод - это одно, большое количество файлов - это то, где ext * падает на лицо.
Патрик
2
Единственное место, где XFS действительно лучше, это случайные операции чтения / записи (все еще кажется странным, что действительно случайный шаблон чтения на механическом диске способен получать 10 МБ / с - мне кажется, что это некоторая оптимизация, которая не работает в реальном мире (imho)), тогда как на странице 7 показано именно то, что я сказал ранее, XFS действительно хорош в обработке больших файлов! Посмотрите на страницы 3 и 5, особенно на 3, вы видите, что он обрабатывает небольшие файлы явно не так хорошо, как ext! Я действительно ничего не имею против XFS, но из того, что вы найдете почти везде, это не лучший вариант для многих маленьких файлов, это все, что я говорю!
Левит
5
XFS также может быть очень медленным, когда дело доходит до больших файлов, если эти файлы расширяются случайным образом / медленно с небольшими порциями в течение длительного времени. (Типичная syslogdсхема.) Например, на моей стороне в настройке XFS поверх MD я только что заметил, что удаление файла объемом 1,5 ГБ заняло 4,75 минуты (!), В то время как диск был ограничен со скоростью 100 транзакций / с со скоростью записи. более 2 МБ / с. Это также сильно влияет на производительность других параллельных операций ввода-вывода на том же диске, так как диск уже исчерпан. Никогда не видел ничего подобного в других ФС (или тестировался в тестах).
Тино