Managing Systems and Workgroups: A Guide for HP-UX System Administrators
Planning a Workgroup
Planning to Manage File Systems
Chapter 292
NOTE JFS extents are unrelated to LVM physical or logical extents. LVM
physical extents are also contiguous blocks of the physical volume (disk),
4MB in size by default, but whose size is fixed. For information about
LVM extents, see “How LVM Works” on page 559.
How does JFS allocate extents to deal with file growth?
When a file grows, a new extent can be added, or the last extent can be
increased in size (assuming there is enough free space immediately
following it). If there is insufficient free space immediately following the
last extent, JFS allocates a separate non-contiguous extent.
The optional HP OnLineJFS product enables you to defragment
noncontiguous extents. This reorganization involves shuffling the data
blocks in a file system to merge extents and make files more contiguous.
Refer to SAM’s online help or fsadm_vxfs (1M) for details.
What is the JFS intent log and how is it used?
JFS groups structural changes into transactions, and records these in an
intent log on the disk before initiating them. For example, writing to a
file might cause it to grow, which would involve allocating additional
space to it, updating its extent map, increasing its size and updating its
last modification time. These changes would be treated as a single
transaction that would be logged before any changes are actually made.
When all the changes are made, this fact would also be recorded in the
intent log.
If the system crashes, fsck need only scan the intent log and complete
transactions that were in progress. This is called log replay. It provides
for greater file system integrity and greatly reduces recovery time,
compared to a traditional file system that must be scanned from
beginning to end for inconsistencies. Because the intent log is available
to fsck, the size of the file system is not an important factor, only the
number of incomplete transactions at the time of the crash. Even for a
file system that was very active, log replay will generally take under ten
seconds.
For further information, see “Dealing with File System Corruption” on
page 613