Section 1: File Systems and System Calls

Sections Thu Oct 06 to Fri Oct 07

This section handout was designed by Jerry Cain. Compiled by Parthiv Krishna.

The first and third exercises are problem set-esque questions that could easily appear on a midterm or final exam. The second problem is an experiment that'll require you fire up your laptop and run some programs and development tools.

Section Overview

Your weekly section is a chance to experiment and explore, ask and answer questions, and get hands-on practice in a supported environment. We provide a set of section exercises that revisit topics from recent lectures and prepare you to succeed at the upcoming assignment.

Section is collaborative! We're all in this together! We will work together on the exercises. The entire group is one learning community working together to advance the knowledge and mastery of everyone. Stuck on an issue? Ask for help. Have an insight? Please share!

To track section participation, we have an online checkoff form for you to fill out as you work. Section is not a race to find answers to exactly and only the checkoff questions-- the checkoff questions are used only to record attendance and get a read on how far you got. Section credit is awarded based on your sincere participation for the full section period. Your other rewards for investing in section are to further practice your skills, work together to resolve open questions, satisfy your curiosity, and reach a place of understanding and mastery. The combination of active exploration, give and take with your peers, and the guidance of the TA makes section time awesome. We hope you enjoy it!

Get Started

Clone the section starter code by using the command below. This command creates a section1 directory containing the project files.

git clone /afs/ir/class/cs111/repos/lab1/shared section1

Next, pull up the online section checkoff and have it open in a browser so you can jot things down as you go.

Exercises

1) Direct, Singly Indirect, and Doubly Indirect Block Numbers

Assume blocks are 512 bytes in size, block numbers are four-byte ints, and that inodes include space for 6 block numbers. The first three are direct block numbers, the next two are singly indirect block numbers, and the final one is a doubly indirect block number.

  • What's the maximum file size?
  • How large does a file need to be before the relevant inode requires the first singly indirect block number be used?
  • How large does a file need to be before the relevant inode requires the first doubly indirect block number be used?
  • Draw as detailed an inode as you can if it's to represent a regular file that's 2049 bytes in size.

2) valgrind and orphaned file descriptors

Here's a very short exercise to enhance your understanding of valgrind and what it can do for you. To get started, go into your section1 directory and compile the provided program. Now open the code file and trace through the code to keep tabs on what file descriptors are created, properly closed, and orphaned.

With this information, try tracing through the program to better understand the file descriptors that are created, closed, and left open. In particular, with the knowledge that open will use the lowest unused file descriptor, calculate the actual file descriptor numbers. Then run valgrind ./open-fds to confirm that there aren't any memory leaks or errors (how could there be?), but then run valgrind --track-fds=yes ./open-fds to get information about the file descriptors that were (intentionally) left open.

Note: if you're SSHing via VSCode, you may see file descriptors other than the ones in this program being used, since VSCode uses some file descriptors as part of connecting to myth. You can ignore those (e.g. sometimes it's file descriptors 19, 20, 21 or 99). To confirm what file descriptors you're seeing may be part of VSCode, try logging in to myth directly via a terminal program and run valgrind through there to see what file descriptors are open.

Without changing the logic of the program, insert as many close statements as necessary so that all file descriptors (including 0, 1, and 2) are properly donated back. (In general, you do not have to close file descriptors 0, 1, and 2, but for this problem you should.)

3) Unix V6 Filesystem

  • Consider the Unix V6 filesystem, which uses 512-byte blocks and 32-byte inodes. Which sector should we read in order to get inode 256? If that sector is an array of inodes,

    • which index should we go to in order to get inode 256?
    • What about inode 345?

  • Unlike the Unix V6 filesystem we learned about in class, the ext2/3/4 family of filesystems (commonly used on Linux) use variable-length directory entries: 

struct ext3_dir_entry { 
    uint32_t inode_number; 
    uint16_t name_length; 
    uint16_t file_type; 
    char[] file_name; 
};

What is the benefit to designing directory entries this way? What are some drawbacks? (Consider what happens when deleting files.)

  • Explain what happens when you type cd .././../. at the shell prompt. Frame your explanation in terms of the Unix V6 filesystem. Assume that the inode number of the current working directory is the only relevant global variable maintained by your terminal.