Lines Matching refs:IO
57 traces from the kernel for each IO processed by the block IO layer. The
58 traces provide a complete timeline for each IO processed, including
59 detailed information concerning when an IO was first received by the block
60 IO layer -- indicating the device, CPU number, time stamp, IO direction,
61 sector number and IO size (number of sectors). Using this information,
62 one is able to \emph{replay} the IO again on the same machine or another
81 \item You extract the pertinent IO information from the traces saved by
83 each trace file created by \texttt{blktrace}, and craft IO descriptions
91 \subsection{IO Stream Replay Characteristics}
92 The major characteristics of the IO stream that are kept intact include:
98 \item[IO direction] The same IO direction (read/write) is maintained.
100 \item[IO offset] The same device offset is maintained.
102 \item[IO size] The same number of sectors are transferred.
110 \item[Device IO Stream Ordering] All IOs on a device are submitted in
116 devices is not necessarily maintained. (Each device with an IO stream
124 much worse timing on a per IO basis.
131 entrance of IOs into the block IO layer. In order to replay these IOs with
134 IOs that will be processed as a single \emph{asynchronous IO} call to the
138 code, and thus are submitted to the block IO layer with \emph{very small}
187 \item Lack of IO ordering across devices.
191 and thus ensure IO ordering across devices, with some reduction in
195 \item Lack of IO timing accuracy -- additional time between IO bunches.
198 \emph{This is the primary problem with any IO replay mechanism -- how
199 to guarantee per-IO timing accuracy with respect to other replayed IOs?
200 One idea to reduce errors in this area would be to push the IO replay
209 \texttt{-max-pkts=1} and then each IO would be treated individually. Of
211 inter-IO times.}
372 \item[Field 4] The fourth field contains the total number of IO bunches.
514 to store information concerning each \emph{stall} and IO operation
