|
|
United States-English | |
|
|
 |
|
HP Servers and Workstations: Managing Systems and Workgroups > Chapter 2 Planning a Workgroup
Planning to Manage File Systems |
|
|
This section addresses questions you might have when planning to administer file systems. The following topics are discussed: For procedures used to administer file systems, go to “Managing File Systems”. System files, application files, and user files all must reside in a file system to be available to the operating system and applications. The overall HP-UX file system consists of a directory tree or hierarchy, starting from the root. Although the file system may appear as one unitary system, it may actually consist of several different “pieces”, each stored on different devices or on different logical volumes. To enable users to access the files in a file system, except for the root file system, you must “mount” the file system. This can be done either manually or automatically at boot-up, by attaching it to a directory in the existing directory tree. The directory where you attach the added file system is called the mount point.
You can also unmount a file system, and if you choose, re-attach it at a different mount point. For procedural information, go to “Unmounting File Systems ”. There are a variety of reasons why you might create a new piece of the overall file system, including:
Table 2-3 File System Limits of HP-UX Releases
As of HP-UX 11.0, the Journaled File System (JFS) is installed as the default for root and other HP-UX file systems. However, four other file-system types are available for use on HP-UX. Information on each is presented in the following table: Table 2-4 HP-UX File System Types
It is permissible to have a mixture of JFS and other file systems on a single computer system.
Many file system administration commands now provide a -F FStype option that allows you to specify the file system type. Use the following keywords to indicate the appropriate file system type:
HP-UX can determine the file system type for commands that operate on a pre-existing file system, even if -F FStype is not specified on the command line. For further information on file system wrappers, see fs_wrapper(5). For procedural information on file system conversion, see “Converting Existing File Systems to JFS”. JFS is the HP-UX implementation of the VERITAS journaled file system (VxFS), which features superb reliability and fast recovery. As of release 10.30, JFS is the default HP-UX file system. The HP-UX 11i operating environments include VxFS. Basic JFS functionality is included with the HP-UX operating system software. With the installation of a separately orderable product called HP OnLineJFS, JFS also provides online administrative operations, including backup, resizing, and defragmentation. The advantages of JFS are well worth the small amount of learning required to use it. For procedural information pertinent to JFS file systems, go to:
What is JFS? JFS is the HP-UX implementation of the VERITAS journaled file system (VxFS) introduced in HP-UX 10.01. It features high reliability, fast recovery, and online administrative operations, including backup, resizing and defragmentation. For how long has JFS been available in HP-UX? HP phased in the implementation of JFS over several releases:
How does the journaled file system (JFS) compare to HFS? JFS improves upon the High-Performance file system (HFS) in the following ways:
As compared to HFS, JFS recovers much faster from system failure, due to its mechanism for logging changes to the file-system structure. When the system boots after a crash, the file system synchronizes using its log to speed recovery, in an operation similar to, but much faster than, that performed by fsck. Fast recovery time is particularly useful in environments that require high performance or that deal with large volumes of data. JFS allows for higher data throughput (faster I/O) than HFS. This is due to the JFS organization of file storage into extents, which can consist of multiple data blocks. The optional HP OnLineJFS product eases system maintenance by allowing you to perform tasks such as file-system backup and enlarging or reducing a file system without unmounting it. These capabilities are not available on HFS. What are the disadvantages of configuring a file system using JFS? You might not want to configure JFS on a system with limited memory because its memory requirements exceed those of HFS. Is JFS use restricted in any way by LVM (see “The Logical Volume Manager (LVM)”)? You can use JFS on any file system, whether or not it is being managed by LVM. How is JFS administered? JFS can be administered using SAM or HP-UX commands. SAM has utilities to create (add), backup, and resize JFS file systems. If you have the optional HP OnLineJFS package (referred to in some manpages as Advanced VxFS), you can use the VxFS Maintenance menu choice of SAM to view extent and directory fragmentation, reorganize extents and directories, resize JFS file systems while online, and perform an online backup using a snapshot of a JFS file system. From the command line you can use:
How does JFS work? JFS allocates space to files in the form of extents, adjacent disk blocks that are treated as a unit. Extents can vary in size from a single block to many megabytes. Organizing file data this way allows JFS to issue large I/O requests, which is more efficient than reading or writing a single block at a time. JFS groups structural changes into transactions, and records these in an intent log on the disk before any changes are actually made. If the system crashes, fsck need only scan the intent log and complete transactions that were in progress. This 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. JFS offers mount options to delay or disable transaction logging. This allows the system administrator to make trade-offs between file system integrity and performance, guaranteeing the integrity of critical file systems, while optimizing the performance of non-critical or temporary file systems. When you have the optional HP OnLineJFS product, many administrative operations can be performed on an active JFS file system, including resizing it, reorganizing its files to make them contiguous and reorganizing directories to reclaim unused space. In addition, a snapshot of a mounted file system can be taken for backup. The snapshot provides a consistent, read-only view of the file system at a certain moment in time, even as the file system it is a snapshot of continues to change. Online administration, along with fast recovery made possible by the intent log, significantly increase file system availability. What are the contents of a JFS transaction? A transaction consists of all individual system operations related to a change. For example, writing to a file might cause it to grow, which would involve allocating additional space, updating its extent map, increasing its size, and updating its last modification time. These changes are treated as a single transaction, which is logged before any of the changes are actually made. When all the changes are made, this fact is also recorded in the intent log. JFS transactions are guaranteed to be atomic; that is, either all of the individual operations that comprise a transaction complete successfully or none of them do. The file system is not left in an intermediate state, with some operations completed and others not, even after a system crash. Generally, a transaction is committed (that is, guaranteed to 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.
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” Each JFS file system has its own intent log. Space is reserved for the intent log when the file system is created; its size cannot be changed later. The intent log is not a user-visible file, although you can use the fsdb tool to dump it. Normally, user data is not treated as part of a transaction. Instead, it is put in the buffer cache with the usual UNIX delayed write semantics (that is, without guarantees of having been written to disk, unless sync is explicitly run). However, if the application indicates 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 all-or-nothing guarantee that applies to file system metadata (such as directories, inodes, free extent maps). Under what circumstances does the intent log contain file data? Typically, the intent log contains only information on file-system metadata, such as superblock, inodes, and directories. However, file data written synchronously (that is, the file is opened with the O_SYNC or O_DSYNC option) is logged in the intent log, if the write block size is 8KB or less. This behavior is true both for Basic JFS and HP OnLineJFS (also known as Advanced VxFS package), but can be changed using the nodatainlog option of the mount command (see mount_vxfs(1M)).
What is the recommended size of the intent log? The intent log size is set by default, based on the file-system size. Typically, the intent log size is 1 MB. If the file system is:
Might there be a reason to increase the size of the intent log? What happens if it fills up? Will errors occur or performance be affected? No. If the intent log fills up, there is no perceivable impact on users. Blocking on I/O might occur, but this occurs in many situations unrelated to the intent log, and will have no perceivable impact. No errors occur if the intent log fills up. How can I know the size of the intent log? You can use fsdb to view the size of the intent log. This file system debugger should be used by advanced users only, however, as it can destroy the file system if not used properly. Refer to fsdb_vxfs(1M) for relevant information, and for information about the JFS superblock format. How do I modify the intent log size? Use the mkfs -F vxfs command with the following -o option: -o logsize=n, where n is the number of blocks to allocate for the intent log. n must be in the range 32 to 2048. For syntax, see mkfs_vxfs(1M). What are the JFS mount options and when are they advantageous to use? JFS offers mount options to delay or disable transaction logging, and to control whether user data is written synchronously or delayed. These settings allow the system administrator to make trade-offs between file system integrity and performance, guaranteeing the integrity of critical file systems, while optimizing the performance of non-critical or temporary file systems. For syntax, see mount_vxfs(1M). What logging options are available using JFS? JFS provides a variety of options to control how transactions are logged to disk, as listed below. The default, log, provides maximum system integrity in the event of a system failure. Under most other circumstances, including mounting a JFS file system with SAM and doing a cold install, the recommended logging mode is delaylog.
What write options are available using JFS? JFS provides several options to control how user data is written to disk:
Additionally, the system administrator can control the way writes are handled, with and without O_SYNC.
Given all the many JFS options, what are some useful combinations of logging and caching? mount -o log,mincache=dsync
mount -o log
mount -o delaylog
mount -o nolog,convosync=delay
What online operations can be performed with OnLineJFS? Administrative operations that can be performed on an active JFS file system when you have the optional HP OnLineJFS product include:
What is a JFS snapshot and why is it useful? A snapshot (available with HP OnLineJFS) is a consistent, stable view of an active file system, used to perform a backup of an active file system. It allows the system administrator to capture the file-system state at a moment in time (without taking it off-line and copying it), mount that file-system image elsewhere, and back it up. For example, a snapshot of /home can be mounted at /tmp/home. Initially, identical directories and files would appear under /home and under /tmp/home, but users would still be able to access and modify the primary file system (/home). These changes would not appear in the snapshot. Instead, /tmp/home would continue to reflect the state of /home at the moment the snapshot was taken. To the user, the snapshot looks like an ordinary file system, which has been mounted read-only. Snapshots are always mounted read-only; that is, none of its directories or files may be modified. Internally, however, something very different is going on.
All this is done transparently within the kernel. How does one work with snapshots? A JFS snapshot can be used to perform an online backup of a file-system. For procedure, go to “How to Create and Back Up a JFS Snapshot File System ”. The snapshot file system must reside either on a separate disk or separate logical volume from the original file system. Any data on the device prior to taking the snapshot will be overwritten when the snapshot is taken. Commands and applications need not be changed to work with snapshots, since the kernel is responsible for locating snapshot data (either on the snapshot device or the primary device), and for copying individual blocks from the primary file system to the snapshot device immediately before they are updated. Because of this copy-on-write scheme, a snapshot can be created instantaneously and requires only enough space to hold the blocks that might change while the snapshot is mounted. The snapshot volume should be about 10-20% the size of the original file system. The snapshot volume need not be structured in any way; it is not necessary to execute newfs for a snapshot file system prior to mounting it. While a snapshot is mounted, changes to the original file system will not be reflected in the snapshot. The snapshot is a “frozen” image of the original file system. Once a snapshot is unmounted, its contents are lost. What limitations do snapshots pose? It is possible to run out of space on a snapshot device. This might happen because the device is too small, because the primary file system is too volatile, or because the snapshot remains mounted for too long. When a snapshot device becomes full, the kernel has nowhere to copy blocks from the primary file system. In this situation, the kernel cannot maintain a stable view of the file system, so it makes the snapshot inaccessible. Typically, the system administrator will create a new snapshot after correcting the problem (for example, by using a larger snapshot device, or by choosing a time when the primary file system is less volatile). How does an OnLineJFS backup differ from a standard backup? An OnLineJFS backup involves using a snapshot of the file system, rather than the file system itself. Explicit information on how to perform an online backup can be found at “Backing Up a JFS Snapshot File System”. For purposes of online backups, what are the advantages and disadvantages of snapshots compared to using the LVM lvsplit utility? This question assumes you have installed both HP MirrorDisk/UX and HP OnLineJFS.
Advantages of JFS snapshot:
Does JFS have an interface to a snapshot file system? The fscat utility provides an interface to a JFS snapshot file system, similar to that provided by the dd utility invoked on the special file of other JFS file systems. On most JFS file systems, the block or character special file for the file system provides access to a raw image of the file system for such purposes as backing up the file system to tape. The fscat utility shows the snapshot as a stream of bytes that can be processed in a pipeline or written to tape. For more information, refer to fscat_vxfs(1M). What size considerations does an administrator need to be aware of when configuring a JFS file system?
In addition, JFS and HFS have the same limits for file and file-system size:
What does JFS provide to ensure good performance? In general, a JFS file system has better performance than an HFS file system, due to its use of big extents, optimized file-system space usage, large read-ahead, and contiguous files. However, the natural result of file-system is the fragmentation of its blocks. HP OnLineJFS has an efficient means of defragmenting file system space, to restore file-system performance. You can defragment a JFS file system using SAM or directly from the command line using the fsadm command. You can perform two kinds of defragmentation directory and extent defragmentation. How often should you defragment (reorganize) a JFS file system? For optimal performance, the kernel extent allocator must be able to find large extents whenever necessary. To maintain file-system performance levels, the fsadm utility should be run periodically against all JFS file systems, to reduce fragmentation. Frequency depends on file-system usage, activity patterns, and importance of performance, and might mean daily or monthly. However, to maintain optimal performance on busy file systems, you should defragment them nightly. How do you defragment a JFS file system?
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Printable version |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
