Скажем, вы начинаете с чистого листа, то есть вы вообще не обращались к файловой системе. Теперь скажите, что вы запустили stat («/ some / dir / file»). Сначала ядро должно найти файл, который в технических терминах называется inode. Он начинается с просмотра суперблока файловой системы, в котором хранится inode корневого каталога. Затем он открывает корневой каталог, находит «some», открывает его, находит «dir» и т. Д., В конце концов, находит индекс для файла.
Затем вы должны прочитать данные inode. После первого чтения это также кешируется в оперативной памяти. Таким образом, только чтение должно произойти один раз.
Думайте о HD, как о старом проигрывателе, и, как только вы окажетесь в нужном месте с иглой, вы сможете продолжать читать материал быстро, пока он вращается. Однако, когда вам нужно переехать в другое место, называемое «поиск», вы делаете что-то совсем другое. Вам нужно физически переместить руку, затем подождать, пока блюдо начнет вращаться, пока нужное место не окажется под иглой. Этот вид физического движения по своей сути медленный, поэтому время поиска дисков довольно длинное.
Итак, когда мы ищем? Конечно, это зависит от структуры файловой системы. Файловые системы пытаются хранить файлы последовательно, чтобы повысить производительность чтения, и они также обычно пытаются хранить inode для одного каталога рядом друг с другом, но все это зависит от таких вещей, как, когда файлы записываются, фрагментация файловой системы и т. Д. Итак, в худшем В этом случае каждая статистика файла будет вызывать поиск, а затем каждое открытие файла будет вызывать повторный поиск. Так вот почему вещи занимают так много времени, когда ничего не кэшируется.
Некоторые файловые системы лучше, чем другие, дефрагментация может помочь. Вы можете делать некоторые вещи в приложениях. Например, GIO сортирует полученные inode от readdir () перед тем, как заявить о них, надеясь, что номер inode имеет какое-то отношение к порядку диска (как правило, имеет), таким образом сводя к минимуму случайный поиск назад и вперед.
Одной из важных вещей является разработка хранилища данных и приложений для минимизации поиска. Например, именно поэтому Nautilus читает / usr / bin медленно, потому что файлы там, как правило, не имеют расширения, которое нам нужно для магического сниффинга для каждого. Итак, нам нужно открыть каждый файл => один запрос на файл => slooooow. Другой пример - приложения, которые хранят информацию во множестве небольших файлов, как это обычно делал gconf, что также является плохой идеей. Во всяком случае, на практике я не думаю, что вы можете многое сделать, кроме как пытаться скрыть задержки.