developerWorks : Linux | Open Source : Features / Library - Papers
`
`Home
`
`Products
`
`Consulting
`
`Industries
`
`News
`
`About IBM
`
`Search
`
`IBM : developerWorks : Linux library | Open source library
`
`Download it now!
`PDF (543 KB)
`Free Acrobat™ Reader
`
`JFS layout
`How the Journaled File System handles the on-disk layout
`Steve Best, Linux Technology Center, IBM
`Dave Kleikamp, Linux Technology Center, IBM
`May 2000
`This article describes the on-disk Journaled File System (JFS) layout and the
`mechanisms used to achieve scalability, reliability, and performance using the
`on-disk layout structures. You'll learn about the policies and algorithms used to
`manipulate these structures and where JFS uses B+ trees throughout the file system
`to increase file system operations.
`The JFS architecture can be explained in the context of its disk layout characteristics. The
`on-disk layout is the format used by JFS to control the file system. This paper covers
`extent-based file geometry, the directory formats, the formats of block allocation maps,
`inodes, and other characteristics of the layout structures. It provides detail and examples of
`the B+ tree data structures used for file layout. B+ trees were selected to increase the
`performance of reading and writing extents, the most common operations that JFS does.
`Partitions, aggregates, allocation groups, filesets
`Here is the "big picture" view of the on-disk layout.
`Partitions
`A JFS file system is built on top of a partition, which is the abstraction exported to JFS by
`FDISK.
`A partition has:
`A fixed partition block size, with legal values of 512, 1024, 2048, or 4096 bytes. The
`●
`partition block size defines the smallest unit of I/O supported on the partition. It
`corresponds to the underlying disk sector size of the physical device making up the
`partition, with 512 bytes being the most common size.
`A size, PART_NBlocks, which is the number of partition disk blocks.
`●
`An abstract address space, [ 0 .. PART_NBlocks - 1 ], of partition disk blocks.
`●
`Aggregates
`To support DCE DFS (Distributed Computing Environment Distributed File System), JFS separates the notion of a disk
`space allocation pool, called an aggregate, from the notion of a mountable file system sub-tree, called a fileset. The terms
`aggregate and fileset in this article correspond to their DFS usage. There is exactly one aggregate per partition; there may
`be multiple filesets per aggregate. In the first release, JFS only supports one fileset per aggregate; however, all of the
`meta-data has been designed for the fully general case.
`Figure 1 shows the layout of an aggregate with two filesets.
`
`Contents:
` Partitions, aggregates, AGs,
`filesets
` Extents, inodes, B+ trees
` Block Allocation Map
` Inode allocations
` Fileset allocation inodes
` File
` Symbolic link
` Directory
` Access Control List (ACL)
` Extended Attribute (EA)
` Streams
` Aggregate with a fileset
` Summary
` Resources
` About the authors
`
`http://swgiwas001.sby.ibm.com/developerworks/library/jfslayout/index1.html (1 of 30) [4/18/2001 2:46:34 PM]
`
`SPRINGPATH
`EXHIBIT 1011
`
`

`
`developerWorks : Linux | Open Source : Features / Library - Papers
`
`An aggregate has:
`A 32K reserved area at the front of it.
`●
`A fixed aggregate block size, with legal values of 512, 1024, 2048, or 4096 bytes, but no smaller than the partition
`●
`block size. The aggregate block size defines the smallest unit of space allocation supported on the aggregate. Do
`2/30
`http://swgiwas001.sby.ibm.com/developerworks/library/jfslayout/index1.html (2 of 30) [4/18/2001 2:46:34 PM]
`
`

`
`developerWorks : Linux | Open Source : Features / Library - Papers
`not confuse it with the partition block size, which defines the smallest unit of I/O.
`A Primary Aggregate Superblock and Secondary Aggregate Superblock. The superblocks contain aggregate-wide
`●
`information such as the size of the aggregate, size of allocation groups, aggregate block size, etc. The secondary
`aggregate superblock is a direct copy of the primary aggregate superblock. The secondary superblock is used if the
`primary aggregate superblock is corrupted. These superblocks are at fixed locations. This allows JFS to always be
`able to find these without depending on any other information. The superblock structure is defined in
`jfs_superblock.h, struct jfs_superblock.
`An Aggregate Inode Table, containing inodes describing the aggregate-wide control structures. The Aggregate
`●
`Inode Table logically contains an array of inodes. An aggregate has no directory structure; the aggregate inodes are
`not visible anywhere in the aggregate or fileset name space.
`A Secondary Aggregate Inode Table, containing replicated inodes from the Aggregate Inode Table. Since the
`●
`inodes in the Aggregate Inode Table are critical for finding any file system information, they will each be
`replicated in the Secondary Aggregate Inode Table. The actual data for the inodes will not be repeated, just the
`addressing structures used to find the data and the inode itself.
`An Aggregate Inode Map, which describes the Aggregate Inode Table. The Aggregate Inode Allocation Map
`●
`contains allocation state information on the aggregate inodes as well as their on-disk location.
`A Secondary Aggregate Inode Map, which describes the Secondary Aggregate Inode Table. Since the Aggregate
`●
`Inode Table itself must be duplicated, the Secondary Aggregate Inode Map is actually a separate mapping structure
`from the Aggregate Inode Allocation Map.
`A Block Allocation Map, which describes the control structures for allocating and freeing aggregate disk blocks
`●
`within the aggregate. The Block Allocation Map maps one-to-one within the aggregate disk blocks.
`A fsck Working Space (not shown in Figure 1), which provides space for fsck to track the aggregate block
`●
`allocation. This space is necessary because JFS supports very large aggregates; there might not be enough memory
`to track this information in memory when fsck is run. The space is described by the superblock. One bit is
`needed for every aggregate block. The fsck working space always exists at the end of the aggregate.
`An In-line Log (not shown in Figure 1) provides space for logging of meta-data changes of the aggregate. The
`●
`space is described by the superblock. The in-line log always follows the fsck working space.
`Initially, the first inode extent is allocated when the aggregate is created. Additional inode extents are allocated and
`deallocated dynamically as needed. These Aggregate Inodes each describe certain aspects of the aggregate itself, as
`follows:
`Aggregate Inode zero is reserved.
`●
`Aggregate Inode one, the "self" inode, describes the aggregate disk blocks comprising the Aggregate Inode Map.
`●
`This is a circular representation, in that Aggregate Inode one is itself in the file that it describes. The obvious
`circular representation problem is handled by forcing at least the first aggregate inode extent to appear at a
`well-known location, namely, 4K after the Primary Aggregate Superblock. Therefore, JFS can easily find
`Aggregate Inode one, and from there it can find the rest of the Aggregate Inode Table by following the B+ tree in
`Inode one.
`To duplicate the Aggregate Inode Table, JFS will also need to find the copy of the Aggregate Inode one to find the
`●
`rest of the duplicated table. The superblock will contain an extent descriptor that describes the location of the first
`inode extent of the Second Aggregate Inode Table. From that JFS will be able to find the Secondary Aggregate
`Inode one and the rest of the Secondary Aggregate Inode Table.
`Aggregate Inode two describes the Block Allocation Map.
`●
`Aggregate Inode three describes the In-line Log when mounted. This inode is allocated, but no data is saved to
`●
`disk.
`Aggregate Inode four describes the bad blocks discovered during formatting of the aggregate. These bad blocks are
`●
`marked allocated in the block map. This inode is a normal file whose data is the bad blocks.
`Aggregate Inodes five through 15 are reserved for future extensions.
`●
`Starting at Aggregate Inode 16, there is one inode per fileset, the Fileset Allocation Map Inode. This inode
`●
`describes the control structures that represent filesets. As additional filesets are added to the aggregate, the
`Aggregate Inode Table itself may have to grow to accommodate additional fileset inodes.
`3/30
`http://swgiwas001.sby.ibm.com/developerworks/library/jfslayout/index1.html (3 of 30) [4/18/2001 2:46:34 PM]
`
`

`
`developerWorks : Linux | Open Source : Features / Library - Papers
`
`Allocation groups
`Allocation groups (AGs) divide the space in an aggregate into chunks, and allow JFS resource allocation policies to use
`well known methods for achieving great JFS I/O performance. First, the 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 the
`files within a directory are often accessed together. Second, the allocation policies try to distribute unrelated data
`throughout the aggregate in order to accommodate locality. Allocation groups within an aggregate are identified by a
`zero-based AG index, the AG number.
`Allocation group sizes must be selected, which yield AGs that are sufficiently large to provide for contiguous resource
`allocation over time. To minimize the number of updates that need to be done when an aggregate is expanded or shrunk,
`the allocation groups need to be limited to a maximum number of groups, 128. Additionally, JFS will impose a minimum
`on the allocation group size of 8192 aggregate blocks. The allocation group size must always be a power of 2 multiple of
`the number of blocks described by one dmap page (1, 2, 4, 8, ... dmap pages). The allocation group size is stored in the
`aggregate superblock.
`An aggregate whose size is not a multiple of the allocation group size will contain a partial allocation group; the last
`allocation group of the aggregate is not fully covered by disk blocks. This partial allocation group will be treated as a
`complete allocation group, except JFS will mark the non-existent disk blocks allocated in the Block Allocation Map.
`Filesets
`A fileset is a set of files and directories that form an independently mountable sub-tree. A fileset is completely contained
`within a single aggregate. Note that multiple filesets may exist within a single aggregate; in that case, all of the filesets
`share a common pool of free aggregate disk blocks as defined by the aggregate control structures.
`Figure 2 shows the layout of two filesets contained in an aggregate.
`
`4/30
`http://swgiwas001.sby.ibm.com/developerworks/library/jfslayout/index1.html (4 of 30) [4/18/2001 2:46:34 PM]
`
`

`
`developerWorks : Linux | Open Source : Features / Library - Papers
`
`A fileset has:
`A Fileset Inode Table, containing inodes describing the fileset-wide control structures. The Fileset Inode Table
`●
`logically contains an array of inodes.
`A Fileset Inode Allocation Map, which describes the Fileset Inode Table. The Fileset Inode Allocation Map
`●
`contains allocation state information on the fileset inodes as well as their on-disk location. The "super-inode"
`describing the Fileset Allocation Map and other fileset information resides in the Aggregate Inode Table as
`previously described. Since the Aggregate Inode Table is replicated, there is also a secondary version of this inode,
`which points to the same data. The "super-inode" is itself a file. When the fileset is initially created, the first inode
`extent is allocated; additional inode extents are allocated and deallocated dynamically as needed.
`The inodes in a fileset are allocated as follows:
`Fileset inode zero is reserved.
`●
`Fileset inode one contains additional fileset information that would not fit in the Fileset Allocation Map Inode in
`●
`the Aggregate Inode Table.
`Fileset inode two is the root directory inode for the fileset. Note that JFS preserved the common Unix convention
`●
`that inode number two is the root of the file "system."
`Fileset inode three is the ACL file for the fileset.
`●
`Fileset inodes starting with four are used by ordinary fileset objects, user files, directories, and symbolic links.
`●
`Extents, inodes, B+ trees
`An extent is a sequence of contiguous aggregate blocks allocated to a JFS object as a unit. An extent is wholly contained
`within a single aggregate (and therefore a single partition); however, large extents may span multiple allocation groups.
`Every JFS object is represented by an inode. Inodes contain the expected object-specific information such as time stamps
`and file type (regular vs. directory, etc.). They also "contain" a B+ tree to record the allocation of extents. Note
`specifically that all JFS meta data structures (except for the superblock) are represented as "files". By reusing the inode
`structure for this data, the data format (on-disk layout) becomes inherently extensible.
`Details of extents, B+ trees, and inodes are in the sections that follow.
`Extents
`A "file" is allocated in sequences of extents. An extent is a contiguous variable-length sequence of aggregate blocks
`allocated as a unit. An extent can range in size from 1 to 2(24) - 1 aggregate blocks. An extent may span multiple
`Allocation Groups (AGs). These extents are indexed in a B+ tree for better performance in inserting new extents, locating
`particular extents, etc.
`
`5/30
`http://swgiwas001.sby.ibm.com/developerworks/library/jfslayout/index1.html (5 of 30) [4/18/2001 2:46:34 PM]
`
`

`
`developerWorks : Linux | Open Source : Features / Library - Papers
`
`Two values are needed to define an extent, its length and its address. The length is measured in units of aggregate block
`size. JFS uses a 24-bit value to represent the length of an extent, so an extent can range in size from 1 to 2(24) - 1
`aggregate blocks.
`With a 512-byte aggregate block size (the smallest allowable), the maximum extent is 512 * (2(24) - 1) bytes long
`(slightly under 8G). With a 4096-byte aggregate block size (the largest allowable), the maximum extent is 4096 * (2(24) -
`1) bytes long (slightly under 64G). These limits only apply to a single extent; they have no limiting effects on overall file
`size. The address is the address of the first block of the extent. The address is also in units of the aggregate blocks: it is
`the block offset from the beginning of the aggregate.
`An extent-based file system combined with a user-specified aggregate block size allows JFS to need no separate support
`for internal fragmentation. You can configure the aggregate with a small aggregate block size (for example, 512 bytes) to
`minimize internal fragmentation for aggregates with a large number of small size files.
`In general, the allocation policy for JFS tries to maximize contiguous allocation by allocating a minimum number of
`extents, with each extent as large and contiguous as possible. This allows for large I/O transfer, resulting in improved
`performance. However, in special cases this is not always possible. For example, copy-on-write clones of a segment will
`cause a contiguous extent to be partitioned into a sequence of smaller contiguous extents. Another case is restriction of
`extent size. For example, the extent size is restricted for compressed files since JFS must read the entire extent into
`memory and decompress it. JFS has a limited amount of memory available, so it must ensure that it will have enough
`room for the decompressed extent.
`A defragmentation utility is provided to reduce external fragmentation, which occurs from dynamic
`allocation/deallocation of variable-size extents. This allocation and deallocation can result in disconnected variable size
`free extents all over the aggregate. The defragmentation utility will coalesce multiple small free extents into single larger
`extents.
`Inodes
`JFS on-disk inode is 512 bytes. A JFS on-disk inode contains four basic sets of information. The first set describes the
`POSIX attributes of the JFS object. The second set describes additional attributes for JFS object; these attributes include
`information necessary for the VFS support, information specific to the OS environment, and the header for the B+ tree.
`The third set contains either the extent allocation descriptors of the root of the B+ tree or in-line data. The fourth set
`contains extended attributes, more in-line data, or additional extent allocation descriptors. The definition of the on-disk
`inode structure is defined in jfs_dinode.h, struct dinode.
`
`JFS allocates inodes dynamically, which provides the following advantages:
`Inode disk blocks may be placed at any disk address, which decouples the inode number from the location. This
`●
`decoupling simplifies supporting aggregate and fileset reorganization to enable shrinking the aggregate. The inodes
`can be moved, and they will still have the same number. This allows JFS not to need to search the directory
`structure to update the inode numbers. The decoupling is also necessary for supporting DFS fileset cloning. When
`a fileset is cloned, just the inodes are copied. Since JFS can put the new inodes anywhere on disk, the new inodes
`will have the same numbers as the inodes they are copied from. This allows JFS not to have to copy the directory
`structures and update the inode numbers.
`It eliminates the need to allocate "ten times as many inodes as you will ever need." This is especially important
`●
`with the larger inode size (512 bytes) in JFS.
`File allocation for large files can consume multiple allocation groups and still be contiguous, whereas static
`●
`allocation forces a gap (for the initially allocated inodes in each allocation group).
`On the other hand, dynamic inode allocation causes a number of problems, including the following:
`With static allocation the geometry of the file system implicitly describes the layout of inodes on disk; with
`●
`dynamic allocation separate mapping structures are required.
`Those mapping structures are critical to JFS integrity. Due to the overhead involved in replicating these structures,
`●
`JFS has decided to accept the risk of loss of these maps. However, JFS will replicate the B+ tree structures, which
`allows JFS to find the maps.
`Inodes are allocated dynamically by allocating inode extents that are simply a contiguous chunk of inodes on the disk. By
`6/30
`http://swgiwas001.sby.ibm.com/developerworks/library/jfslayout/index1.html (6 of 30) [4/18/2001 2:46:34 PM]
`
`

`
`developerWorks : Linux | Open Source : Features / Library - Papers
`definition, a JFS inode extent contains 32 inodes. With a 512-byte inode size, an inode extent is therefore 16KB in size
`on the disk.
`When a new inode extent is allocated, the extent is not initialized. However, for fsck to be able to check if an inode is
`in use, JFS will need some information in the inode to check. Once an inode in an extent is marked in-use, its fileset
`number, inode number, inode stamp, and the inode allocation group block address must be initialized. Thereafter, the link
`field will be sufficient to determine if the inode is currently in use.
`Notice that dynamic inode allocation implies that there is no direct relationship between an inode number and the disk
`address of the inode. Therefore, JFS must have a means of finding the inodes on disk. The Inode Allocation Map
`provides this function.
`Inodes generation numbers are simply counters that get incremented each time an inode is reused.
`The static-inode-allocation practice of storing a per-inode generation counter doesn't work with dynamic inode
`allocation, because when an inode becomes free, its disk space may literally be reused for something other than an inode
`(in other words, the space may be reclaimed for ordinary file data storage). Therefore, in JFS there is simply one inode
`generation counter that is incremented on every inode allocation, rather than one counter per inode that would be
`incremented when that inode is reused.
`B+ trees
`This section describes the B+ tree data structure used for file layout. B+ trees were selected to increase the performance
`of reading and writing extents, which are the most common operations JFS will have to do. B+ trees provide a fast search
`for reading a particular extent of a file. They also provide an efficient way to append or insert an extent in a file. Less
`commonly, JFS will need to traverse an entire B+ tree when removing a file. In order to ensure JFS will remove the
`blocks used for the B+ tree as well as the file data, the B+ tree is also efficient for traversal.
`An extent allocation descriptor (xad structure) describes the extent and adds two more fields that are needed for
`representing files: an offset, describing the logical byte address the extent represents, and a flags field. The extent
`allocation descriptor structure is defined in jfs_xtree.h, struct xad.
`
`The xad structure is:
` struct xad {
` unsigned flag:8;
` unsigned rsvrd:16;
` unsigned off1:8;
` uint32 off2;
` unsigned len:24;
` unsigned addr1:8;
` uint32 addr2;
` } xad_t;
`
`where:
`flag is an 8-bit field containing miscellaneous flags. These flags can indicate copy-on-write, if the extent is
`●
`allocated but not recorded, information for compression, etc.
`rsvrd is a 16-bit field reserved for future use. It is always zero.
`●
`off1,off2 is a 40-bit field, containing the logical offset of the first block in the extent. The logical offset is
`●
`represented in units of the aggregate block size; in other words, to get a byte, offset must be multiplied by the
`aggregate block size.
`len is a 24-bit field, containing the length of the extent. The length is represented in units of aggregate block size.
`●
`addr1,addr2 is a 40-bit field, containing the address of the extent. The address is represented in units of aggregate
`●
`block size.
`An xad structure describes two abstract ranges:
`The physical range of disk blocks on the disk. This starts at aggregate block number xad_address and extends for
`●
`xad_length aggregate blocks.
`
`7/30
`http://swgiwas001.sby.ibm.com/developerworks/library/jfslayout/index1.html (7 of 30) [4/18/2001 2:46:34 PM]
`
`

`
`developerWorks : Linux | Open Source : Features / Library - Papers
`The logical range of bytes within a file. This starts at byte number xad_offset * AGBS (aggregate block size) and
`●
`extends for xad_length * AGBS bytes.
`The physical range and logical range are, of course, both the same number of bytes long. Note that xad_offset is
`stored in units of aggregate block size (for example, a value of "3" in xad_offset means 3 aggregate blocks, not 3
`bytes). It follows from this that extents within a file are always aligned on aggregate block size boundaries.
`There is one generic B+ tree index structure for all index objects (except for directories) in JFS. The data being indexed
`will depend on the object. The B+ tree is keyed by offset of xad of data being described by the tree. The entries are sorted
`by the offsets of the xad structures. An xad structure is an entry in a node of a B+ tree.
`Figure 3 shows a single xad structure and how it describes both the range of bytes logically within the file as well as the
`physical location of that range of bytes on the disk itself (in other words, with the aggregate).
`
`The bottom of the second section of a disk inode contains a data descriptor that tells what is stored in the second half of
`the inode. The second half could contain in-line data for the file if it is small enough. If the file data won't fit in the
`in-line data space for the inode, it will be contained in extents, and the inode will contain the root node of the B+ tree.
`The header will indicate how many xad are in use and how many are available. Generally, the inode will contain 8 xad
`structures for the root of the B+ tree. If there are 8 or fewer extents for the file, then these 8 xad structures are also a leaf
`node of the B+ tree. They will describe the extents. (See Figure 4, example 1.) Otherwise the 8 xad structures in the inode
`will point to either the leaves or internal nodes of the B+ tree.
`
`8/30
`http://swgiwas001.sby.ibm.com/developerworks/library/jfslayout/index1.html (8 of 30) [4/18/2001 2:46:34 PM]
`
`

`
`developerWorks : Linux | Open Source : Features / Library - Papers
`
`9/30
`http://swgiwas001.sby.ibm.com/developerworks/library/jfslayout/index1.html (9 of 30) [4/18/2001 2:46:34 PM]
`
`

`
`developerWorks : Linux | Open Source : Features / Library - Papers
`
`Once the 8 xad structures in the inode are filled, an attempt will be made to use the last quadrant of the inode for more
`xad structures. If the INLINEEA bit is set in the di_mode field of the inode, then the last quadrant of the inode is
`available.
`Once all of the available xad structures in the inodes are used, the B+ tree must be split. JFS will allocate 4K of disk
`space for a leaf node of the B+ tree. A leaf node is logically an array of xad entries with a header. The header points to
`the first free xad entry in the node, all xad entries following that one are also not allocated. The 8 xad entries are copied
`from the inode to the leaf node, the header is initialized to point to the 9th entry as the first free entry. Then JFS will
`update the root of the B+ tree into the inode's first xad structure; this xad structure will point to the newly allocated leaf
`node. The offset for this new xad structure will be the offset of the first entry in the leaf node. The header in the inode
`will be updated to indicate that now only 1 xad is being used for the B+ tree. The header in the inode also needs to be
`updated to indicate that the inode now contains the pure root of the B+ tree. (See Figure 4, example 2.)
`
`As new extents are added to the file, they will continue to be added to this same leaf node in the necessary order. This
`will continue until this node fills. Once the node fills a new 4K of disk space will be allocated for another leaf node of the
`B+ tree. The second xad structure from the inode will be set to point to this newly allocated node. (See Figure 4, example
`3.)
`This will continue until all 8 xad structures in the inode are filled, at which time another split of the B+ tree will occur.
`This split will create internal inodes of the B+ tree which are used purely to route the searches of the tree. JFS will
`allocate 4K of disk space for an internal node of the B+ tree. An internal node looks the same as a leaf node. The 8 xad
`entries are copied from the inode to the internal node, the header is initialized to point to the 9th entry as the first free
`entry. Then JFS will update the root of the B+ tree by making the inode's first xad structure pointed to the newly
`allocated internal inode. The header in the inode will be updated to indicate that only 1 xad is being used for the B+ tree.
`(See Figure 4, example 4.)
`
`The file jfs_xtree.h describes the header for the root of the B+ tree in struct xtpage_t. The file jfs_btree.h is the
`header for an internal node or a leaf node in struct btpage_t.
`Examples
`The following examples further illustrate the use of extent descriptors and xad structures:
`A 1041377 byte file, allocated contiguously.
`●
`The same 1041377 byte file, but split into three pieces on the disk.
`●
`A 1041377 byte file, but with a "hole" in it (a sparse file).
`●
`A 16GB file, allocated contiguously.
`●
`In all of these examples, the aggregate block size is 1KB.
`1041377 byte file, allocated contiguously: This file requires 1017 1KB aggregate blocks (with 31 bytes in the last
`aggregate block lost to internal fragmentation). Only one xad structure is required to describe this contiguous file:
`flag not discussed here
`offset 0 /* the beginning of the file */
`length 1017 /* 1017 1KB aggregate blocks */
`address xxxxx /* aggregate block # */
`
`This same xad structure could represent any contiguous file of size 1040385 (1016 * 1024 + 1) to 1041408 (1017 *
`1024), because extent descriptors only represent sizes down to aggregate block size granularity. Only the inode
`di_size field records byte granularity.
`1041377 byte file, in three pieces: Assume that the same file is split into three separate extents on the disk: one 495
`aggregate blocks long, one 22, one 500. It requires three xad structures to represent this file one per physical extent:
`
`10/30
`http://swgiwas001.sby.ibm.com/developerworks/library/jfslayout/index1.html (10 of 30) [4/18/2001 2:46:34 PM]
`
`

`
`developerWorks : Linux | Open Source : Features / Library - Papers
`xad #0:
`flag not discussed here
`offset 0 /* the beginning of the file */
`length 495 /* 495 1KB aggregate blocks */
`address xxxxx /* aggregate block # */
`
`xad #1:
`flag not discussed here
`offset 495 /* the beginning of the file */
`length 22 /* 22 1KB aggregate blocks */
`address yyyyy /* aggregate block # */
`
`xad #2:
`flag not discussed here
`offset 517 /* the beginning of the file */
`length 500 /* 500 1KB aggregate blocks */
`address zzzzz /* aggregate block # */
`
`In this case, xad number 0 describes the first 495 physical aggregate blocks of the file. The xad_offset field contains
`zero, because this xad describes the bytes starting at logical offset zero. The next xad, xad number 1, describes the next
`22 physical aggregate blocks of the file. The xad_offset field contains 495, because this xad describes the bytes
`starting at logical offset 506880 (495 * 1024); the previous bytes being described by xad 0. The final xad describes the
`last 500 blocks of the file. The xad_offset field here is 517. Notice that for files which are not sparse, the
`xad_offset field of a given xad is equal to the sum of the lengths of all previous xad structures (517 = 495 + 22 in
`this example). If this relationship were always true, the xad_offset fields would be redundant and could be
`eliminated. However, the next example shows that, for sparse files, the xad_offset field is not redundant.
`1041377 byte sparse file: Consider a file created via the following POSIX style operations:
`fd = create ("newfile", blah blah blah);
`write (fd, "hi", 2);
`lseek (fd, 1041374, 0);
`write (fd, " bye" , 3);
`
`This file has two bytes of data ("hi") starting at logical byte offset zero, and three more bytes starting at logical byte
`offset 1,041,374 ("bye"), and would be all zero (sparse) in between. The file is 1041377 bytes long.
`In general, JFS does not allocate physical disk space to hold byte ranges of a file that has never been written to.
`Therefore, it will take two xad structures to represent this file: one for an extent containing the "hi" data, and one for an
`extent containing the "bye" data:
`xad #0 :
`flag not discussed here
`offset 0 /* the beginning of the file */
`length 1 /* 1 1KB aggregate blocks */
`address xxxxx /* aggregate block # */
`
`xad #1:
`flag not discussed here
`offset 1016 /* the beginning of the file */
`length 1 /* 1 1KB aggregate blocks */
`address yyyyy /* aggregate block */
`
`In this case, the first extent (xad 0) contains the bytes "hi", followed by 1022 bytes of zero. The last extent (xad 1)
`contains 990 bytes of zero, followed by the 3 bytes of "bye". The remaining 31 bytes in the 1KB extent are not part of the
`file (they are the same 31 bytes lost to internal fragmentation as in the first example).
`Notice that in this case the xad_offset fields are necessary; they are the only way to know that xad 1 represents a
`11/30
`http://swgiwas001.sby.ibm.com/developerworks/library/jfslayout/index1.html (11 of 30) [4/18/2001 2:46:34 PM]
`
`

`
`developerWorks : Linux | Open Source : Features / Library - Papers
`sequence of bytes that are at an "unexpected" logical offset within the file (that is, the offset for xad 1 does not equal the
`offset of xad 0 + length). This is how sparse files are represented.
`The di_size field of the inode will contain the offset value of the last byte written plus one.
`16GB file, allocated contiguously: The length field in an xad structure is only 24 bits long: therefore, it can hold a value
`of up to 2(24) - 1. If the aggregate block size is 1KB ( for example), then the longest extent a single xad can represent is
`(2(24) - 1 ) * 2(10) = 1KB less than 16G. By implication, this is also the largest extent a single xad structure can