Файловая система Linux с inodes закрывается на диске
Я хотел бы сделать ls -laR /media/myfs на Linux максимально быстро. У меня будет 1 миллион файлов в файловой системе, 2 ТБ общего размера файла и некоторые каталоги, содержащие целых 10 000 файлов. Какую файловую систему я должен использовать и как я должен настроить ее?
Насколько я понимаю, причина почему ls -laR является медленным, потому что это имеет к stat(2) каждый inode (т.е. 1 миллион stat(2)s), и так как inodes распределяются случайным образом на диске, каждом stat(2) потребности один поиск на диске.
Вот некоторые решения, которые я имел в виду, ни один из которого я удовлетворен:
Создайте файловую систему на SSD, потому что искать операции на SSD быстры. Это не работало бы, потому что SSD на 2 ТБ не существует, или это непомерно дорого.
Создайте файловую систему, которая охватывает на двух блочных устройствах: SSD и диск; диск содержит данные файла, и SSD содержит все метаданные (включая записи каталога, inodes, и POSIX расширил атрибуты). Существует ли файловая система, которая поддерживает это? Это пережило бы системный катастрофический отказ (перебой в питании)?
Использовать
find /media/myfsна ext2, ext3 или ext4, вместоls -laR /media/myfs, потому что первый может преимуществоd_typeполе (см. вgetdents(2)страница справочника), таким образом, это не имеет к статистике. К сожалению, это не отвечает моим требованиям, потому что мне нужны все размеры файла также, которыйfind /media/myfsне печатает.Используйте файловую систему, такую как VFAT, который хранит inodes в записях каталога. Я любил бы этого, но VFAT не надежен и достаточно гибок для меня, и я не знаю ни о какой другой файловой системе, которая делает это. Вы? Конечно, хранение inodes в записях каталога не работало бы на файлы с числом каналов больше чем 1, но это не проблема, так как у меня есть только несколько дюжин таких файлов в моем варианте использования.
Скорректируйте некоторые настройки в
/procилиsysctlтак, чтобы inodes были заблокированы к системной памяти навсегда. Это не ускорило бы первоеls -laR /media/myfs, но это сделало бы все последующие вызовы удивительно быстро. Как я могу сделать это? Мне не нравится эта идея, потому что она не ускоряет первый вызов, который в настоящее время занимает 30 минут. Также я хотел бы заблокировать расширенные атрибуты POSIX в памяти также. Что я должен сделать для этого?Используйте файловую систему, которая имеет инструмент дефрагментации онлайн, который может быть проинструктирован для перемещения inodes к начало блочного устройства. После того как перемещение сделано, я могу работать
dd if=/dev/sdb of=/dev/null bs=1M count=256получить начало блочного устройства, выбранного к ядру кэш в оперативной памяти без поиска, и затемstat(2)операции были бы быстры, потому что они читают из кэша. Существует ли способ заблокировать те inodes и/или блоки в память, после того как они были считаны? Какая файловая система имеет такой инструмент дефрагментации?
2 ответа
Я просто использовал бы ext4 и удостоверился бы, что у Вас есть набор dir_index. Можно проверить на тот флаг путем выполнения этого:
dumpe2fs /dev/drivepartition | grep "Filesystem features:"
Самой большой проблемой, с которой Вы столкнетесь, является просто количество файлов в целом в файловой системе. Любая операция Вы натыкаетесь на файловую систему, должна будет посмотреть на каждый файл. Дело обстоит так с любой файловой системой. 10 000 файлов в каталоге могут походить на много, но я нахожу, что файловые системы не становятся медленными, пока Вы не добираетесь до 40 000 файлов или больше и это - действительно более старый признак файловых систем как ext2.
Это кажется, что Вы пытаетесь сделать что-то определенное, а не просто иметь файловую систему общего назначения. Если можно объяснить, что Вы пытаетесь сделать, мы можем, вероятно, предложить способ оптимизировать Ваши данные. Например, база данных.
Я буду торговать Вами мой ответ на Ваш вопрос для Вашего ответа на мой: Что кнопки должны играться в/proc или/sys для хранения всего inodes в памяти?
Теперь для моего ответа на Ваш вопрос:
Я борюсь с проблемой подобного выхода, где я пытаюсь заставить ls-l работать быстро по NFS для каталога с несколькими тысячами файлов, когда сервер в большой степени загружается.
NetApp выполняет задачу блестяще; все остальное, что я попробовал до сих пор, не делает.
Исследуя это, я нашел несколько файловых систем, которые разделяют метаданные от данных, но у них всех есть некоторые недостатки:
- dualfs: Очень еще имеет некоторые патчи в наличии для 2.4.19, но не.
- блеск: ls-l является худшим вариантом, потому что все метаданные кроме размера файла хранятся на сервере метаданных.
- QFS для Соляриса, StorNext/Xsan: Не известный большой производительностью метаданных без существенных инвестиций.
Таким образом, это не поможет (если Вы не сможете восстановить dualfs).
Лучший ответ в Вашем случае должен увеличить Ваше шпиндельное количество как можно больше. Самое ужасное - но самый дешевый и самый практичный - способ сделать это должно получить JBOD промышленного класса (или два) и карта волоконно-оптического канала прочь eBay, которые несколько лет. Если Вы выглядите твердыми, необходимо смочь сохранить затраты менее чем 500$ или около этого. Критерии поиска "146 ГБ" и "73 ГБ" очень помогут. Необходимо смочь убедить продавца заключать сделку на чем-то вроде этого, так как у них есть набор того, что они сидели без дела и едва любых заинтересованных покупателей:
Настройте RAID 0 дорожек через все диски. Создайте резервную копию своих данных неукоснительно, потому что один или два из дисков неизбежно перестанет работать. Используйте tar для резервного копирования вместо CP или rsync так, чтобы получающий единственный диск не должен был иметь дело с миллионами inodes.
Это - единственный самый дешевый способ, которым я нашел (в этот конкретный исторический момент, так или иначе) для увеличения IOPs для файловых систем в 2-4TB диапазоне.
Надежда, которая помогает - или по крайней мере интересна!