|< Day Day Up >|
8.5 VxFS Internal Structures
VxFS first made its appearance in HP-UX version 10.01. Since then, it has grown in use and has become the default filesystem type in HP-UX version 11.X. With its current incarnation, it supports all the features of HFS including ACLs which were missing until layout version 4 (JFS version 3.3). Version 3.3 is available for HP-UX version 11.X as well as HP-UX version 10.20. As such, VxFS is the way forward as far as filesystems are concerned for HP-UX. The product is known by two main names: JFS (Journaled File System), which is the name associated with the software product itself, and VxFS (Veritas extended File System), which is the filesystem type. The easy way to remember this is that JFS is the product used to access VxFS filesystems.
The key benefits to using VxFS can be summarized as follows:
When we look at the basic building blocks of VxFS, they appear to be similar to the building blocks of HFS (Figure 8-4).
Figure 8-4. Basic VxFS layout.
In comparison to HFS, there are a number of conceptual similarities; we have a Superblock, which is a road map to the rest of the filesystem. An Allocation Unit is similar to the concept of a Cylinder Group in HFS in that it is a localized collection of tracks and cylinders. In VxFS, an Allocation Unit is 32MB in size (possibly with the exception of the last AU). There are some fundamental differences that are not immediately apparent.
The OLT is the Object Location Table. This structure references a number of structural elements that I haven't shown in Figure 8-4. Information stored in the OLT includes information relating to where to find the initial inodes describing the filesystem, the device configuration (HP-UX currently allows only one device per filesystem, even if it is a logical device), where to find redundant superblocks, as well as space for information not maintained in version 4 layout such as the Current Usage Table. One of the main elements in the OLT is a reference to a list of fileset headers. A fileset is essentially a collection of files/inodes stored within the data blocks of the filesystem. When I was first told this, I immediately equated a fileset to an inode list. This is a fair comparison, if a little naive. In VxFS, we (currently) have two filesets. Fileset 1 (known as the Structural Fileset) and Fileset 999 (known as the Unnamed or Primary Fileset). You and I, as users, will interface with the Primary Fileset because it references inodes that are user visible, i.e., regular files, directories, links, device files, etc., and it is the fileset that is mounted by default (in the future, it may be possible to support and mount more filesets; cloning a fileset may be possible). The Structural Fileset contains structural information relating to the filesystem, and there are no standard user-accessible commands to view files/inodes within Fileset 1. Fileset 1 is there to be used by the filesystem as it sees fit; for example, an inode in the Primary Fileset may reference and inode in the Structural Fileset for BSD-style quota information.
In VxFS, we have inodes that work in a similar way to inodes in an HFS filesystem; i.e., they reference the file type and mode, ownership, size, timestamps, and references to data blocks. This is where things start to change. VxFS are 256 bytes in size. One of the reasons an inode is bigger is that VxFS inodes can have attributes associated with them (more on attributes later). Another reason an inode is bigger is that we need to store information relating to allocation flags set by the setext command, e.g., contiguous allocation of extents for this file. One other fundamental difference is the way an inode will reference the data blocks (=extents) associated with the user file. This is known as the Inode Organization Type (i_orgtype). There are four organization types:
Inodes are referenced via entries in the Inode List Table. This table can reference clumps of inodes known as Inode Extents, much in the same way that normal inodes reference clumps (extents) of data. The Inode List Table is a Structural File and has its own Structural inode, which follows the same organization type definitions as normal inodes. In VxFS, we do not create inodes until we need them (dynamic inode allocation). Consequently, Inode Extents may not necessarily contiguous. Inside the Inode Extent will be an Inode Allocation Unit Table, which stores information used to allocate inodes for that Inode List Table. All this proves that files/inodes in the Structural Fileset are used much in the same way as files/inodes in the Primary Fileset; it's just that we don't normally deal with them directly.
The last piece of VxFS theory we discuss is inode attributes. There are 72 bytes reserved at the end of the inode dedicated to attributes. In addition, an inode can have an attribute inode (similar in concept to a continuation inode in HFS). If used, an attribute inode is referenced via the iattrino structure in the general inode (there's a list of corresponding attribute inodes for every general inode). Who uses these attributes? Applications that are VxFS-aware can use them if they so desire. Take a backup application such as the Hierarchical Storage Management products like DataProtector. If coded properly, there's nothing to say that these applications could store a "tape archived" attribute with the inode every time it's backed up. This has nothing to do with standard filesystem commands (that don't know anything about this attribute), but might mean lots to the backup application. The only standard filesystem commands that currently use attributes are VxFS ACLs. We have discussed ACLs previously, but just let me do a quick recap. With ACLs, we can give users their own access permissions for files and directories. This allows a filesystem to meet a specific part of the C2 (U.S. Department of Defense: Orange Book) level of security. VxFS ACLs are managed by the getacl and setacl commands. Here, fred and barney are given their own permissions to the /logdata/db.log file:
root@hpeos003 pwget -n fred fred:rK23oXbRNKgAo:109:20::/home/fred:/sbin/sh root@hpeos003 pwget -n barney barney:acGNA0B.QxKYI:110:20::/home/barney:/sbin/sh root@hpeos003 root@hpeos003 getacl /logdata/db.log # file: /logdata/db.log # owner: root # group: sys user::rw- group::rw- class:rw- other:r-- root@hpeos003 setacl -m "user:fred:rwx" /logdata/db.log root@hpeos003 setacl -m "user:barney:---" /logdata/db.log root@hpeos003 getacl /logdata/db.log # file: /logdata/db.log # owner: root # group: sys user::rw- user:fred:rwx user:barney:--- group::rw- class:rwx other:r-- root@hpeos003
Let's see if we can find the attributes just applied:
root@hpeos003 ll -i /logdata/db.log 4 -rw-rwxr-- 1 root sys 212726016 Nov 13 13:04 /logdata/db.log root@hpeos003 root@hpeos003 echo "4i" | fsdb -F vxfs /dev/vx/dsk/ora1/logvol inode structure at 0x000003f8.0400 type IFREG mode 100674 nlink 1 uid 0 gid 3 size 212726016 atime 1068728572 410003 (Thu Nov 13 13:02:52 2003 BST) mtime 1068728665 710006 (Thu Nov 13 13:04:25 2003 BST) ctime 1068736084 820007 (Thu Nov 13 15:08:04 2003 BST) aflags 0 orgtype 3 eopflags 0 eopdata 0 fixextsize/fsindex 0 rdev/reserve/dotdot/matchino 0 blocks 51938 gen 2 version 0 96 iattrino 0 ext0: INDIR boff: 0x00000000 bno: 67584 len: 2 ext1: NULL boff: 0x00000000 bno: 0 len: 0 ext2: NULL boff: 0x00000000 bno: 0 len: 0 ext3: NULL boff: 0x00000000 bno: 0 len: 0 ext4: NULL boff: 0x00000000 bno: 0 len: 0 ext5: NULL boff: 0x00000000 bno: 0 len: 0 root@hpeos003
As we can see, iattrino has not been set. This means that if we do not look for the attribute inode, the attribute will be stored in the last 72 bytes of this inode. We can dump the attributes with the fsdb attr command:
root@hpeos003 echo "4i.attr.p 18 x" | fsdb -F vxfs /dev/vx/dsk/ora1/logvol 000003f8.04b8: 00000001 0000003c 00000001 00000001 000003f8.04c8: 00000003 00000000 00000002 0000006d 000003f8.04d8: 00070000 00000002 0000006e 00000000 000003f8.04e8: 00000004 00000000 00060000 00000000 000003f8.04f8: 00000000 00000000 00008180 00000001 root@hpeos003
This takes a little deciphering, but look at each highlighted element in turn:
This introduction into the background behind VxFS will allow us to understand how VxFS works and may help us to answer some questions when we run fsck. What we need to discuss now are the additional administrative features related that the Online JFS brings to our system.
|< Day Day Up >|