Managing Systems and Workgroups: A Guide for HP-UX System Administrators

Planning a Workgroup
Planning to Manage File Systems
Chapter 2 91
complete) when the system call that initiated it returns to the
application; exceptions, however, are found in the JFS mount options
that delay transaction logging. However, even if transaction logging is
delayed, transactions remain atomic and the file system will still not be
left in an intermediate state.
Is user data part of a transaction?
User data is not usually treated as part of a transaction. Instead, it is put
in the buffer cache without guarantees that it is written to disk unless
sync (1M) is explicitly run. However, if an application uses a synchronous
write (for example, by opening a file with the O_SYNC flag), the user data
is treated as part of the transaction, with the same atomicity applicable
to the file system metadata (inodes, extent maps, etc.).
What are JFS extents and how are they used by the operating system?
JFS allocates space to files in the form of extents, adjacent (contiguous)
disk blocks treated as a unit. Extents may vary in size from a single
block to many megabytes. Organizing file data this way allows JFS to
issue large I/O requests (that is, handle I/O in multiple blocks), which is
more efficient than reading or writing a single block at a time.
If a file is read sequentially, JFS may fetch more of the current extent
than necessary to satisfy a single read system call, thus making the data
available in the buffer cache for future reads. This form of read-ahead
does not involve an extra I/O operation, since the data is contiguous on
the disk. Instead, more data is brought into the buffer cache with a
single I/O request than is immediately needed.
Data for a write system call is placed in the buffer cache and flushed to
disk at some later time. This is called a delayed write. Eventually, when
the data is flushed, JFS looks for other data waiting to be flushed to
adjacent blocks and attempts to cluster all data into a single, large I/O
request.
JFS extents are represented by a starting block number and a block
count. When a file grows, JFS first attempts to increase the size of the
last extent in the file.
• If this succeeds, its starting block number remains the same, but its
block count is increased.
• If this fails, a new extent is allocated with a different starting block
number and added to the file.