Persistence tests

Step by step walkthrough
Running individual persistence tests
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.

```
 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.
```
 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.
```
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.
```
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.
```
rm -f tmp.dsk
```
This deletes tmp.dsk so 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 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.

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

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.

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
```
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 debugpintos command, 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 tar program you can do so by running the loadusersymbols tests/filesys/extended/tar command, and setting the breakpoint to the line you are interested in debugging.
Once you have set your breakpoints, you can continue the debugging session so you can start debugging the persistence test.
```
(gdb) continue
```

Persistence tests

Table of contents

Step by step walkthrough

Running individual persistence tests

Using GDB with persistence tests