Project 4 Mechanics 

Fetch a New VMWare Machine

We'll be using a new VMWare machine for this project. It differs from the previous one in that:

• It is configured with two disks. One is a normal (ext3) file system, just as before. The other has a single partition that will be used for your cse451fs file system.
• The disks are persistent -- whatever you write to them will be there when you reboot.

Persistence should make your work a little easier, since you won't have to reformat your file system each time you boot. It's unlikely that anything you do in this project will corrupt the main file system (the one that must be intact to be able to boot), but if it does you can always just refetch the original VMWare machine.

The new machine is at forkbomb:/cse451/projects/FC4-451-2Disk.tar.bz2. It should be loaded on lab PCs. Make sure that when you load the config file for VMWare you're using the file in the directory called FC4-451-2Disk!

Set Up Your (Kernel and mkfs) Build Environments

The code we're using is the same as the code from Project 1. However, some configuration (build) options have been changed to make debugging easier, among other things. Here's what you should do to get started:

• Fetch the Linux source and un-tar into your forkbomb project space. The source is at forkbomb:/cse451/projects/linux-2.6.13.2-cse451fs.tar.bz2.
• Get a copy of the cse451 file system starter code: forkbomb:/cse451/projects/projFS.tar.gz. Unpack it into some backed up directory accessible from your forkbomb account (e.g., your home directory (which for me is /homes/iws/ak). The directory projFS will be created, with subdirectories mkfs and cse451_2.6.
• cd into linux_2.6.13/fs and create a symbolic link (man ln - you want the -s switch) named cse451fs to wherever you've located your cse451_2.6 directory.
• Now you need to make the Linux kernel, the cse451fs file system module, and mk451fs. For the former, cd to your Linux source topmost directory and say make. For the latter, cd into the mkfs directory and say make.

Try Out the cse451fs File System

• Get VMWare up and running with the kernel you built. (See Project 1 if you don't remember how.)
• Copy some files to the VMWare machine:
  • scp the mk451fs executable to the VMWare machine. (By default, it'll end up in root's home directory (/root), which is fine.) [This step is not necessary if you've compiled mk451fs on the virtual machine.]
  • scp the file cse451fs.ko, which should be in your cse451_2.6 directory, to /lib/modules/2.6.13.2/ on the VMWare machine.
• Login to the VMWare machine and run the command depmod.
• Okay, at this point you're ready to try out the (skeleton) file system.
  • Run mk451fs. That will reformat the partition we're using, which is called /dev/hdb1. (Note that this wipes out any files that might exist on it. You need to run mk451fs only if you've corrupted the file system, but I'm listing this step here for completeness. You can safely run it at this point, or any point.)
  • Now mount the file system. This command will do:

    mount -t cse451fs /dev/hdb1 fsmount

    That will cause the cse451fs module to be loaded into the kernel, and will attach the root of /dev/hdb1 to the directory named fsmount.
  • cd into fsmount and create some files. These are cse451fs files.
  • dmesg | tail -n 40 will show you the kind of debugging output that is being printed by the skeleton code.

Working More Efficiently

Here are some points that might help:

• mk451fs can be used to examine something like the raw disk contents for your file system. Try mk451fs --help for documentation.
• There are Unix commands that will do a probably less useful version of the same thing -- the Unix commands don't know anything about the cse451fs file system layout, though, so just dump hex, not the nicely annotated information provided by mk451fs. For example, hexdump -n 9192 /dev/hdb1/ and xxd -s 1024 -l 1024 /dev/hdb1 | less.
• The root account on the VMWare machine has an ssh key already set up. To use it, you need the private key. Copy forkbomb:/cse451/projects/vmware_id_rsa to some directory you like to work in. (See the next point.)
• You should use a script to help move files from hither to yon, which you'll be doing a lot. Here's roughly what I used.

  #/bin/bash
  
  SCP="scp -i vmware_id_rsa"
  SSH="ssh -i vmware_id_rsa"
  
  scp forkbomb:/cse451/ak/projFS/mkfs/mk451fs .
  ${SCP} mk451fs root@192.168.93.2:
  rm mk451fs
  
  scp forkbomb:/cse451/ak/linux-2.6.13.2/fs/cse451fs/cse451fs.ko .
  ${SCP} cse451fs.ko root@192.168.93.2:/lib/modules/2.6.13.2
  rm cse451fs.ko
  
  ${SSH} root@192.168.93.2 depmod
  

  Note that it makes use of the vmware_id_rsa private key file.
• The command umount /dev/hdb1 unmounts the file system. (It must be unmounted to run mk451fs, for instance.)
• The command modprobe -r cse451fs unloads the cse451fs module. If you unload it, you can reload a newer version you've scp'ed over without having to reboot the machine. (That's assuming the old version hasn't caused some kind of fatal error, of course.)
• The Linux source configuration we're using has set switches that tell the kernel to try to continue running, even if things have gone horribly wrong. You might find that a fatal error has occured, and things start acting strange, even though you can create new shells and the like. Reboot...
• The script test.sh in root's home directory on the VMWare machine does a simple test of the cse451fs file system. Basically, it copies /usr/include/linux to it. It does this using a single cp command executing alone, and a number of them executing concurrently. It also does the exactly the same copying to /root, which is supported by ext3 and so presumably provides a definitive result. (Note that because of file size restrictions, the results the skeleton code gets are different from what ext3 gets.)

  Log files are written. Other things happen. As with all code, all details can be gleaned as necessary from the script itself.