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