Filesystem Debugging
At this stage, it is considered good practice to check the filesystem on the PC. We used the standalone utilities (/boot, /stand/cat, /stand/ls, /stand/icheck) to verify that the filesystem was correct for use with the kernel. However, even before having an operational system, we can validate our filesystem with our standalone system (see "Initial Utilities: The Standalone System," DDJ, March 1991), because it has the ability to interpret the filesystem data structures. /boot can be used to check for the presence of files and directories by attempting to boot from a file. For example, one can try to boot from /stand/ls, with the proviso that "/" be a directory that has the "stand" directory in it, and that "stand", in turn, contain "ls"--an executable file. If the given file cannot be opened, /boot will tell us why. ls, like its user-mode utility counterpart, lists the contents of a directory on a disk, so we can check to see if the contents are correct. Similarly, cat shows the contents of an ASCII file, so we can check to see that the ASCII files present have the appropriate contents and that fence-post or data translation problems have not corrupted the files. Finally, /stand/ icheck, the largest standalone program, can exhaustively check for filesystem consistency to make certain that all of the filesystems' data structures are undamaged. We can verify this by running the same icheck program on the cross-host, ensuring that the filesystem is identically consistent on both the cross-host and the target system.
These validation techniques independently test file contents separate from file system data structures, or "meta data," on the off-chance that we are somehow corrupting the contents of files when we create the filesystem. It's important to realize that programs that check the filesystem have no way to check contents of files. Thus, the file contents may be completely mangled in ways that could still leave the filesystem in a correct state!
|
|