Link Search Menu Expand Document

Persistence tests

Table of contents

  1. Step by step walkthrough
  2. Running individual persistence tests
  3. Using GDB with persistence tests

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 T.tar.

Step by step walkthrough

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 filesys/build/ directory.

  1.  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 tmp.dsk filename.

  2.  pintos-mkdisk tmp.dsk --filesys-size=2
    

    This creates a new disk image called tmp.dsk initialized with room for two files initially. Any persistence tests will contain at least two files.

  3. 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.dsk uses the existing tmp.dsk we created in step 2 as the disk image for the simulator. -p tests/filesys/extended/dir-mkdir -a dir-mkdir and -p tests/filesys/extended/tar -a tar copy over tests/filesys/extended/dir-mkdir and tests/filesys/extended/tar from your machine to the simulator and names them dir-mkdir and tar respectively. dir-mkdir is the executable of the test (i.e. the code that will run), and tar is the executable for the tar program. These are the two files which space was allocated for back when creating the new disk image.

  4. 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.dsk as the disk image.

    -g fs.tar -a tests/filesys/extended/dir-mkdir.tar will copy over fs.tar from the simulator to your machine and names it dir-mkdir.tar within the filesys/build/tests/filesys/extended directory. The fs.tar is created within the fsutil.c methods you may have encountered; it is the tar ball of the root directory after all the functionality of your test has run.

  5. rm -f tmp.dsk
    

    This deletes tmp.dsk so other tests will not use the same file.

  6. 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 tmp.dsk and 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.

Running individual persistence tests

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.

  1. Run pintos-test on the base test (i.e. without the *-persistence suffix) and make sure you pass it.

     pintos-test dir-mkdir
    
  2. 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
    

Using GDB with persistence tests

Again, we’ll use dir-mkdir test as an example.

  1. Run the usual command to debug the base test (i.e. without the *-persistence suffix) associated with the persistence test.
    PINTOS_DEBUG=1 pintos-test testname
    
  2. Enter the following commands to run the base test to completion.
    (gdb) debugpintos
    (gdb) continue
    

    Once you have run the above, after a short while you should see the message Remote connection closed.

    This signifies that the base test has finished running and the persistence test is now ready to be debugged. To debug the persistence test, run debugpintos and proceed debugging as usual.