当前时区为 UTC + 8 小时



发表新帖 回复这个主题  [ 9 篇帖子 ] 
作者 内容
1 楼 
 文章标题 : ubuntu 是如何管理i/o 的 ??
帖子发表于 : 2007-12-22 14:48 

注册: 2007-12-22 1:42
帖子: 21
送出感谢: 0 次
接收感谢: 0 次
今天下载一个游戏,居然没看见硬盘灯在闪?? 太夸张了
以前用vista 时候,灯就没停过,更不用说bt了。
但是ubuntu 究竟怎么处理的呢? 难道是写入一个i/o buffer, 这也太疯狂了,也不知道什么时候才转到硬盘?


页首
 用户资料  
 
2 楼 
 文章标题 :
帖子发表于 : 2007-12-22 15:13 
头像

注册: 2005-10-19 17:33
帖子: 2052
送出感谢: 0 次
接收感谢: 0 次
kernel里面的确有buffer控制。但是软件实现才是主要部分。软件实现不好,一天到晚fwrite,那么硬盘灯还是狂亮。kernel里面的buffer只是很小的值而已(和用户空间的应用比起来)。而很多软件,实际上是攒到了一定的数量,比如1M才写一次,这样I/O频度就低很多了。同样,在windows下面,如果bt或者其他软件能适当控制fwrite的频率,那么硬盘灯也不会狂闪。这和什么OS没关系的


页首
 用户资料  
 
3 楼 
 文章标题 :
帖子发表于 : 2007-12-22 21:51 

注册: 2007-02-25 16:56
帖子: 1261
送出感谢: 0 次
接收感谢: 0 次
vista自己就一劲的读盘 :lol:


页首
 用户资料  
 
4 楼 
 文章标题 :
帖子发表于 : 2007-12-22 21:51 

注册: 2007-02-25 16:56
帖子: 1261
送出感谢: 0 次
接收感谢: 0 次
vista自己就一个劲的读盘 :lol:


页首
 用户资料  
 
5 楼 
 文章标题 :
帖子发表于 : 2007-12-23 0:05 
头像

注册: 2007-01-01 22:14
帖子: 644
送出感谢: 0 次
接收感谢: 0 次
楼上风怒了~~哈哈


页首
 用户资料  
 
6 楼 
 文章标题 :
帖子发表于 : 2007-12-24 0:01 

注册: 2006-10-26 7:02
帖子: 441
送出感谢: 0 次
接收感谢: 0 次
猛将兄 写道:
kernel里面的确有buffer控制。但是软件实现才是主要部分。软件实现不好,一天到晚fwrite,那么硬盘灯还是狂亮。kernel里面的buffer只是很小的值而已(和用户空间的应用比起来)。而很多软件,实际上是攒到了一定的数量,比如1M才写一次,这样I/O频度就低很多了。同样,在windows下面,如果bt或者其他软件能适当控制fwrite的频率,那么硬盘灯也不会狂闪。这和什么OS没关系的

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


页首
 用户资料  
 
7 楼 
 文章标题 :
帖子发表于 : 2007-12-24 8:45 
头像

注册: 2005-10-19 17:33
帖子: 2052
送出感谢: 0 次
接收感谢: 0 次
vvvli 写道:
猛将兄 写道:
kernel里面的确有buffer控制。但是软件实现才是主要部分。软件实现不好,一天到晚fwrite,那么硬盘灯还是狂亮。kernel里面的buffer只是很小的值而已(和用户空间的应用比起来)。而很多软件,实际上是攒到了一定的数量,比如1M才写一次,这样I/O频度就低很多了。同样,在windows下面,如果bt或者其他软件能适当控制fwrite的频率,那么硬盘灯也不会狂闪。这和什么OS没关系的

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

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


页首
 用户资料  
 
8 楼 
 文章标题 :
帖子发表于 : 2007-12-24 14:24 

注册: 2006-10-26 7:02
帖子: 441
送出感谢: 0 次
接收感谢: 0 次
猛将兄 写道:
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,无所谓了。


页首
 用户资料  
 
9 楼 
 文章标题 :
帖子发表于 : 2007-12-24 15:04 
头像

注册: 2005-10-19 17:33
帖子: 2052
送出感谢: 0 次
接收感谢: 0 次
vvvli 写道:
猛将兄 写道:
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,无所谓了。

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


页首
 用户资料  
 
显示帖子 :  排序  
发表新帖 回复这个主题  [ 9 篇帖子 ] 

当前时区为 UTC + 8 小时


在线用户

正在浏览此版面的用户:没有注册用户 和 2 位游客


不能 在这个版面发表主题
不能 在这个版面回复主题
不能 在这个版面编辑帖子
不能 在这个版面删除帖子
不能 在这个版面提交附件

前往 :  
本站点为公益性站点,用于推广开源自由软件,由 DiaHosting VPSBudgetVM VPS 提供服务。
我们认为:软件应可免费取得,软件工具在各种语言环境下皆可使用,且不会有任何功能上的差异;
人们应有定制和修改软件的自由,且方式不受限制,只要他们自认为合适。

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
简体中文语系由 王笑宇 翻译