Ставит ли TAP-адаптер в очередь пакеты?

Предложения по выбору вариантов лучше, чем ext4 для хранения большого количества небольших файлов:

Если вы используете файловую систему в качестве хранилища объектов, вы можете захотеть использовать файловую систему, которая специализируется на что, возможно, в ущерб другим характеристикам. Быстрый поиск в Google обнаружил Ceph , который, похоже, имеет открытый исходный код и может быть смонтирован как файловая система POSIX, но также доступен через другие API. Я не знаю, стоит ли использовать его на одном хосте без использования репликации.

Другой системой хранения объектов является OpenStack's Swift . В его проектной документации говорится, что он хранит каждый объект как отдельный файл с метаданными в xattrs . Вот статья об этом. В их руководстве по развертыванию говорится, что XFS обеспечивает лучшую производительность для объектного хранилища. Таким образом, даже несмотря на то, что XFS не справляется с рабочей нагрузкой, она явно была лучше, чем у конкурентов, когда RackSpace тестировал вещи.Возможно, Swift отдает предпочтение XFS, потому что XFS имеет хорошую / быструю поддержку расширенных атрибутов. Может случиться так, что ext3 / ext4 будет работать на отдельных дисках в качестве серверной части хранилища объектов, если дополнительные метаданные не нужны (или если они хранились внутри двоичного файла).

Swift выполняет репликацию / балансировку нагрузки за вас и предлагает вам предоставить ему файловые системы, созданные на необработанных дисках, не RAID . Он указывает на то, что его рабочая нагрузка, по сути, наихудшая для RAID5 (что имеет смысл, если мы говорим о рабочей нагрузке с записью небольших файлов. XFS обычно не упаковывает их полностью, так что вы не собираетесь получить запись с полной полосой, а RAID5 должен выполнить некоторые чтения, чтобы обновить полосу четности. В документации Swift также говорится об использовании 100 разделов на диск. Я предполагаю, что это термин Swift, и не говорится о создании 100 различных файловых систем XFS на каждом Диск SATA.

Запуск отдельной XFS для каждого диска на самом деле огромная разница . Вместо одной гигантской карты свободных индексных узлов каждый диск будет иметь отдельную XFS с отдельными списками свободных узлов. Кроме того, это позволяет избежать штрафа RAID5 за небольшие записи.

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

Практически с любой нормальной файловой системой поможет использование такой структуры, как

1234/5678   # nested medium-size directories instead of
./12345678   # one giant directory

. Вероятно, около 10 тысяч записей будет разумным, поэтому взять хорошо распределенные 4 символа имен ваших объектов и использовать их в качестве каталогов - простое решение. Это не обязательно должно быть очень хорошо сбалансировано. Нечетный каталог в 100 КБ, вероятно, не будет заметной проблемой, как и некоторые пустые каталоги.

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

Дэйв Чиннер прокомментировал производительность XFS с огромным количеством выделенных inodes , что привело к медленному touch производительность. Поиск свободного индексного дескриптора для выделения начинает занимать больше процессорного времени, так как битовая карта свободного индексного дескриптора фрагментируется. Обратите внимание, что это не проблема одного большого каталога по сравнению с несколькими каталогами, а проблема многих используемых inode во всей файловой системе. Разделение ваших файлов на несколько каталогов помогает с некоторыми проблемами, такими как та, которую ext4 задушила в OP, но не с проблемой отслеживания свободного места на всем диске. Отдельная файловая система на диск в Swift помогает в этом по сравнению с гигантской XFS на RAID5.

Я не знаю, хорош ли btrfs в этом, но я думаю, что может быть. Я думаю, что Facebook не зря нанимает своего ведущего разработчика.: P Некоторые тесты, которые я видел, например, распаковка исходного кода ядра Linux, показывают, что btrfs работает хорошо.

Я знаю, что reiserfs был оптимизирован для этого случая, но он почти не поддерживается, если вообще поддерживается. Я действительно не могу рекомендовать использовать reiser4. Хотя было бы интересно поэкспериментировать.Но это, безусловно, наименее надежный выбор. Я также видел отчеты о снижении производительности устаревшей файловой системы reiserFS, и нет хорошего инструмента дефрагментации. (Google файловая система миллионы маленьких файлов , и посмотрите на некоторые из существующих ответов stackexchange.)

Я, вероятно, чего-то упускаю, поэтому последняя рекомендация: спросите об этом на serverfault! Если бы мне нужно было что-то выбрать прямо сейчас, я бы сказал, попробуйте BTRFS, но убедитесь, что у вас есть резервные копии. (особенно, если вы используете встроенную в BTRFS избыточность нескольких дисков вместо того, чтобы запускать ее поверх RAID. Преимущества в производительности могут быть значительными, поскольку небольшие файлы - плохая новость для RAID5, если только это рабочая нагрузка, в основном, для чтения.)