смежное пространство на жестком диске - NTFS

Хорошо, давайте ответим по пунктам...

Вопрос 1: Когда я создаю файл в NTFS, сохраняется ли он непрерывно на физическом жестком диске?

Вопрос не имеет смысла. Когда вы создаете файл, NTFS выделяет место в MFT для метаданных, необходимых для отслеживания вещей. Небольшие файлы могут фактически поместиться в записи MFT для файла - такие резидентные файлы по определению являются непрерывными. Если файл не помещается в MFT, то блоки пространства выделяются по мере необходимости, и они могут быть или не быть смежными. Вообще говоря, она не знает, какого размера будет ваш файл или сколько места для него предварительно выделить, поэтому NTFS просто выделит место по мере необходимости, хотя вы можете дать ей подсказку, вызвав SetEndOfFile. Но это дает только подсказку и не гарантирует, что данные файла будут храниться в непрерывной области диска. На самом деле несложно убедить себя в том, что даже если файловая система выполняет дефрагментацию в реальном времени, она никогда не может *гарантировать, что свободное пространство будет доступно в виде единого непрерывного блока дисковых адресов.

Вопрос 2: если нет, есть ли способ создать файл таким образом, чтобы при записи в него данные сохранялись в нем непрерывно (на жестком диске)? Что-то вроде экстентов в базе данных.

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

Вопрос 3: если такой файл существует - есть ли способ прочитать данные из него (используя системный вызов C read) в группе/блоке. какой максимальный размер группы я могу использовать.

Системные вызовы C (такие как fread) не знают о NTFS, фрагментации, "связках" и блоках. Все, что они знают, это как прочитать запрошенное количество байтов из указанного дескриптора файла и поместить данные в предоставленный вами буфер. На самом деле вы можете указать любой размер, который вы хотите, хотя библиотека C будет вызывать API-интерфейсы операционной системы и файловой системы для чтения данных, кратных размеру блока, который определяется реализацией.

В соответствии с этим ответом суперпользователя вы можете вызовите SetEndOfFile, чтобы предоставить системе подсказку о размере файла, что позволит NTFS выделить непрерывное хранилище для всего файла.

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

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

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

1. Может быть. Но вы не можете гарантировать, что они будут храниться на физическом жестком диске непрерывно.

2. Вы можете, используя низкоуровневый необработанный доступ к жесткому диску. Для некоторых больших систем баз данных они не используют НИКАКОЙ файловой системы, а напрямую записывают/читают жесткий диск. А формирование данных на жестком диске определяется системой базы данных.

3. Независимо от того, как файл хранится физически, вы можете прочитать его в блоке на C. Я не думаю, что существует «максимальный размер пакета». Но существует «хороший размер пакета», как (размер блока файловой системы) * N.

Говорят, что файловая система reiserfs хороша для хранения множества маленьких файлов. Но я никогда не проверял это.