8.9 Navigating through Filesystems via the VFS Layer

     

The HP-UX kernel supports a multitude of filesystems. HP-UX, like most other versions of UNIX, provides a standard interface to users to manage files and directories. The example we used of hard and soft links in the HFS section would work as well in the VxFS section. To users, we have one monolithic filesystem. In reality, the underlying filesystems can be UFS, VxFS, NFS, CDFS, DFS, AutoFS, CacheFS, CIFS, and Loopback FS. The technology that allows us to present this single interface to users is known as the Virtual Filesystem Layer that uses virtual nodes ( vnode ) to reference each individually mounted filesystem (Figure 8-7).

Figure 8-7. The VFS layer.

graphics/08fig07.gif


The VFS structures hide the technicalities of mount points and filesystems away from users. When navigating through a multitude of filesystems, the code can locate an individual file in an individual filesystem while being guided by the VFS layer to a superblock structure on a particular disk (the mount command tells the kernel on which device to find a filesystem), which subsequently guides us to where the inodes for files are held on disk. Once read into memory (into the inode cache ), we can index through the inode cache to locate a particular inode from a particular device. Here's a simple example of navigating through a filesystem tree. When we read the /stand/system file, we have to traverse through two different filesystem types: VxFS for the root filesystem and HFS for the /stand filesystem. There are some assumptions to make before we start:

  • The kernel has established where the root filesystem is at boot time and set up a special kernel structure called rootdir referencing the vnode that points to the root inode.

  • Inode 2 is the root inode of a filesystem.

  • The kernel has established at boot time a special kernel variable called rootvfs that references the top of the vnode structure.

  • Inode structures in memory are a superset of the inode structures stored on disk. Inodes in memory have indexing and other information that makes searching for them and finding them quicker.

  • If an inode is not in memory, the kernel will have to interface via the superblock (referenced through the vnode structure) to locate the inode on disk and read it into the inode cache in memory.

Figure 8-8 shows a summarized view of how walking through the filesystem would work.

  1. Locate the vnode for the root filesystem.

  2. We can then locate the inode for the root filesystem. This will be a directory. We hope that permissions will allow us to read further. The inode will reference the disk (dev=0x40000003 - major=0x40(=64) minor=0x000003 - vg00/lvol3) containing the data blocks for the directory. Reading the data blocks, we realize that the stand entry is inode 7.

  3. We can index through the inode cache looking for an inode from the same device but with inode 7.

  4. Eventually locating the inode, we discover that this is also a directory. Whenever we discover a directory, we need to make sure that it is not a mountpoint for a filesystem.

  5. Referencing back to the vnode, we realize that this is a mountpoint (vfsmountedhere references back to a valid vfs structure).

  6. We now know which device is the mountpoint for our new filesystem. We now have a new device ID (dev=0x40000001 = vg00/lvol1) to index through the inode cache.

  7. We eventually find an HFS inode = 2 for our new device ID. It is a directory, and we have permission to read.

  8. Reading the directory blocks, we realize the inode for the system entry is inode 16.

  9. We can index through the inode cache looking for inode = 16 dev =0x40000001. Locating the inode, we have permission to read.

  10. The inode tells us that this is a regular file. We analyze the block pointers in the inode to get to the data blocks. We eventually get to our data.

Figure 8-8. Walking through the filesystem.
graphics/08fig08.gif

All in the blink of an eye.

Do we need to know or understand the vagaries of this process? No, we don't. What we need to appreciate is that every time we perform long directory searches and set up a multitude of symbolic links all over the place , we are asking the kernel to do a considerable amount of work. Making life easier for the kernel with simple measures like shorter directory paths can recoup benefits for overall system health and performance.



HP-UX CSE(c) Official Study Guide and Desk Reference
HP-UX CSE(c) Official Study Guide and Desk Reference
ISBN: N/A
EAN: N/A
Year: 2006
Pages: 434

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net