几万个而已，真要算起来stat一个文件几毫秒的话，一个线程几十秒也能完成。你再想想服务器，一个进程每秒钟能接受上千请求，光写日志就写上万条，然后再乘以几十个进程。这才叫io密集型
至于 git，你觉得 git 会开几十个线程出来吗，很多操作都是非并行的。
至于编译，实际上是一个CPU密集型操作，一个进程访问文件的时候也是顺序的，实际的并行程度不会超过CPU核心数，而且大部分时间是耗在计算上而不是io上了

【 在 siegfried415 的大作中提到: 】
: 我经常用beyond compare对比两个目录，这两个目录中可能有几万个甚至几十万个文件，bc能做到在几十秒之内完成几十万个文件的比较，你觉得在这种情况下，操作系统会会不会每秒钟发出成千上万的读写指令？然后这些指令为什么就不能在ssd中被分配到不同的队列中来并行的去执行呢？
: 类似的操作，还有打包，压缩和解压缩，备份与同步，编译内核，git操作等等，都涉及到大量的小文件的读写，你怎么知道这些操作无法利用ssd的并行读写能力呢？
: --来自微水木3.5.1
--
FROM 221.219.97.*

跑分软件都能测试4k 64线程,bc或compare或sync这一大类软件用不到30线程我觉得不可能
【 在 siegfried415 的大作中提到: 】
: bc不是stat，而是读两个文件，然后对比，并将有差异的部分写入到文件中。至于你说git不会开几十个线程（并因此推断很多操作都是非并行的），我只是想说你很外行，现在操作系统和系统开发平台（比如twisted等）已经可以很好地做到异步IO了，根本不需要多个操作系统线程就可以产生大量异步IO请求了。
:
--
FROM 114.241.136.*

我发现你真是一个外行：
编过系统程序的都知道，小文件的读写是非常慢的，因为小文件读写的主要开销是花在系统调用的上下文切换环节上。说句题外话，被面试人如果用小文件的总长度来估计大量小文件操作的总开销，说明你对OS一知半解，肯定通不过我的面试的。。。


【 在 zli07 的大作中提到: 】
: 1. 无论怎么说，几十秒内对比完上万个文件的瓶颈都不在iops上，如果文件小的话，比如每个文件4KB，上万个文件才4MB，即使单线程也能搞定
: 2. 你告诉我异步文件IO？文件没有异步IO谢谢，无论是select/epoll/ev，都不支持文件，只能用在网络/管道上
: :
--
修改:siegfried415 FROM 113.232.128.*
FROM 113.232.128.*

我想反驳的是你的“用小文件的总长度来估算读取代价”的方式，任何人都知道，拷贝一个rar文件可能需要t秒，那么解压缩后拷贝，则需要的时间远远大于t/压缩比，文件越小数量越多速度越慢。

这就像两个人辩论，当一个人说1+1=20，那么这个讨论就完全进行不下去了一样。。。


【 在 zli07 的大作中提到: 】
: 就算再慢，几万个文件10秒钟也能读完。你要不要写个代码试试？
: :
--
修改:siegfried415 FROM 113.232.128.*
FROM 113.232.128.*

随便你，不会再回你了。。。

【 在 zli07 的大作中提到: 】
: 但是即使再烂的ssd，4K读写也能达到每秒好几兆的速度，换算成4K的话就是好几千个文件。
: 我的观点从来没有变过，那就是日常生活中的操作根本用不到4k 64thd，而你用的例子根本不能反对我的观点
: :
--
FROM 113.232.128.*