85 lines
5.3 KiB
HTML
85 lines
5.3 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
<!DOCTYPE html
|
||
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
<html lang="en-us" xml:lang="en-us">
|
||
|
<head>
|
||
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
<meta name="security" content="public" />
|
||
|
<meta name="Robots" content="index,follow" />
|
||
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
<meta name="DC.Type" content="task" />
|
||
|
<meta name="DC.Title" content="Expanding buffer I/O through HFS" />
|
||
|
<meta name="abstract" content="Read about tailoring read requests for performance and to expand buffer I/O in HFS." />
|
||
|
<meta name="description" content="Read about tailoring read requests for performance and to expand buffer I/O in HFS." />
|
||
|
<meta name="DC.Relation" scheme="URI" content="tipsandtechniques.htm" />
|
||
|
<meta name="copyright" content="(C) Copyright IBM Corporation 2000, 2006" />
|
||
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2000, 2006" />
|
||
|
<meta name="DC.Format" content="XHTML" />
|
||
|
<meta name="DC.Identifier" content="bufferio" />
|
||
|
<meta name="DC.Language" content="en-us" />
|
||
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
<!-- US Government Users Restricted Rights -->
|
||
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
||
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
||
|
<title>Expanding buffer I/O through HFS</title>
|
||
|
</head>
|
||
|
<body id="bufferio"><a name="bufferio"><!-- --></a>
|
||
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
<h1 class="topictitle1">Expanding buffer I/O through HFS</h1>
|
||
|
<div><p>Read about tailoring read requests for performance and to expand
|
||
|
buffer I/O in HFS.</p>
|
||
|
<div class="p"><div class="p">An alternative method of opening a stream file through HFS can
|
||
|
improve performance for applications that typically read portions, but not
|
||
|
all, of the data in large optical files. This alternate method of input/output
|
||
|
is referred to as <dfn class="term">expanding buffer I/O</dfn>. Expanding buffer I/O
|
||
|
is available only to HFS API applications when accessing High Performance
|
||
|
Optical File System (HPOFS) or ISO 9660 formatted media. This attribute is
|
||
|
ignored when the media format is UDF.<div class="note"><span class="notetitle">Note:</span> Using the HFS APIs, optical file
|
||
|
data is buffered into a virtual optical file in i5/OS™ main storage. If expanding buffer
|
||
|
I/O is not selected as an option, the size of this buffer is equal to the
|
||
|
size of the actual optical file. For example, a 100 MB file on optical media
|
||
|
has a 100 MB buffer when the file is opened through the HFS API Open Stream
|
||
|
File. The performance cost for overhead operations involving the optical buffer
|
||
|
is proportional to the buffer size. The time it would take to read one byte
|
||
|
of a 100 MB file is substantially greater than reading one byte of a 50 KB
|
||
|
file.</div>
|
||
|
</div>
|
||
|
<p>When an optical file is opened for expanding buffer I/O,
|
||
|
the size of the buffer begins at zero and expands as data is read into the
|
||
|
buffer as requested by the application. The minimum amount of the size expansion
|
||
|
is 256 KB. The buffer expands only if the requested data is contained within
|
||
|
a logical 256 KB page that is not yet contained in the buffer. For these reasons,
|
||
|
the amount of time it would take to read one byte of a 100 MB file opened
|
||
|
for expanding buffer I/O should be roughly identical to the time to read one
|
||
|
byte of a 50 KB file opened in the same manner.</p>
|
||
|
</div>
|
||
|
<div class="section"><strong>Situations in which expanding buffer I/O is useful</strong><div class="p">Expanding
|
||
|
buffer I/O should be considered as an option for improving the performance
|
||
|
of reads if any of the following conditions are met:<ul><li>The typical size of an optical file to be read is greater than 256 KB.</li>
|
||
|
<li>The amount of data read from the optical file between the open and close
|
||
|
stream file is a fraction of the total file data. The exact fraction would
|
||
|
be impossible to specify, but the performance improvements that are achieved
|
||
|
will be greater the smaller the fraction. For example, an application that
|
||
|
used expanding buffer I/O to read 25 KB of a 50 MB file would experience much
|
||
|
greater performance improvements than an application that read 45 MB of the
|
||
|
same file. An application that reads the entire 50 MB example file 40 KB at
|
||
|
a time through multiple reads probably would not experience any performance
|
||
|
improvement using expanding buffer I/O.</li>
|
||
|
<li>The application will not issue the Set Stream File Size, Lock-Unlock Byte
|
||
|
Range, or Write Stream file APIs while the file is open for expanding buffer
|
||
|
I/O. </li>
|
||
|
</ul>
|
||
|
</div>
|
||
|
<p>For specific details on how to implement expanding buffer I/O,
|
||
|
see <a href="specialattributes.htm">Using special attributes</a>.</p>
|
||
|
</div>
|
||
|
</div>
|
||
|
<div>
|
||
|
<div class="familylinks">
|
||
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="tipsandtechniques.htm" title="The following techniques are often helpful in designing custom optical programs for your business.">Tips: Optical programming</a></div>
|
||
|
</div>
|
||
|
</div>
|
||
|
</body>
|
||
|
</html>
|