09/03 Lecture Followup

For the curious, here are the demos from today's lecture:

Calling a the getpid system call, with or without wrappers: demo0.c

Virtualization of CPU and Memory: demo1.c

Concurrency done wrong: demo2.c

Persistence: demo3.c

If you want to redo the crash experiment I did in class, you need to learn a bit about mounting file systems in Linux. Even if you have multiple disks, they all appear in the same file-system tree. Extra disks are often mounted under "/mnt".

Let's say I bought a new computer with a fast SSD for most work, and a large hard drive for backing up movies. On Linux, I can find different devices under "/dev". So perhaps "/dev/sda1" is a partition on my flash SSD and "/dev/sdb1" is a partition on my hard drive. I can format and mount these devices (see how). I could mount the SSD as my root file system at "/" and my hard drive at "/mnt/movies". Now, if I save a file as /a/b/c, it will be saved on the SSD, and if I save a file as /mnt/movies/movie1.mp4, it will be saved on the hard drive.

In the demo, I created a file system on top of a fake disk (i.e., a file). I created a large file called disk.img, and then ran "mkfs.ext4 disk.img". mkfs.ext4 normally creates file systems on top of a real disk (like /dev/sda1), but we're tricking it into creating a file system within a file.

How is this useful? Well, we can read disk.img at any time to see what ext4 would have saved to disk (if it were actually running on a real disk). Therefore, if we make a copy of disk.img, we can record what state we would have ended up with on disk if there had been a sudden power loss. If we unmount the disk.img, and mount the crash copy, we can see what files ext4 would have been able to recover after the crash.

I'm happy to answer any questions about this, but don't worry if you're confused! We'll be spending over a third of the semester talking about file systems, and you aren't expected to understand everything on the first day.