Lines Matching refs:IOs
66 The basic operating work-flow to replay IOs would be something like:
70 device or devices that you wish to trace and later replay IOs upon. Note:
88 attempts to generate the same IOs seen during the sample workload phase.
95 \item[Device] The IOs are replayed on the same device as was seen
106 IOs during the sample workload. \texttt{btreplay} \emph{attempts} to
107 maintain the same time differential between IOs, but no guarantees as
110 \item[Device IO Stream Ordering] All IOs on a device are submitted in
114 As noted above, the time between IOs may not be accurately maintained
115 during replays. In addition the actual ordering of IOs \emph{between}
122 thread handles all IOs across all devices. This approach, while
123 guaranteeing correct ordering of IOs across all devices, resulted in
131 entrance of IOs into the block IO layer. In order to replay these IOs with
133 multiple sequential (in time) IOs and put them in a single \emph{bunch} of
134 IOs that will be processed as a single \emph{asynchronous IO} call to the
137 number of workloads, the IOs are coming in from the page cache handling
144 in one bunch -- only IOs within the time specified are eligible
151 more than 8 individual IOs. With this option, one can increase or
158 about \emph{bunches} of IOs to be replayed. \texttt{btreplay} operates on
167 ordering and timing of IOs seen during the sample workload. The reclaiming
199 to guarantee per-IO timing accuracy with respect to other replayed IOs?
204 \item Bunching of IOs results in reduced time amongst IOs within a bunch.
305 amount of time (in nanoseconds) to include in any one bunch of IOs that
307 IOs processed at one time -- perhaps yielding in more realistic replay.
317 maximum number of IOs to store in a single bunch. As with the \texttt{-m}
374 \item[Field 5] The last field shows the average number of IOs per bunch
498 ignored. IOs will be replayed without inter-bunch delays.
