Return to mount_kio.html CVS log

Up to [Development] / xfs-website.orig

Modified Files:
	beta.html
Added Files:
	mount_kio.html

<& xfsTemplate,top=>1,side=>1 &>

<!-- Start Project Content -->
<h2>
<b><font face="ARIAL NARROW,HELVETICA">Mount Options: kio and kiocluster</font></b></h2>


<p>
In Linux, I/O is internally abstracted as a list of buffers; these buffers
are of the size chosen at the time at which the file system was
created (mkfs).
In this traditional approach, pages of a single I/O operation
which are contiguous
on disk still need to be specified using multiple buffers. This
requirement can be an unnecessary overhead in XFS which normally employs
large extents (contiguous disk blocks) to represent files. The <tt>kio</tt>
option internally abstracts contiguous I/O as a single entity using a
relatively new feature in Linux, called kiobufs. With this approach the
overhead of allocating and maintaining multiple buffers is minimized. The
<tt>kio</tt> option can improve both read and write performance.
</p>

<p>
As a further optimization, XFS uses delayed allocation, whereby multiple
writes are "clustered" before actual space is allocated on disk. With
locality of writes (that is, writes to contiguous logical blocks of a
file as, for example, in a <tt>cp</tt> operation),
disk blocks can be allocated in fewer
and larger-sized extents. This approach not only allows the writes to
be performed with fewer seeks to different locations on disk, but also
allows a subsequent sequential read (as in the <tt>cat</tt> operation)
to be processed with
fewer seeks.  The <tt>kiocluster</tt> option uses kiobufs
instead of simple Linux buffers to internally represent the
I/O belonging to a cluster. Since
clustering only applies to writes, the <tt>kiocluster</tt> option only affects
write performance.
</p>

<p>
Specifying <tt>kio</tt> or <tt>kiocluster</tt>
is optional.  If neither is specified all
I/O is internally performed using buffers.  Also, the same file system
can be mounted using different options at different times; this can be
useful to study the performance of the system using a particular workload
under the different options.
</p>

<p>
Finally, we have observed that <tt>kio</tt> option can improve performance
in general, and the performance of large and sequential I/O
(e.g., streaming). Specifying the <tt>kiocluster</tt> option
improves streaming write performance. However,
we have observed performance problems with non-sequential localized
writes.
</p>

<p>
To specify that <tt>kiobufs</tt> be used for I/O
instead of <tt>buffer_heads</tt>,
use the <tt>kio</tt> option of the mount command:
</p>
<p>
<ul>
<tt>
mount -o kio <i>device</i> <i>dir</i>
</tt>
</ul>
</p>
<p>
Alternately, you can specify the <tt>kio</tt>
option in the <tt>fstab</tt> file, as follows:
</p>
<ul>
<tt>
<i>device</i> <i>dir</i> xfs defaults,...,kio 0 0
</tt>
</ul>
</p>

To specify that <tt>kiobufs</tt> be used for both I/O
and write clustering,
use the <tt>kiocluster</tt> option of the mount command:
</p>
<p>
<ul>
<tt>
mount -o kiocluster <i>device</i> <i>dir</i>
</tt>
</ul>
</p>
<p>
Alternately, you can specify the <tt>kiocluster</tt>
option in the <tt>fstab</tt> file, as follows:
</p>
<ul>
<tt>
<i>device</i> <i>dir</i> xfs defaults,...,kiocluster 0 0
</tt>
</p>


<br>


<& xfsTemplate,bottom=>1 &>