4

Я хотел бы сделать ls -laR /media/myfs в Linux как можно быстрее. У меня будет 1 миллион файлов в файловой системе, 2 ТБ общего размера файла и несколько каталогов, содержащих до 10000 файлов. Какую файловую систему мне использовать и как ее настроить?

Насколько я понимаю, причина, по которой ls -laR медленная, потому что он должен иметь stat(2) каждого inode (т.е. 1 миллион stat(2) s), а также потому, что inode распределяются случайным образом на диске, каждый stat(2) нужен один диск искать.

Вот некоторые решения, которые я имел в виду, и ни одно из которых меня не устраивает:

  • Создайте файловую систему на SSD, потому что операции поиска на SSD выполняются быстро. Это не сработает, потому что твердотельный накопитель емкостью 2 ТБ не существует или он слишком дорогой.

  • Создайте файловую систему, которая охватывает два блочных устройства: SSD и диск; диск содержит данные файла, а SSD содержит все метаданные (включая записи каталога, inode и расширенные атрибуты POSIX). Есть ли файловая система, которая поддерживает это? Выдержит ли это системный сбой (перебои в подаче электроэнергии)?

  • Используйте find /media/myfs в ext2, ext3 или ext4 вместо ls -laR /media/myfs , поскольку первое может использовать преимущество поля d_type (см. Справочную страницу getdents(2) ), поэтому оно не должны стат. К сожалению, это не соответствует моим требованиям, потому что мне нужны также файлы всех размеров, которые не find /media/myfs .

  • Используйте файловую систему, такую как VFAT, которая хранит inode в записях каталога. Я хотел бы этого, но VFAT не достаточно надежен и гибок для меня, и я не знаю ни одной другой файловой системы, которая делает это. Вы? Конечно, хранение inode в записях каталога не будет работать для файлов с количеством ссылок больше 1, но это не проблема, поскольку в моем случае использования у меня всего несколько десятков таких файлов.

  • Настройте некоторые параметры в /proc или sysctl так, чтобы inode был навсегда заблокирован в системной памяти. Это не ускорит первые ls -laR /media/myfs , но сделает все последующие вызовы удивительно быстрыми. Как я могу это сделать? Мне не нравится эта идея, потому что она не ускоряет первый вызов, который в настоящее время занимает 30 минут. Также я бы хотел заблокировать расширенные атрибуты POSIX в памяти. Что я должен сделать для этого?

  • Используйте файловую систему, которая имеет онлайн-инструмент для дефрагментации, который может быть инструктирован для перемещения inode в начало блочного устройства. Как только перемещение выполнено, я могу запустить dd if=/dev/sdb of=/dev/null bs=1M count=256 чтобы получить начало блочного устройства, извлеченного в кэш-память ядра без поиска, а затем Операции stat(2) будут быстрыми, потому что они читают из кеша. Есть ли способ заблокировать эти inode и / или блоки в памяти после их чтения? В какой файловой системе есть такой инструмент дефрагментации?

|источник

4 ответа4

2

Ответа, к сожалению, нет, хотя я и нашел ответ в Google за последние полчаса.

Создайте файловую систему, которая охватывает два блочных устройства: SSD и диск; диск содержит данные файла, а SSD содержит все метаданные (включая записи каталога, inode и расширенные атрибуты POSIX). Есть ли файловая система, которая поддерживает это? Выдержит ли это системный сбой (перебои в подаче электроэнергии)?

Именно то, что я тоже хотел бы.

Для ссылок, смотрите эту вставку, потому что я не могу публиковать более одной ссылки ...

http://www.notehub.org/2014/10/2/external-metadata-more-information

Поддержка нескольких устройств от btrfs обсуждается здесь:

Btrfs: Работа с несколькими устройствами, Джонатан Корбет, 30 декабря 2013 г. (LWN), [ссылка] [1]

Но хотя вы можете зеркально отразить метаданные (-m raid1) на SSD, вы вынуждены также использовать SSD для хранения данных (-d raid0), хотя бы частично.

Хорошей новостью является то, что работа ведется:

Выделенные метаданные управляют Яном Шмидтом и Арне Янсеном (пока не в ядре). Мы можем очень легко разделить ввод-вывод данных и метаданных. Метаданные, как правило, преобладают в поисках, и для многих приложений имеет смысл размещать метаданные на более быстрых твердотельных накопителях. [Ссылка] [2]

Если вы готовы использовать проприетарную общую параллельную файловую систему (GPFS) от IBM, то, похоже, это уже возможно. Прочтите "Как перенести все метаданные файловой системы GPFS на твердотельные накопители": [ссылка] [3]

|источник
2

диск содержит данные файла, а SSD содержит все метаданные ... Есть ли файловая система, которая поддерживает это?

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

|источник
2

Я обменяю вам мой ответ на ваш вопрос на ваш ответ на мой: Какие регуляторы нужно использовать в /proc или /sys, чтобы сохранить все inode в памяти?

Теперь для моего ответа на ваш вопрос:

Я борюсь с подобной проблемой, когда пытаюсь заставить ls -l быстро работать над NFS для каталога с несколькими тысячами файлов, когда сервер сильно загружен.

NetApp блестяще выполняет задачу; все остальное, что я пробовал до сих пор не делает.

Исследуя это, я обнаружил несколько файловых систем, которые отделяют метаданные от данных, но у всех них есть некоторые недостатки:

  • dualfs: есть некоторые патчи для 2.4.19, но не намного.
  • luster: ls -l - сценарий наихудшего случая, поскольку все метаданные, кроме размера файла, хранятся на сервере метаданных.
  • QFS для Solaris, StorNext/Xsan: не известен высокой производительностью метаданных без значительных инвестиций.

Так что это не поможет (если вы не можете оживить dualfs).

Лучший ответ в вашем случае - максимально увеличить количество шпинделей. Самый уродливый, но самый дешевый и практичный способ сделать это - получить JBOD (или две) корпоративного класса от Ebay, которым несколько лет. Если вы будете выглядеть пристально, вы сможете удерживать свои расходы на уровне менее $ 500 или около того. Поисковые термины "146gb" и "73gb" будут очень полезны. Вы должны быть в состоянии убедить продавца заключить сделку на что-то вроде этого, так как у них есть куча из них, сидящих без дела, и вряд ли какие-либо заинтересованные покупатели:

http://cgi.ebay.ca/StorageTek-Fibre-Channel-2TB-14-Bay-HDD-Array-JBOD-NAS-/120654381562?pt=UK_Computing_Networking_SM&hash=item1c178fc1fa#ht_2805wt_1056

Установите полосу RAID-0 на всех дисках. Резервное копирование ваших данных, потому что один или два диска неизбежно выйдет из строя. Используйте tar для резервного копирования вместо cp или rsync, чтобы принимающему отдельному диску не приходилось иметь дело с миллионами inode.

Это единственный дешевый способ, который я нашел (в любом случае, в данный исторический момент) для увеличения IOP для файловых систем в диапазоне 2-4 ТБ.

Надеюсь, что это поможет - или хотя бы интересно!

|источник
1

Я бы просто использовал ext4 и убедился, что у вас установлен dir_index. Вы можете проверить этот флаг, выполнив это:

dumpe2fs /dev/drivepartition | grep "Filesystem features:"

Самая большая проблема, с которой вы столкнетесь, это просто общее количество файлов в файловой системе. Любая операция, которую вы выполняете в файловой системе, должна проверять каждый файл. Это касается любой файловой системы. 10000 файлов в каталоге может показаться большим, но я обнаружил, что файловые системы не работают медленно, пока вы не получите 40000 файлов или более, и это действительно более старый признак файловых систем, таких как ext2.

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

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .