ubuntu 是如何管理i/o 的 ??

[shatai88]

今天下载一个游戏，居然没看见硬盘灯在闪？？ 太夸张了
以前用vista 时候，灯就没停过，更不用说bt了。
但是ubuntu 究竟怎么处理的呢？ 难道是写入一个i/o buffer, 这也太疯狂了，也不知道什么时候才转到硬盘？

[猛将兄]

kernel里面的确有buffer控制。但是软件实现才是主要部分。软件实现不好，一天到晚fwrite，那么硬盘灯还是狂亮。kernel里面的buffer只是很小的值而已（和用户空间的应用比起来）。而很多软件，实际上是攒到了一定的数量，比如1M才写一次，这样I/O频度就低很多了。同样，在windows下面，如果bt或者其他软件能适当控制fwrite的频率，那么硬盘灯也不会狂闪。这和什么OS没关系的

[lb_bn]

vista自己就一劲的读盘

[lb_bn]

vista自己就一个劲的读盘

[milujite]

楼上风怒了~~哈哈

[vvvli]

kernel里面的确有buffer控制。但是软件实现才是主要部分。软件实现不好，一天到晚fwrite，那么硬盘灯还是狂亮。kernel里面的buffer只是很小的值而已（和用户空间的应用比起来）。而很多软件，实际上是攒到了一定的数量，比如1M才写一次，这样I/O频度就低很多了。同样，在windows下面，如果bt或者其他软件能适当控制fwrite的频率，那么硬盘灯也不会狂闪。这和什么OS没关系的

关系当然有，如果文件系统 本身不是立即写入的。fwrite也没用。

[猛将兄]

kernel里面的确有buffer控制。但是软件实现才是主要部分。软件实现不好，一天到晚fwrite，那么硬盘灯还是狂亮。kernel里面的buffer只是很小的值而已（和用户空间的应用比起来）。而很多软件，实际上是攒到了一定的数量，比如1M才写一次，这样I/O频度就低很多了。同样，在windows下面，如果bt或者其他软件能适当控制fwrite的频率，那么硬盘灯也不会狂闪。这和什么OS没关系的

关系当然有，如果文件系统 本身不是立即写入的。fwrite也没用。

任何一个文件系统，都不可能认定一个很大的buffer值，通常就是几十K而已。几十K对于BT这种应用来说，根本不可能称之为buffer，一般bt的客户端最好以M为单位来进行批量写，否则你每收到一点就写一下，不管windows还是linux，磁盘都受不了

[vvvli]

kernel里面的确有buffer控制。但是软件实现才是主要部分。软件实现不好，一天到晚fwrite，那么硬盘灯还是狂亮。kernel里面的buffer只是很小的值而已（和用户空间的应用比起来）。而很多软件，实际上是攒到了一定的数量，比如1M才写一次，这样I/O频度就低很多了。同样，在windows下面，如果bt或者其他软件能适当控制fwrite的频率，那么硬盘灯也不会狂闪。这和什么OS没关系的

关系当然有，如果文件系统 本身不是立即写入的。fwrite也没用。

任何一个文件系统，都不可能认定一个很大的buffer值，通常就是几十K而已。几十K对于BT这种应用来说，根本不可能称之为buffer，一般bt的客户端最好以M为单位来进行批量写，否则你每收到一点就写一下，不管windows还是linux，磁盘都受不了

xfs buffer 没这么小吧。话说回来，反正现在硬盘自带8-16m cache，无所谓了。

[猛将兄]

kernel里面的确有buffer控制。但是软件实现才是主要部分。软件实现不好，一天到晚fwrite，那么硬盘灯还是狂亮。kernel里面的buffer只是很小的值而已（和用户空间的应用比起来）。而很多软件，实际上是攒到了一定的数量，比如1M才写一次，这样I/O频度就低很多了。同样，在windows下面，如果bt或者其他软件能适当控制fwrite的频率，那么硬盘灯也不会狂闪。这和什么OS没关系的

关系当然有，如果文件系统 本身不是立即写入的。fwrite也没用。

任何一个文件系统，都不可能认定一个很大的buffer值，通常就是几十K而已。几十K对于BT这种应用来说，根本不可能称之为buffer，一般bt的客户端最好以M为单位来进行批量写，否则你每收到一点就写一下，不管windows还是linux，磁盘都受不了

xfs buffer 没这么小吧。话说回来，反正现在硬盘自带8-16m cache，无所谓了。

完全 不是一个概念。fwrite涉及到用户空间向内核空间的copy操作，非常的昂贵。
如果一个fs的的buffer设置太大，在一些意外情况下，数据丢失是非常严重的。所以绝对不能依赖fs的buffer，要应用根据应用的需要来自行设置