dcsimg

A Trip Down the Data Path: I/O and Performance Page 2

NewsletterIconSTORAGE DAILY

Want the latest storage insights?

Download the authoritative guide: Enterprise Data Storage 2018: Optimizing Your Storage Infrastructure

The I/O Path

Applications generally make requests to create files in one of at least two ways, both using POSIX standards calls.

 

  1. The file is created/opened with the open(2) system call, and I/O is made directly to the system via calls to the raw device, volume manager and/or file system using read(2), write(2), pread(2), pwrite(2) and/or the POSIX standard asynchronous I/O routines aio_read(3RT), aio_write(3RT), lio_listio(3RT).

  2. The file is created/opened with fopen(3) and I/O is done via the POSIX standard C library package (fread/fwrite/fprint). If a file is opened using fopen(3), the initial path through the system is different than when the file is opened using the open(2) system call. This method is typically used more often as it has fewer restrictions than using direct system calls.

Both of these methods work on UNIX, Windows, Linux and even mainframe systems as the POSIX standard is supported on all of them.

 

Using the C Library

With fopen(3), which uses the C library package (libc.a on UNIX and Linux systems), the data is moved from the user data space to a library buffer for each opened file. The C library is often called standard I/O. The size of this library buffer is by default:

 

OSSize in Bytes
Windows4096 (the range of values supported are from 2 to 32768 bytes)
Linux8192
Solaris8192
AIX4096
SGI4096

Table 1. Buffer Sizes for Standard I/O

It should be noted that the actual memory size of the library buffer is really 8 bytes greater than the actual buffer size. These 8 bytes are used for pointer and control information for the buffer.

Page 3: Using the C Library (Continued)

 

Submit a Comment

 

People are discussing this article with 0 comment(s)