(免责声明:我只是想为这个有趣的讨论添加一些提示)恕我直言，有一些事情需要考虑:

(disclaimer: I want 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 库使用的系统服务可能会有很大差异.IE.在某些系统上，如果可能，库会广泛使用文件内存映射.

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) 正如您所说，不同的文件系统可能以非常不同的方式运行.特别是，我希望事务性文件系统必须做一些非常聪明而且可能很昂贵的事情，以准备好在文件中间进行中止的写入操作的可能回滚.

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) 现代操作系统具有非常激进的缓存算法.fseeked"文件可能已经存在于缓存中，因此操作变得更快.但是，如果其他进程产生的整体文件系统活动变得重要，它们可能会降级很多.

3) Modern OS'es have very aggressive caching algorithms. 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.

有什么意见吗?