Чтение файлов по устройству / порядку inode?

Question

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

Answer 1

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

Более того, Linux ухудшает ваши шаблоны доступа во время сканирования каталогов, возвращая записи каталога в пространство пользователя в порядке хеш-таблиц, а не в физическом порядке.,К счастью, Linux также предоставляет системные вызовы для определения физического местоположения файла и того, хранится ли файл на ротационном устройстве, чтобы вы могли восстановить некоторые потери.Посмотрите, например, этот патч, который я представил dpkg несколько лет назад:

http://lists.debian.org/debian-dpkg/2009/11/msg00002.html

Этот патч не включает в себя тест для ротационных устройств, потому что эта функция не была добавлена ​​в Linux до 2012 года:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ef00f59c95fe6e002e7c6e3663cdea65e253f4cc

Я также использовал запатентованную версию Mutt, которая сканировала бы Maildirs в физическом порядке, обычно давая увеличение скорости в 5-10 раз.

Примечаниечто иноды небольшие, с большой предварительной выборкой и кэшированием, поэтому открытие файлов для определения их физического местоположения перед чтением стоит затрат.Это правда, что обычные инструменты, такие как tar, rsync, cp и PostgreSQL, не используют эти методы, и простая истина заключается в том, что это делает их излишне медленными.

Answer 2

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

Answer 3

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

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

2) Сортировка файлов по имени или номеру индекса фактически ничего не меняет в общем случае.Вам нужно отсортировать файлы по физическому расположению их блоков на диске, чтобы их можно было прочитать с минимальным поиском.Однако существует довольно много препятствий:

• Большинство файловых систем не предоставляют такую ​​информацию приложениям пользовательского пространства, кроме как по причинам отладки.

• Сами блоки каждого файла могут быть распределены по всему диску, особенно в большей части файловой системы.Невозможно последовательно читать несколько файлов без поиска назад и вперед.

• Вы предполагаете, что ваш процесс является единственным, обращающимся к подсистеме хранения.Как только кто-то еще делает то же самое, каждая оптимизация, которую вы предлагаете, уходит из окна.

• Вы пытаетесь быть умнее, чем операционная система и ее собственное кэширование иМеханизмы планирования ввода / вывода.Весьма вероятно, что, пытаясь угадать ядро, то есть единственное, которое действительно знает вашу систему и ваши шаблоны использования, вы ухудшите ситуацию.

• Не думаете ли вы, например, что PostreSQL или Oracle использовали бы подобную технику, если бы могли?Когда БД установлена ​​в надлежащей файловой системе, они позволяют ядру делать свое дело и не пытаются переоценить свои решения.Только когда БД находится на необработанном устройстве, вступают в действие специализированные алгоритмы оптимизации, учитывающие физические блоки.

• Вы также должны принимать во внимание специфические свойства своих устройств хранения.Например, современные твердотельные накопители делают традиционную оптимизацию времени поиска устаревшей.