带NTFS的Windows如何使用大量文件和目录？
在遇到性能问题或其他问题之前,是否有关于可以放在单个目录中的文件或目录限制的指导？
例如,在其中有一个包含100,000个文件夹的文件夹,这是一件好事吗？
以下是来自环境的人的一些建议,其中我们有包含数千万个文件的文件夹.
文件夹将索引信息(指向子文件和子文件夹的链接)存储在索引文件中.当你有很多孩子时,这个文件会变得非常大.请注意,它不区分作为文件夹的子项和作为文件的子项.唯一的区别是该子项的内容是子文件夹索引或子文件数据.注意:我在某种程度上简化了这一点,但这得到了重点.
索引文件将碎片化.当它过于分散时,您将无法将文件添加到该文件夹.这是因为允许的片段数量有限制.这是设计的.我已经在支持事件调用中向微软证实了这一点.因此,虽然文件夹中可以拥有的文件数量的理论限制是几十亿,但是当你开始点击数千万个文件时会好运,因为你将首先达到碎片限制.
然而,这并不全是坏事.您可以使用该工具:contig.exe对此索引进行碎片整理.它不会减小索引的大小(对于数千万个文件,它可以达到几个Gigs),但是你可以减少片段的数量.注意:磁盘碎片整理工具不会对文件夹的索引进行碎片整理.它将整理文件数据.只有contig.exe工具会对索引进行碎片整理.仅供参考:您也可以使用它来整理单个文件的数据.
如果要进行碎片整理,请不要等到达到碎片限制的最大数量.我有一个文件夹,我无法碎片整理,因为我等到太晚了.我的下一个测试是尝试将一些文件从该文件夹移动到另一个文件夹中,以查看我是否可以对其进行碎片整理.如果失败了,那么我要做的就是1)创建一个新文件夹.2)将一批文件移动到新文件夹.3)对新文件夹进行碎片整理.重复#2直到完成,然后4)删除旧文件夹并重命名新文件夹以匹配旧文件夹.
更直接地回答您的问题:如果您正在查看100K条目,请不要担心.去敲你自己.如果你正在查看数以千万计的条目,那么:
a)制定计划将它们细分为子文件夹(例如,假设您有100M文件.最好将它们存储在1000个文件夹中,这样每个文件夹只有100,000个文件,而不是将它们存储到1个大文件夹中.将创建1000个文件夹索引,而不是一个更有可能达到最大片段限制的单个大文件索引
b)计划定期运行contig.exe以保持大文件夹的索引碎片整理.
只有在你感到无聊时才阅读以下内容.
实际限制不在片段的#上,而在于存储指向片段的指针的数据段的记录数.
所以你拥有的是一个存储指向目录数据片段的指针的数据段.目录数据存储关于该目录据称存储的子目录和子文件的信息.实际上,目录不会"存储"任何内容.它只是一种跟踪和呈现功能,它向用户呈现层次结构的错觉,因为存储介质本身是线性的.
短文件名创建也会降低性能问题.如果文件夹中有超过300k的文件,Microsoft建议关闭短文件名创建[1].前6个字符的唯一性越小,问题就越多.
[1] NTFS的工作原理来自http://technet.microsoft.com,搜索"300,000"
我正在构建一个文件结构来托管多达20亿(2 ^ 32)个文件,并执行以下测试,显示固态硬盘上每个NTFS目录大约250个文件或120个目录的导航+读取性能急剧下降( SSD):
文件性能在250到1000个文件之间下降50%.
目录性能在120到1000个目录之间下降了60%.
数字> 1000的值保持相对稳定
有趣的是,目录和文件的数量不会显着干扰.
所以课程是:
250以上的文件编号成本为2
120以上的目录成本为2.5
Windows 7中的File-Explorer可以处理大型#Files或#Dirs,但可用性仍然很糟糕.
引入子目录并不昂贵
这是数据(每个文件和目录的2次测量):
(FOPS = File Operations per Second) (DOPS = Directory Operations per Second) #Files lg(#) FOPS FOPS2 DOPS DOPS2 10 1.00 16692 16692 16421 16312 100 2.00 16425 15943 15738 16031 120 2.08 15716 16024 15878 16122 130 2.11 15883 16124 14328 14347 160 2.20 15978 16184 11325 11128 200 2.30 16364 16052 9866 9678 210 2.32 16143 15977 9348 9547 220 2.34 16290 15909 9094 9038 230 2.36 16048 15930 9010 9094 240 2.38 15096 15725 8654 9143 250 2.40 15453 15548 8872 8472 260 2.41 14454 15053 8577 8720 300 2.48 12565 13245 8368 8361 400 2.60 11159 11462 7671 7574 500 2.70 10536 10560 7149 7331 1000 3.00 9092 9509 6569 6693 2000 3.30 8797 8810 6375 6292 10000 4.00 8084 8228 6210 6194 20000 4.30 8049 8343 5536 6100 50000 4.70 7468 7607 5364 5365
这是测试代码:
[TestCase(50000, false, Result = 50000)]
[TestCase(50000, true, Result = 50000)]
public static int TestDirPerformance(int numFilesInDir, bool testDirs) {
var files = new List();
var dir = Path.GetTempPath() + "\\Sub\\" + Guid.NewGuid() + "\\";
Directory.CreateDirectory(dir);
Console.WriteLine("prepare...");
const string FILE_NAME = "\\file.txt";
for (int i = 0; i < numFilesInDir; i++) {
string filename = dir + Guid.NewGuid();
if (testDirs) {
var dirName = filename + "D";
Directory.CreateDirectory(dirName);
using (File.Create(dirName + FILE_NAME)) { }
} else {
using (File.Create(filename)) { }
}
files.Add(filename);
}
//Adding 1000 Directories didn't change File Performance
/*for (int i = 0; i < 1000; i++) {
string filename = dir + Guid.NewGuid();
Directory.CreateDirectory(filename + "D");
}*/
Console.WriteLine("measure...");
var r = new Random();
var sw = new Stopwatch();
sw.Start();
int len = 0;
int count = 0;
while (sw.ElapsedMilliseconds < 5000) {
string filename = files[r.Next(files.Count)];
string text = File.ReadAllText(testDirs ? filename + "D" + FILE_NAME : filename);
len += text.Length;
count++;
}
Console.WriteLine("{0} File Ops/sec ", count / 5);
return numFilesInDir;
}
100,000应该没问题.
我(有趣地)看到人们遇到了数百万个文件的问题,而且我自己也遇到过问题,只是不知道如何计算过去60多万个文件,但NTFS应该对你正在谈论的卷有好处.
如果你想知道,技术(我希望理论上)最大文件数是:4,294,967,295
对于本地访问,大量目录/文件似乎不是问题.但是,如果您通过网络访问它,那么在几百个之后就会出现明显的性能损失(尤其是从Vista计算机访问时(XP到Windows Server w/NTFS似乎在这方面运行得更快)).
京公网安备 11010802040832号 | 京ICP备19059560号-6 