我的问题是关于 NTFS Fs 上的文件分配方法。
我有两个主要问题-
我正在尝试为小型应用程序创建一个基于文件的简单数据库，并希望在文件中创建我的数据库。出于性能原因，我需要将我的数据按连续顺序保存在磁盘上并成批读取。（我计划在我的应用程序中映射这个文件）。
根据这个超级用户的回答，您可以调用SetEndOfFile以向系统提供文件大小提示，这将允许 NTFS 为整个文件分配连续的存储空间。
多任务或多用户操作系统的另一个重要点是，即使文件是连续存储的，驱动器也可能会在文件访问过程中被另一个任务调用以读取或写入。这将导致驱动器完全寻找其他地方。在繁忙的系统上，这可能会不断发生。
操作系统驱动程序可以使用诸如scatter-gather或电梯算法之类的算法，这些算法尝试按照数据在磁盘上出现的顺序安排对各种任务缓冲区的读取或写入，因此磁头可以从内部到顺序扫描外部轨道 - 或反之亦然，沿途拾取或丢弃数据。
电梯算法之所以如此命名，是因为真正的电梯必须根据各楼层乘客的要求，选择最有效的装卸模式。他们不能浪费时间和精力无效率地上下波动。磁盘驱动器磁头定位差别不大。
好的，那么让我们逐点回答......
问题 1：当我在 NTFS 上创建文件时，它是否连续存储在物理硬盘上？
这个问题没有意义。当您创建文件时，NTFS 将在 MFT 中为它需要跟踪的元数据分配空间。小文件实际上可能适合文件的 MFT 记录 - 根据定义，此类常驻文件是连续的。如果文件不适合 MFT，则根据需要分配空间块，它们可能是连续的，也可能不是连续的。一般来说，它不知道你的文件有多大，也不知道要为它预分配多少空间——所以 NTFS 只会根据需要分配空间，尽管你可以通过调用SetEndOfFile函数来给它一个提示。但这仅提供提示，并不能保证文件数据将存储在磁盘的连续区域中。事实上，说服自己即使文件系统执行实时碎片整理，它也永远不能保证可用空间作为单个连续的磁盘地址块可用。
问题 2：如果没有 - 有没有办法创建一个文件，这样当我写入它时，数据会连续存储在其中（在硬盘上）？类似于数据库中的范围。
为什么你认为这是一个重要的问题？您通常不应该关心文件系统如何存储您的数据；您应该只关心它确实存储数据的事实。您可能认为访问非连续存储的文件会更慢，但不一定如此；高级缓存算法和操作系统的预取通常会完全消除任何减速。如果您关心的是性能，那么您是否有实际的硬数据表明文件系统的碎片是一个问题？如果是这样，正确的方法是使用不同的文件系统或根本不使用文件系统。
问题 3：如果存在这样的文件 - 有没有办法从它（使用 C 读取系统调用）中读取数据。我可以使用的最大束大小是多少。
C 系统调用（如fread）不了解 NTFS、碎片、“束”和块。他们所知道的只是如何从指定的文件句柄中读取请求的字节数并将数据放入您提供的缓冲区中。实际上，您可以指定您想要的任何大小，尽管 C 库将调用 O/S 和文件系统特定的 API 来读取块大小的倍数的数据，这是实现定义的。
有可能。但是您不能保证它连续存储在物理硬盘上。
您可以通过对硬盘的低级原始访问。对于一些大型数据库系统，它们不使用任何文件系统，而是直接写入/读取硬盘。而硬盘中的数据格式是由数据库系统定义的。
无论文件如何物理存储，您都可以在 C 中以块的形式读取它。我认为没有“最大束大小”。但是确实存在“良好的束大小”，例如（文件系统的块大小）* N。
据说文件系统 reiserfs 适合存储大量小文件。但我从未测试过它。