Documentation_block_deadline-iosched.txt

Chinese translated version of Documentation_block_deadline-iosched.txt

If you have any comment or update to the content, please contact the
original document maintainer directly.  However, if you have a problem
communicating in English you can also ask the Chinese maintainer for
help.  Contact the Chinese maintainer if this translation is outdated
or if there is a problem with the translation.

Chinese maintainer:Luo Yangyang <[e-mail]>
---------------------------------------------------------------------
Documentation_block_deadline-iosched.txt 的中文翻译

如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
译存在问题，请联系中文版维护者。

中文版维护者： 罗秧秧  <[e-mail]>
中文版翻译者： 罗秧秧  <[e-mail]>
中文版校译者： 罗秧秧  <[e-mail]>

以下为正文
---------------------------------------------------------------------

Deadline IO scheduler tunables
==============================
This little file attempts to document how the deadline io scheduler works.
In particular, it will clarify the meaning of the exposed tunables that may be
of interest to power users.

Selecting IO schedulers
-----------------------
Refer to Documentation/block/switching-sched.txt for information on
selecting an io scheduler on a per-device basis.

截止时间IO调度程序可调参数
==============================
这个小文件试图记录说明截止时间IO调度程序（电梯算法）是怎么工作的。
特别是，它将阐明暴露可调参数的含义，这可能是
高权限用户的兴趣。

选择IO调度程序
-----------------------
参考文档Documentation/block/switching-sched.txt的信息，
在每个设备的基础上选择一个IO调度。
********************************************************************************

read_expire (in ms)
-----------
The goal of the deadline io scheduler is to attempt to guarantee a start
service time for a request. As we focus mainly on read latencies, this is
tunable. When a read request first enters the io scheduler, it is assigned
a deadline that is the current time + the read_expire value in units of
milliseconds.

read_expire（毫秒）
-----------
截止IO调度程序的目标是试图保证为一个请求启动
服务时间。在我们主要集中在读取延迟时，这是
可调的。当一个读请求首先进入io调度时，它被分配
到一个截止时间，这个时间是当前时间+以毫秒为单位的读请求超时时间（read_expire）值。


write_expire (in ms)
-----------
Similar to read_expire mentioned above, but for writes.

写请求超时时间(write_expire)（毫秒）
-----------
类似read_expire上面提到的，但是是针对写请求的。

fifo_batch(number of requests)
----------
Requests are grouped into ``batches'' of a particular data direction (read or
write) which are serviced in increasing sector order.  To limit extra seeking,
deadline expiries are only checked between batches.  fifo_batch controls the
maximum number of requests per batch.

This parameter tunes the balance between per-request latency and aggregate
throughput.  When low latency is the primary concern, smaller is better (where
a value of 1 yields first-come first-served behaviour).  Increasing fifo_batch
generally improves throughput, at the cost of latency variation.

fifo_batch（请求数）
----------
请求被分组为有一个特定的数据方向（读或
写）的“批操作”，这是为增强扇区次序提供服务的。为了限制额外的查找，
只在批次之间检查限期期满。 fifo_batch控制
每批次的请求的最大数量。

此参数调整每个请求的延迟和总吞吐量之间的平衡。低延时是首要关注的，越小越好（如果
值为1，就产生先到先得的行为）。增加fifo_batch
通常可以在一定的延迟变化的成本上提高吞吐量。
writes_starved (number of dispatches)
--------------
When we have to move requests from the io scheduler queue to the block
device dispatch queue, we always give a preference to reads. However, we
don't want to starve writes indefinitely either. So writes_starved controls
how many times we give preference to reads over writes. When that has been
done writes_starved number of times, we dispatch some writes based on the
same criteria as reads.

writes_starved（调度数）
--------------
当我们不得不将请求从IO调度队列移到块
设备调度队列中时，我们始终给予优先读取。然而，我们
不想无限期地饿死写请求。所以writes_starved控制
我们会优先考虑读请求而不是写请求的次数。当写请求可以被“饿死”的次数已经
到了的时候，我们会派遣一些与读操作相同准则的基础上的写操作。

front_merges (bool)
------------
Sometimes it happens that a request enters the io scheduler that is contiguous
with a request that is already on the queue. Either it fits in the back of that
request, or it fits at the front. That is called either a back merge candidate
or a front merge candidate. Due to the way files are typically laid out,
back merges are much more common than front merges. For some work loads, you
may even know that it is a waste of time to spend any time attempting to
front merge requests. Setting front_merges to 0 disables this functionality.
Front merges may still occur due to the cached last_merge hint, but since
that comes at basically 0 cost we leave that on. We simply disable the
rbtree front sector lookup when the io scheduler merge function is called.

Nov 11 2002, Jens Axboe <[e-mail]>

front_merges（布尔）
------------
有时候会发生：一个请求紧接着一个已经在队列中的请求进入IO调度。
无论是它适合于后面的那个请求，或者是前面的。这就是所谓的后合并候选
或前合并候选。根据文件通常是编排出来的方式，
后合并比前合并更为普遍。对于某些工作负载，你
甚至可以知道，试图进行前合并请求是在浪费时间。设置参数front_merges为0禁用这个功能。
由于缓存last_merge提示，前合并仍可能会出现。但既然
基本上是0成本出现的，我们就把它放在那，让它发生。我们只需简单地在IO调度合并函数被调用时禁用
红黑树扇区查找。

2002年11月11日，Jens Axboe<[e-mail]>