（声明：我不会只是一些提示添加到这个有趣的讨论）
恕我直言，有一些事情要考虑到：

(disclaimer: I wont just to add some hints to this interesting discussion) IMHO there are some things to take into account:

1）fseek的不是主系统的服务，但是一个库功能。为了评估其性能，我们必须考虑文件流库是如何实现的。在一般情况下，该文件I / O库补充在用户空间中的缓冲层，所以fseek的性能可能相当不同，如果目标位置的内部或当前缓冲区之外。此外，该系统服务的I / O libary用途可能有很大的差异。即在某些系统上图书馆广泛使用的文件内存映射如果可能的话。

1) fseek is not a primary system service, but a library function. To evaluate its performance we must consider how the file stream library is implemented. In general, the file I/O library adds a layer of buffering in user space, so the performance of fseek may be quite different if the target position is inside or outside the current buffer. Also, the system services that the I/O libary uses may vary a lot. I.e. on some systems the library uses extensively the file memory mapping if possible.

2），正如你所说，不同的文件系统的行为可能在一个非常不同的方式。特别是，我会期望一个文件系统的事务必须做一些非常聪明的，也许昂贵的是在一个文件中间ppared来中止写入操作的可能回滚$ P $。

2) As you said, different filesystems may behave in a very different way. In particular, I would expect that a transactional filesystem must do something very smart and perhaps expensive to be prepared to a possible rollback of an aborted write operation in the middle of a file.

3）现代化OS'es有非常积极的缓存algorythms。一个fseeked文件很可能是已经$缓存p $ psent，所以操作变得快得多。但是，他们可能会降低很多，如果被其他进程所产生的整体文件系统活动变得重要起来。

3) The modern OS'es have very aggressive caching algorythms. An "fseeked" file is likely to be already present in cache, so operations become much faster. But they may degrade a lot if the overall filesystem activity produced by other processes become important.

有何评论？
 问候

Any comments? Regards