Expanding buffer I/O through HFS

Read about tailoring read requests for performance and to expand buffer I/O in HFS.

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 expanding buffer I/O. 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.

Note: 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.

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.

Situations in which expanding buffer I/O is useful

Expanding buffer I/O should be considered as an option for improving the performance of reads if any of the following conditions are met:

The typical size of an optical file to be read is greater than 256 KB.
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.
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.

For specific details on how to implement expanding buffer I/O, see Using special attributes.