Documentation目录下的as-iosched.txt文档翻译
唐泳
Anticipatory IO scheduler
预期IO调度程序
-------------------------
Nick Piggin <piggin@cyberone.com.au> 13 Sep 2003
Attention! Database servers, especially those using "TCQ" disks should
investigate performance with the 'deadline' IO scheduler. Any system with high
disk performance requirements should do so, in fact.
注意！数据库服务器，特别是那些使用“TCQ”磁盘应该研究一下使用'deadline'IO调度程序
的性能。事实上，任何使用高性能磁盘的系统都应该考虑到这些。
If you see unusual performance characteristics of your disk systems, or you
see big performance regressions versus the deadline scheduler, please email
me. Database users don't bother unless you're willing to test a lot of patches
from me ;) its a known issue.
如果你看到你的磁盘系统中有不寻常的性能特征或者是你看到一个高性能的回归分析和使用了
期限调度的话，请一定要给我发邮件。数据库使用者不必困扰，除非你想要在我这里测试大量
的补丁。
Selecting IO schedulers
选择IO调度程序
-----------------------
To choose IO schedulers at boot time, use the argument 'elevator=deadline'.
'noop' and 'as' (the default) are also available. IO schedulers are assigned
globally at boot time only presently.
为了能够在启动期间选择IO调度程序，请使用参数'elevator=deadline'.'noop'和'as'也是
可以的。目前，IO调度程序只能够在启动期间被全局分配。
Tuning the anticipatory IO scheduler
调谐预期调度
------------------------------------
When using 'as', the anticipatory IO scheduler there are 5 parameters under
/sys/block/*/iosched/. All are units of milliseconds.
当使用'as'的时候，预期调度程序在目录/sys/block/*/iosched下由5个参数，这5个参数都是以
毫秒为单位的。
The parameters are:
这五个参数分别是：
* read_expire
Controls how long until a request becomes "expired". It also controls the
interval between which expired requests are served, so set to 50, a request
might take anywhere < 100ms to be serviced _if_ it is the next on the
expired list. Obviously it won't make the disk go faster. The result
basically equates to the timeslice a single reader gets in the presence of
other IO. 100*((seek time / read_expire) + 1) is very roughly the %
streaming read efficiency your disk should get with multiple readers.
控制一个请求到什么时候是过期的。同时他也控制哪一个过期的请求能够被服务的时间间隔，
所以被设置乘50.在过期列表上的下一个请求可能被带到任何地方在小于100毫秒的时候被
服务。很明显，他不会使磁盘变得更快。这个结果基本上等同于在其他IO的中一个单独的
读程序获取的一个时间片。
* read_batch_expire
Controls how much time a batch of reads is given before pending writes are
served. Higher value is more efficient. This might be set below read_expire
if writes are to be given higher priority than reads, but reads are to be
as efficient as possible when there are no writes. Generally though, it
should be some multiple of read_expire.
控制在一些等待的写程序被服务之前一批读程序会被给于多少时间。高数值是更加由效率的。
如果写操作相比于读操作被给于更高的优先级的话，这个值可能被设置的逼read_expire要低。
* write_expire, and
* write_batch_expire are equivalent to the above, for writes.
* write_expire, 和
* write_batch_expire是为写程序设置的，与上述相同。
* antic_expire
Controls the maximum amount of time we can anticipate a good read before
giving up. Many other factors may cause anticipation to be stopped early,
or some processes will not be "anticipated" at all. Should be a bit higher
for big seek time devices though not a linear correspondence - most
processes have only a few ms thinktime.
控制在放弃之前我们能够预期一个好的读程序做大时间。任何其他因素都会导致预期提前
终止，或者是一些进程根本不会被预期。即使不是一个线性对应的，对一个高寻找时间的
设备也应该被设定的稍高一些。大多数进行仅仅有几毫秒的思考时间。
预期IO调度程序
-------------------------
Nick Piggin <piggin@cyberone.com.au> 13 Sep 2003
Attention! Database servers, especially those using "TCQ" disks should
investigate performance with the 'deadline' IO scheduler. Any system with high
disk performance requirements should do so, in fact.
注意！数据库服务器，特别是那些使用“TCQ”磁盘应该研究一下使用'deadline'IO调度程序
的性能。事实上，任何使用高性能磁盘的系统都应该考虑到这些。
If you see unusual performance characteristics of your disk systems, or you
see big performance regressions versus the deadline scheduler, please email
me. Database users don't bother unless you're willing to test a lot of patches
from me ;) its a known issue.
如果你看到你的磁盘系统中有不寻常的性能特征或者是你看到一个高性能的回归分析和使用了
期限调度的话，请一定要给我发邮件。数据库使用者不必困扰，除非你想要在我这里测试大量
的补丁。
Selecting IO schedulers
选择IO调度程序
-----------------------
To choose IO schedulers at boot time, use the argument 'elevator=deadline'.
'noop' and 'as' (the default) are also available. IO schedulers are assigned
globally at boot time only presently.
为了能够在启动期间选择IO调度程序，请使用参数'elevator=deadline'.'noop'和'as'也是
可以的。目前，IO调度程序只能够在启动期间被全局分配。
Tuning the anticipatory IO scheduler
调谐预期调度
------------------------------------
When using 'as', the anticipatory IO scheduler there are 5 parameters under
/sys/block/*/iosched/. All are units of milliseconds.
当使用'as'的时候，预期调度程序在目录/sys/block/*/iosched下由5个参数，这5个参数都是以
毫秒为单位的。
The parameters are:
这五个参数分别是：
* read_expire
Controls how long until a request becomes "expired". It also controls the
interval between which expired requests are served, so set to 50, a request
might take anywhere < 100ms to be serviced _if_ it is the next on the
expired list. Obviously it won't make the disk go faster. The result
basically equates to the timeslice a single reader gets in the presence of
other IO. 100*((seek time / read_expire) + 1) is very roughly the %
streaming read efficiency your disk should get with multiple readers.
控制一个请求到什么时候是过期的。同时他也控制哪一个过期的请求能够被服务的时间间隔，
所以被设置乘50.在过期列表上的下一个请求可能被带到任何地方在小于100毫秒的时候被
服务。很明显，他不会使磁盘变得更快。这个结果基本上等同于在其他IO的中一个单独的
读程序获取的一个时间片。
* read_batch_expire
Controls how much time a batch of reads is given before pending writes are
served. Higher value is more efficient. This might be set below read_expire
if writes are to be given higher priority than reads, but reads are to be
as efficient as possible when there are no writes. Generally though, it
should be some multiple of read_expire.
控制在一些等待的写程序被服务之前一批读程序会被给于多少时间。高数值是更加由效率的。
如果写操作相比于读操作被给于更高的优先级的话，这个值可能被设置的逼read_expire要低。
* write_expire, and
* write_batch_expire are equivalent to the above, for writes.
* write_expire, 和
* write_batch_expire是为写程序设置的，与上述相同。
* antic_expire
Controls the maximum amount of time we can anticipate a good read before
giving up. Many other factors may cause anticipation to be stopped early,
or some processes will not be "anticipated" at all. Should be a bit higher
for big seek time devices though not a linear correspondence - most
processes have only a few ms thinktime.
控制在放弃之前我们能够预期一个好的读程序做大时间。任何其他因素都会导致预期提前
终止，或者是一些进程根本不会被预期。即使不是一个线性对应的，对一个高寻找时间的
设备也应该被设定的稍高一些。大多数进行仅仅有几毫秒的思考时间。
类似资料：