JFS File System Layout

A file system is a set of files, directories, and other structures. File systems maintain information and identify where a file or directory's data is located on the disk. In addition to files and directories, JFS file systems contain a boot block, a superblock, bitmaps, and one or more allocation groups. Each file system occupies one logical volume.

JFS Boot Block

The boot block occupies the first 4096 bytes of the file system, starting at byte offset 0 on the disk. The boot block is available to start the operating system.

JFS Superblock
The superblock is 4096 bytes in size and starts at byte offset 4096 on the disk. The superblock maintains information about the entire file system and includes the following fields: Size of the file system Number of data blocks in the file system A flag indicating the state of the file system Allocation group sizes

JFS Allocation Bitmaps

The file system contains the following allocation bitmaps: The fragment allocation map records the allocation state of each fragment. The disk i-node allocation map records the status of each i-node.

JFS Fragments
Many file systems have disk blocks or data blocks. These blocks divide the disk into units of equal size to store the data in a file or directory's logical blocks. The disk block may be further divided into fixed-size allocation units called fragments. Some systems do not allow fragment allocations to span the boundaries of the disk block. In other words, a logical block cannot be allocated fragments from different disk blocks. The journaled file system (JFS), however, provides a view of the file system as a contiguous series of fragments. JFS fragments are the basic allocation unit and the disk is addressed at the fragment level. Thus, fragment allocations can span the boundaries of what might otherwise be a disk block. The default JFS fragment size is 4096 bytes, although you can specify smaller sizes. In addition to containing data for files and directories, fragments also contain disk addresses and data for indirect blocks. Allocating JFS File Space explains how the operating system allocates fragments.

JFS Allocation Groups

The set of fragments making up the file system are divided into one or more fixed-sized units of contiguous fragments. Each unit is an allocation group. The first of these groups begins the file system and contains a reserved area occupying the first 32 x 4096 bytes of the group. The first 4096 bytes of this area hold the boot block, and the second 4096 bytes hold the file system superblock. Each allocation group contains a static number of contiguous disk i-nodes that occupy some of the group's fragments. These fragments are reserved for the i-nodes at file-system creation and extension time. For the first allocation group, the disk i-nodes occupy the fragments immediately following the reserved block area. For subsequent groups, the disk i-nodes are found at the start of each group. Disk i-nodes are 128 bytes in size and are identified by a unique disk i-node number or i-number. The i-number maps a disk i-node to its location on the disk or to an i-node within its allocation group. A file system's fragment allocation group size and the disk i-node allocation group size are specified as the number of fragments and disk i-nodes that exist in each allocation group. The default allocation group size is 8 MB, but can be as large as 64 MB. These values are stored in the file system superblock, and they are set at file system creation. Allocation groups allow the JFS resource allocation policies to use effective methods for to achieve optimum file system I/O performance. These allocation policies try to cluster disk blocks and disk inodes for related data to achieve good locality for the disk. Files are often read and written sequentially, and files within a directory are often accessed together. Also, these allocation policies try to distribute unrelated data throughout the file system in an attempt to minimize free-space fragmentation.

JFS Disk i-Nodes

A logical block contains a file or directory's data in units of 4096 bytes. Each logical block is allocated fragments for the storage of its data. Each file and directory has an i-node that contains access information such as file type, access permissions, owner's ID, and number of links to that file. These i-nodes also contain "addresses" for finding the location on the disk where the data for a logical block is stored. Each i-node has an array of numbered sections. Each section contains an address for one of the file or directory's logical blocks. These addresses indicate the starting fragment and the total number of fragments included in a single allocation. For example, a file with a size of 4096 bytes has a single address on the i-node's array. Its 4096 bytes of data are contained in a single logical block. A larger file with a size of 6144 bytes has two addresses. One address contains the first 4096 bytes and a second address contains the remaining 2048 bytes (a partial logical block). If a file has a large number of logical blocks, the i-node does not contain the disk addresses. Instead, the i-node points to an indirect block that contains the additional addresses.

JFS2 File System Layout

A file system is a set of files, directories and other structures. The file systems maintain information and identify where the data is located on the disk for a file or directory. In addition to files and

directories a JFS2 file system contains a superblock, allocation maps and one or more allocation groups. Each file system occupies one logical volume.

JFS2 Superblock
The superblock is 4096 bytes in size and starts at byte offset 32768 on the disk. The superblock maintains information about the entire file system and includes the following fields: Size of the file system Number of data blocks in the file system A flag indicating the state of the file system Allocation group sizes File system block size

JFS2 Allocation Maps

The file system contains the following allocation maps: The i-node allocation map records the location and allocation of all i-nodes in the file system. The block allocation map records the allocation state of each file system block.

JFS2 Disk i-Nodes

A logical block contains a file or directory's data in units of file system blocks. Each logical block is allocated file system blocks for the storage of its data. Each file and directory has an i-node that contains access information such as file type, access permissions, owner's ID, and number of links to that file. These i-nodes also contain a B+ tree for finding the location on the disk where the data for a logical block is stored.

JFS2 Allocation Groups

Allocation groups divide the space on a file system into chunks. Allocation groups are used only for a problem-solving technique in which the most appropriate solution, found by attempting alternative methods, is selected at successive stages of a program for using in the next step of the program. Allocation groups allow JFS2 resource-allocation policies to use well-known methods for achieving optimum I/O performance. First, the allocation policies try to cluster disk blocks and disk i-nodes for related data to achieve good locality for the disk. Files are often read and written sequentially and the files within a directory are often accessed together. Second, the allocation policies try to distribute unrelated data throughout the file system in order to accommodate disk locality. Allocation groups within a file system are identified by a zero-based allocation group index, the allocation group number. Allocation group sizes must be selected that yield allocation groups that are large enough to provide for contiguous resource allocation over time. Allocation groups are limited to a maximum number of 128 groups. The minimum allocation group size is 8192 file-system blocks.

Partial Allocation Groups

A file system whose size is not a multiple of the allocation group size will contain a partial allocation group; the last allocation group of the file system is not fully covered by disk blocks. This partial allocation group will be treated as a complete allocation group, except that the nonexistent disk blocks will be marked as allocated in the block allocation map.

Mounting
Mounting makes file systems, files, directories, devices, and special files available for use at a particular location. It is the only way a file system is made accessible. The mount command instructs the operating system to attach a file system at a specified directory. You can mount a file or directory if you have access to the file or directory being mounted and write permission for the mount point. Members of the system group can also perform device mounts (in which devices or file systems are mounted over directories) and the mounts described in the /etc/filesystems file. A user operating with root user authority can mount a file system arbitrarily by naming both the device and the directory on the command line. The /etc/filesystems file is used to define mounts to be automatic at system initialization. The mount command is used to mount after system startup. Mount points A mount point is a directory or file at which a new file system, directory, or file is made accessible. To mount a file system or a directory, the mount point must be a directory; and to mount a file, the mount point must be a file. Mounting file systems, directories, and files There are two types of mounts, a remote mount and a local mount. Remote mounts are done on a remote system on which data is transmitted over a telecommunication line. Remote file systems, such as Network File System (NFS), require that the files be exported before they can be mounted. Local mounts are mounts done on your local system. Automatic mount control Mounts can be set to occur automatically during system initialization. Mount security for diskless workstations Diskless workstations must have the ability to create and access device-special files on remote machines to have their /dev directories mounted from a server. Because servers cannot distinguish device-special files intended for a client from those intended for the server, a user on the server might be able to access the physical devices of the server using the special files of the client device.

Managing file system

A file system is a complete directory structure, including a root directory and any subdirectories and files beneath it.

File systems are confined to a single logical volume. Some of the most important system management tasks are concerning file systems, specifically: Allocating space for file systems on logical volumes Creating file systems Making file system space available to system users Monitoring file system space usage Backing up file systems to guard against data loss in the event of system failures Making a snapshot to capture a consistent block-level image of a file system at a given point in time Maintaining file systems in a consistent state.

Following is a list of system management commands that help manage file systems: backup chfs -a splitcopy dd df fsck mkfs mount restore snapshot umount Performs a full or incremental backup of a file system Creates an online backup of a mounted JFS file system Copies data directly from one device to another for making file system backups Reports the amount of space used and free on a file system Checks file systems and repairs inconsistencies Makes a file system of a specified size on a specified logical volume Attaches a file system to the system-wide naming structure so that files and directories in that file system can be accessed Restores files from a backup Creates a snapshot of a JFS2 file system Removes a file system from the system-wide naming structure, making the files and directories in the file system inaccessible.

Displaying available space on a file system (df command) Use the df command to display information about total space and available space on a file system. The FileSystem parameter specifies the name of the device on which the file system resides, the directory on which the file system is mounted, or the relative path name of a file system.

File system commands There are a number of commands designed to operate on file systems, regardless of type.

Comparing file systems on different machines When file systems that exist on different machines should be identical but you suspect one is damaged, you can compare the file systems.

Program Address Space Overview

The Base Operating System provides a number of services for programming application program memory use. Tools are available to assist in allocating memory, mapping memory and files, and

profiling application memory usage. As background, this section describes the system's memory management architecture and memory management policy.

System Memory Architecture Introduction

The system employs a memory management scheme that uses software to extend the capabilities of the physical hardware. Because the address space does not correspond one-to-one with real memory, the address space (and the way the system makes it correspond to real memory) is called virtual memory. The subsystems of the kernel and the hardware that cooperate to translate the virtual address to physical addresses make up the memory management subsystem. The actions the kernel takes to ensure that processes share main memory fairly comprise the memory management policy. The following sections describe the characteristics of the memory management subsystem in greater detail.

The Physical Address Space of 64-bit Systems

The hardware provides a continuous range of virtual memory addresses, from 0x00000000000000000000 to 0xFFFFFFFFFFFFFFFFFFFF, for accessing data. The total addressable space is more than 1 trillion terabytes. Memory access instructions generate an address of 64 bits: 36 bits to select a segment register and 28 bits to give an offset within the segment. This addressing scheme provides access to more than 64 million segments of up to 256M bytes each. Each segment register contains a 52-bit segment ID that becomes a prefix to the 28-bit offset, which together form the virtual memory address. The resulting 80-bit virtual address refers to a single, large, systemwide virtual memory space. The process space is a 64-bit address space; that is, programs use 64-bit pointers. However, each process or interrupt handler can address only the systemwide virtual memory space (segment) whose segment IDs are in the segment register.

Segment Register Addressing

The system kernel loads some segment registers in the conventional way for all processes, implicitly providing the memory addressability needed by most processes. These registers include two kernel segments, and a shared-library segment, and an I/O device segment, that are shared by all processes and whose contents are read-only to non-kernel programs. There is also a segment for the exec system call of a process, which is shared on a read-only basis with other processes executing the same program, a private shared-library data segment that contains read-write library data, and a read-write segment that is private to the process. The remaining segment registers may be loaded using memory mapping techniques to provide more memory, or through memory access to files according to access permissions imposed by the kernel. See Understanding Memory Mapping for information on the available memory mapping services. The system's 32-bit addressing and the access provided through indirection capabilities gives each process an interface that does not depend on the actual size of the systemwide virtual memory space. Some segment registers are shared by all processes, others by a subset of processes, and yet

others are accessible to only one process. Sharing is achieved by allowing two or more processes to load the same segment ID.

Paging Space
To accommodate the large virtual memory space with a limited real memory space, the system uses real memory as a work space and keeps inactive data and programs that are not mapped on disk. The area of disk that contains this data is called the paging space. A page is a unit of virtual memory that holds 4K bytes of data and can be transferred between real and auxiliary storage. When the system needs data or a program in the page space, it: 1. 2. Finds an area of memory that is not currently active. Ensures that an up-to-date copy of the data or program from that area of memory is in the paging space on disk. 3. Reads the new program or data from the paging space on disk into the newly freed area of memory.

Memory Management Policy

The real-to-virtual address translation and most other virtual memory facilities are provided to the system transparently by the Virtual Memory Manager (VMM). The VMM implements virtual memory, allowing the creation of segments larger than the physical memory available in the system. It accomplishes this by maintaining a list of free pages of real memory that it uses to retrieve pages that need to be brought into memory. The VMM occasionally must replenish the pages on the free list by removing some of the current page data from real memory. The process of moving data between memory and disk as the data is needed is called "paging." To accomplish paging, the VMM uses page-stealing algorithms that categorize pages into three classes, each with unique entry and exit criteria: working storage pages local file pages remote file pages

In general, working pages have highest priority, followed by local file pages, and then remote file pages. In addition, the VMM uses a technique known as the clock algorithm to select pages to be replaced. This technique takes advantage of a referenced bit for each page as an indication of what pages have been recently used (referenced). When a page-stealer routine is called, it cycles through a page frame table, examining each page's referenced bit. If the page was unreferenced and is stealable (that is, not pinned and meets other page-stealing criteria), it is stolen and placed on the free list. Referenced pages may not be stolen, but their reference bit is reset, effectively "aging" the reference so that the page may be stolen the next time a page-stealing algorithm is issued. See Paging Space Programming Requirements for more information.

Memory Allocation
Version 3 of the operating system uses a delayed paging slot technique for storage allocated to applications. This means that when storage is allocated to an application with a subroutine such as malloc, no paging space is assigned to that storage until the storage is referenced. See System Memory Allocation Using the malloc Subsystem to learn more about the system's allocation policy.