linux查看python文件大小_Linux上文件的默认缓冲区大小

既然你链接到了2.7文档，我假设你使用的是2.7。(在Python3.x中，这一切都变得简单得多，因为更多的缓冲是在Python级别公开的。)

所有的open实际上所做的(在POSIX系统上)就是调用fopen，然后，如果您已经为buffering传递了任何内容，setvbuf。因为您没有传递任何内容，所以您只得到来自fopen的默认缓冲区，这取决于您的C标准库。(详见the source。如果没有buffering，它会将-1传递给PyFile_SetBufSize，除非bufsize >= 0，否则它不会执行任何操作。)

如果您阅读glibc ^{} manpage，它将解释如果您从未调用任何缓冲函数：Normally all files are block buffered. When the first I/O operation occurs on a file, malloc(3) is called, and a buffer is obtained.

注意，它并没有说明获得的缓冲区大小。这是有意的；这意味着实现可以是智能的，并为不同的情况选择不同的缓冲区大小。(有一个BUFSIZ常量，但这只在调用setbuf之类的遗留函数时使用；它不能保证在任何其他情况下使用。)

那么，会发生什么？如果你查看GLUBC源，它最终调用宏^ {A3}，它可以被钩住(或者被重写，因为GLUBC将C++ +流和C STDIO缓冲)结合起来，但是最终，它分配了一个^ {b13CD}}的BUF，这是平台特定宏^{}的别名，它是^ {CD15}}。

当然，您可能希望在自己的系统上跟踪宏，而不是信任通用源。

你可能想知道为什么没有好的记录方法来获取这些信息。大概是因为你不应该在意。如果您需要一个特定的缓冲区大小，可以手动设置；如果您相信系统最清楚，只需信任它。除非你真的在开发内核或libc，谁在乎呢？理论上，这也使得系统可以在这里做一些聪明的事情，比如根据文件系统的块大小选择bufsize，或者甚至基于运行的stats数据，尽管看起来不像linux/glibc、FreeBSD或OS X除了使用常量之外做任何事情。这很可能是因为这对大多数应用程序来说都无关紧要。(您可能希望自己测试一下，在一些缓冲的I/O绑定脚本上使用从1KB到2MB的显式缓冲区大小，并查看性能差异是什么。)