System Calls and the I/O Path

Henry Newman

If you read my last column, you might ask why would a systems administrator need to know about the I/O path for the C library, much less the path for UNIX system calls? During my two+ decades in the business, some of the biggest mistakes I’ve seen sys admins and vendors make is to optimize I/O without fully understanding how it all works together. You cannot configure and optimize storage systems (hardware and software) without fully understanding the file sizes, number of files, and most importantly, the I/O sizes that the file system will see from the applications. This month, I will be looking at system calls and how they send data to the file system. Future columns will cover:

• File system structure and the history
• File system performance and configuration
• RAID systems configuration and performance
• Secondary storage and library performance
• Backup and HSM performance issues
• Development of a storage benchmark based on your system

Each of these areas might take a few months to cover, so this outline will last for a while. I am interested in your feedback, so please let me know if you have any suggestions.

I/O Path (Using UNIX System Calls)

My last column covered the I/O path using the C library package. I’ll now discuss the details of using direct UNIX system calls for doing I/O, and I’ll also discuss the path the data follows if requests do not begin and end on 512-byte boundaries. The system path for both system call and C library I/O is the same in this case.

When a program uses system calls for I/O, a large number of variables affect both the path and the performance. I will begin with a description of some important system calls and how they are used. There are two types of I/O supported on most UNIX systems:

• Synchronous I/O — Each I/O request waits for the completion of the last request to that file descriptor.