Until now, each test invoked Pintos just once. However, an important purpose of a file system is to ensure that data remains accessible from one boot to another. Thus, the Project 3 file system tests invoke Pintos twice. During the second invocation, all the files and directories in the Pintos file system are combined into a single file (known as a tarball), which is then copied from the Pintos file system to the host (i.e. your development VM) file system.
The grading scripts check the file system’s correctness based on the contents of the file copied out in the second run. This means that your project will not pass any of the extended file system tests labeled
*-persistence until the file system is implemented well enough to support
tar, the Pintos user program that produces the file that is copied out. The
tar program is fairly demanding (it requires both extensible file and subdirectory support), so this will take some work. Until then, you can ignore errors from
make check regarding the extracted file system.
Incidentally, as you may have surmised, the file format used for copying out the file system contents is the standard Unix
tar format. You can use the Unix
tar program to examine them. The tar file for test
T is named
To debug persistence tests, you must first understand what is exactly going on. Let’s use the
dir-mkdir test as an example to walk through how a persistence tests works.
When you run
pintos-test dir-mkdir from the
filesys/ directory, you’ll notice several commands that are run. Keep in mind while you run the
pintos-test commands from the
filesys/ directory, the following commands (if run individually) should be run in the
rm -f tmp.dsk
We make sure to delete any remaining disk files if by some off chance it was left behind by another test because all tests use the
pintos-mkdisk tmp.dsk --filesys-size=2
This creates a new disk image called
tmp.dskinitialized with room for two files initially. Any persistence tests will contain at least two files.
pintos -v -k -T 60 --qemu --disk=tmp.dsk \ -p tests/filesys/extended/dir-mkdir -a dir-mkdir \ -p tests/filesys/extended/tar -a tar \ -- -q -f run dir-mkdir < /dev/null 2> \ tests/filesys/extended/dir-mkdir.errors > tests/filesys/extended/dir-mkdir.output
This boots up a simulator to run Pintos on. Other flags can be understood using
pintos –help, but they’re omitted for brevity.
--disk=tmp.dskuses the existing
tmp.dskwe created in step 2 as the disk image for the simulator.
-p tests/filesys/extended/dir-mkdir -a dir-mkdirand
-p tests/filesys/extended/tar -a tarcopy over
tests/filesys/extended/tarfrom your machine to the simulator and names them
dir-mkdiris the executable of the test (i.e. the code that will run), and
taris the executable for the tar program. These are the two files which space was allocated for back when creating the new disk image.
pintos -v -k -T 60 --qemu --disk=tmp.dsk \ -g fs.tar -a tests/filesys/extended/dir-mkdir.tar \ -- -q run 'tar fs.tar /' < /dev/null 2> \ tests/filesys/extended/dir-mkdir-persistence.errors \ > tests/filesys/extended/dir-mkdir-persistence.output
This tests the persistence tests. We use the same
tmp.dskas the disk image.
-g fs.tar -a tests/filesys/extended/dir-mkdir.tarwill copy over
fs.tarfrom the simulator to your machine and names it
fs.taris created within the
fsutil.cmethods you may have encountered; it is the tar ball of the root directory after all the functionality of your test has run.
rm -f tmp.dsk
tmp.dskso other tests will not use the same file.
perl -I../.. ../../tests/filesys/extended/dir-mkdir.ck \ tests/filesys/extended/dir-mkdir tests/filesys/extended/dir-mkdir.result
This provides you with some test output of the entire test.
As a result, you can run each of these commands individually instead of running
pintos-test all at once. In between, you may benefit from examining files after running each step, mainly the
dir-mkdir.tar. While you could
tar dir-mkdir.tar to examine this, you may run into issues if you have functionality issues in inode. To examine these files as binary or ASCII, you can use
hexedit (you may need to install using
sudo apt install hexedit) or the Hex Editor extension on VS Code.
Here is a faster way of running persistence tests manually without running make check every time. Again, we’ll use
dir-mkdir test as an example.
pintos-teston the base test (i.e. without the
*-persistencesuffix) and make sure you pass it.
Then run the following.
cd build perl -I../.. ../../tests/filesys/extended/dir-mkdir-persistence.ck \ tests/filesys/extended/dir-mkdir-persistence \ tests/filesys/extended/dir-mkdir-persistence.result
Again, we’ll use
dir-mkdir test as an example.
- Run the usual command to debug the base test (i.e. without the
*-persistencesuffix) associated with the persistence test.
PINTOS_DEBUG=1 pintos-test testname
- Enter the following commands to run the base test to completion. These commands will allow you to debug your persistence tests by running the test to completion and going into the persistence tests.
(gdb) continue (gdb) debugpintos
After running the
debugpintoscommand, you should add the breakpoints in the functions that you are interested in debugging for the persistency tests. At this point if you want to add a breakpoint to the
tarprogram you can do so by running the
loadusersymbols tests/filesys/extended/tarcommand, and setting the breakpoint to the line you are interested in debugging.
- Once you have set your breakpoints, you can
continuethe debugging session so you can start debugging the persistence test.