我在一个目录中有数百万个文件(在有许多子目录的目录上),这些文件都是小文件。
我认为有两个挑战:
如何遍历目录查找所有文件。我尝试了“FindFirstFile/FindNextFile”的方式,但我觉得它太慢了。我应该使用Windows 更改日志吗?
找到所有文件名后,我需要将整个文件读入内存,然后解析它。我应该使用 FILE_FLAG_SEQUENTIAL_SCAN 标志吗?还是有更有效的方法?
我在一个目录中有数百万个文件(在有许多子目录的目录上),这些文件都是小文件。
我认为有两个挑战:
如何遍历目录查找所有文件。我尝试了“FindFirstFile/FindNextFile”的方式,但我觉得它太慢了。我应该使用Windows 更改日志吗?
找到所有文件名后,我需要将整个文件读入内存,然后解析它。我应该使用 FILE_FLAG_SEQUENTIAL_SCAN 标志吗?还是有更有效的方法?
NTFS,或者实际上任何非专业的文件系统在处理数百万个小文件时都会很慢。那是数据库的领域。
如果文件实际上很小,那么您如何阅读它们都无关紧要。间接费用将占主导地位。使用第二个线程可能是值得的,但第三个线程不太可能提供进一步的帮助。
此外,用于FindFirstFileEx
加快搜索速度。您不需要备用文件名,但更喜欢更大的缓冲区。
您可以使用NtQueryDirectoryFile
大缓冲区(例如 64 KB)来查询子项。
此功能是您可以与文件系统通信的最快速度的绝对限制。
如果这对您不起作用,您可以直接读取 NTFS 文件表,但这意味着您必须具有管理权限并且需要手动实现文件系统读取器。
一些想法可以解决..
我担心的是,如果您将文件的内容加载到内存中,您将很快耗尽服务器内存。您需要做的是找到有问题的文件并将结果写入您可以解析和解释的日志或报告。