0% found this document useful (0 votes)
9 views46 pages

Lecture 4

Uploaded by

cetdocteurhehe
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
9 views46 pages

Lecture 4

Uploaded by

cetdocteurhehe
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 46

CS111, Lecture 4

Unix V6 Filesystem, Continued

Optional reading:
Operating Systems: Principles and Practice (2nd Edition): Sections 13.1-13.2

😷 masks strongly This document is copyright (C) Stanford Computer Science and Nick Troccoli, licensed under

recommended
Creative Commons Attribution 2.5 License. All rights reserved.
Based on slides and notes created by John Ousterhout, Jerry Cain, Chris Gregg, and others.
NOTICE RE UPLOADING TO WEBSITES: This content is protected and may not be shared, 1
uploaded, or distributed. (without expressed written permission)
Topic 1: Filesystems - How can
we design filesystems to manage files
on disk, and what are the tradeoffs
inherent in designing them? How
can we interact with the filesystem in
our programs?
2
CS111 Topic 1: Filesystems
Key Question: How can we design filesystems to manage files on disk, and what are
the tradeoffs inherent in designing them? How can we interact with the filesystem in
our programs?

Filesystems Filesystem
Case study: Unix
introduction and System calls and Crash recovery
V6 Filesystem
design file descriptors

Lecture 2 Lecture 3 / Today Lecture 5 Lectures 6-7

assign1: implement portions of the Unix v6 filesystem!

3
Learning Goals
• Explore the design of the Unix V6 filesystem
• Understand the design of the Unix v6 filesystem in how it represents
directories
• Practice with the full process of going from file path to file data

4
Plan For Today
• Recap: the Unix V6 Filesystem so far
• Practice: doubly-indirect addressing
• Directories and filename lookup
• Practice: filename lookup

5
Plan For Today
• Recap: the Unix V6 Filesystem so far
• Practice: doubly-indirect addressing
• Directories and filename lookup
• Practice: filename lookup

6
Unix V6 Filesystem
Every file has an associated inode. An inode has space for up to 8 block
numbers for file payload data, and this block number space is used differently
depending on whether the file is “small mode” or “large mode”

if ((inode.i_mode & ILARG) != 0) { // file is “large mode”

7
Small File Scheme
If the file is small, i_addr stores direct block numbers: numbers of blocks that
contain payload data.
index 0 1 2 3 4 5 6 7

i_addr 341 33 124 … … … … …

Block 341 Block 33 Block 124 To know how many of


the 8 numbers are
File File File used, we can look at the
Part 0 Part 1 Part 2 size stored in the inode.
8
Large File Scheme
If the file is large, the first 7 entries in i_addr are singly-indirect block numbers
(block numbers of blocks that contain direct block numbers). The 8th entry (if
needed) is a doubly-indirect block number (the number of a block that contains
singly-indirect block numbers).
index 0 1 2 3 4 5 6 7

i_addr 444 22 34 792 168 976 2467 555

Block 444 Block 555 Block 1352 Block 126 Block 897
126, 98, 70, 127, 1352, 567, … 897, 4356, 6791,
1252, … …
File Part File Part
0 … 1,792 …
9
Large File Scheme
Another way to think about it: a file can be represented using at most 7 + 256 =
263 singly-indirect blocks. The first seven are stored in the inode. The
remaining 256 are stored in a block whose block number is stored in the inode.

index 0 1 2 3 4 5 6 7

i_addr 444 22 34 792 168 976 2467 555

Block 444 Block 555 Block 1352 Block 126 Block 897
126, 98, 70, 127, 1352, 567, … 897, 4356, 6791,
1252, … …
File Part File Part
0 … 1,792 …
10
Large File Scheme
An inode for a large file stores 7 singly-indirect block numbers and 1 doubly-
indirect block number. What is the largest file size this supports? Each block
number is 2 bytes big.

(7+256) singly-indirect block numbers total x


256 block numbers per singly-indirect block x
512 bytes per block
= ~34MB

11
Large File Scheme
An inode for a large file stores 7 singly-indirect block numbers and 1 doubly-
indirect block number. What is the largest file size this supports? Each block
number is 2 bytes big.

OR:
(7 * 256 * 512) + (256 * 256 * 512) ~ 34MB
(singly indirect) + (doubly indirect)

Better! still not sufficient for today's standards, but perhaps in 1975. Moreover,
since block numbers are 2 bytes, we can number at most 216 - 1 = 65,535 blocks,
meaning the entire filesystem can be at most 65,535 * 512 ~ 32MB.
12
Inodes
• Files only use the block numbers they need (depending on their size)
• Note: doubly-indirect is useful (and there are many other possible designs!),
but it means even more steps to access data.

13
Plan For Today
• Recap: the Unix V6 Filesystem so far
• Practice: doubly-indirect addressing
• Directories and filename lookup
• Practice: filename lookup

14
Doubly-Indirect Addressing
What is the smallest file size (in bytes) that would require using the doubly-
indirect block to store its data?

Respond on PollEv: pollev.com/cs111fall23


or text CS111FALL23 to 22333 once to join.
15
16
Doubly-Indirect Addressing
What is the smallest file size (in bytes) that would require using the doubly-
indirect block to store its data?

Files up to (7 * 256 * 512) bytes are representable using just the 7 singly-
indirect blocks. Files of (7 * 256 * 512) + 1 or more bytes would need the
doubly-indirect block as well.

17
Doubly-Indirect Addressing
Assume we have a the following inode. How do we find the block containing the
start of its payload data? How about the remainder of its payload data?
Inode 16: Step 1: Go to block 26 and read block numbers.
• ”large mode” For the first number, 80, go to block 80 and read
• size = 18,855,234 the beginning of the file (the first 512 bytes).
• i_addr = [26,35,32,50,58,22,59,30] Then go to block 41 for the next 512 bytes, etc.

Block # … 2 … 26 … 30 … 80 … 87 … 89

80,41,82,85, 87,114,47,48, It was the best 89,448,234,99, “My father,”


103, 24,45,… 122,99,111, of times, it … exclaimed
Inode 543,… was the worst Lucie, “you
Block
… table … … … of times… … … are ill!”
contents
start

18
Doubly-Indirect Addressing
Assume we have a the following inode. How do we find the block containing the
start of its payload data? How about the remainder of its payload data?
Inode 16: Step 2: After 256 blocks, go to block 35, repeat
• ”large mode” the process. Do this a total of 7 times, for blocks
• size = 18,855,234 26, 35, 32, 50, 58, 22, and 59, reading 1792
• i_addr = [26,35,32,50,58,22,59,30] blocks.

Block # … 2 … 26 … 30 … 80 … 87 … 89

80,41,82,85, 87,114,47,48, It was the best 89,448,234,99, “My father,”


103, 24,45,… 122,99,111, of times, it … exclaimed
Inode 543,… was the worst Lucie, “you
Block
… table … … … of times… … … are ill!”
contents
start

19
Doubly-Indirect Addressing
Assume we have a the following inode. How do we find the block containing the
start of its payload data? How about the remainder of its payload data?
Inode 16: Step 3: Go to block 30, which is a doubly-
• ”large mode” indirect block. From there, go to block 87, which
• size = 18,855,234 is an indirect block. From there, go to block 89,
• i_addr = [26,35,32,50,58,22,59,30] which is the 1793rd (256*7 + 1) block.

Block # … 2 … 26 … 30 … 80 … 87 … 89

80,41,82,85, 87,114,47,48, It was the best 89,448,234,99, “My father,”


103, 24,45,… 122,99,111, of times, it … exclaimed
Inode 543,… was the worst Lucie, “you
Block
… table … … … of times… … … are ill!”
contents
start

20
Plan For Today
• Recap: the Unix V6 Filesystem so far
• Practice: doubly-indirect addressing
• Directories and filename lookup
• Practice: filename lookup

21
Now we understand how files
are stored. But how do
we find them?

22
The Directory Hierarchy
Filesystems usually support directories ("folders")
• A directory can contain files and more directories
• A directory is a file container. It needs to store information about what
files/folders are contained within it.
• On Unix/Linux, all files live within the root directory, "/"
• We can specify the location of a file via the path to it from the root directory
(“absolute path”):

/classes/cs111/index.html

Common filesystem task: given a filepath, get the file's contents.


23
Directories
Key idea: Unix V6 directories are what map filenames to inode numbers in the
filesystem. Filenames are not stored in inodes; they are stored in directories.
Thefore, file lookup must happen via directories.

A Unix V6 directory contains an unsorted list of 16 byte “directory entries”. Each


entry contains the name and inode number of one thing in that directory.
23 myfile.txt
struct direntv6 {
54 song.mp3
uint16_t d_inumber;
char d_name[14]; 1245 otherFolder
};

24
Directories
Unix V6 directories contain lists of 16 byte “directory entries”. Each entry
contains the name and inode number of one thing in that directory.
• The first 14 bytes are the name (not necessarily null-terminated!)
• The last two bytes are the inumber

23 myfile.txt
struct direntv6 {
54 song.mp3
uint16_t d_inumber;
char d_name[14]; 1245 prez.pptx
};

25
How can we use this
directory representation to
translate from a filepath to
its inode number?
26
The Lookup Process

/classes/cs111/index.html

Start at the
root directory

27
The Lookup Process

/classes/cs111/index.html

In the root
directory,
find the
entry named
"classes".
28
The Lookup Process

/classes/cs111/index.html

In the "classes"
directory, find
the entry
named "cs111".

29
The Lookup Process

/classes/cs111/index.html

In the "cs111"
directory, find the
entry named
"index.html". Then
read its contents.
30
Directories
How can we store directories on disk?
• Directories store directory entries – could be many entries
• Directories also have associated metadata (size, permissions, creation date, …)

Key idea: let’s model a directory as a file. We’ll pretend it’s a “file” whose
contents are its directory entries! Each directory will have an inode, too.
Key benefit: we can leverage all the existing logic for how files and inodes work,
no need for extra work or complexity!

• Inodes can store a field telling us whether something is a directory or file.


• Directories can be “small mode” or “large mode”, just like files
31
The Lookup Process
The root directory ("/") is set to have inumber 1. That way we always know
where to go to start traversing. (0 is reserved to mean "NULL" or "no inode").

32
The Lookup Process

/classes/cs111/index.html

Go to inode with
inumber 1 (root
directory).

33
The Lookup Process

/classes/cs111/index.html

In its payload data,


look for the entry
“classes” and get
its inumber. Go to
that inode.
34
The Lookup Process

/classes/cs111/index.html

In its payload
data, look for
the entry
“cs111” and get
its inumber. Go
to that inode. 35
The Lookup Process

/classes/cs111/index.html

In its payload data,


look for the entry
“index.html” and get
its inumber. Go to that
inode and read in its
payload data. 36
Plan For Today
• Recap: the Unix V6 Filesystem so far
• Practice: doubly-indirect addressing
• Directories and filename lookup
• Practice: filename lookup

37
Ex.: Finding “/local/files/fairytale.txt”
(small file)
1. go to inode 1. It's small.
We need to look in block
25 for the list of its entries.

2. Look in block 25 for


32 33 34

"local" -> inode 16.


2

3. Go to inode 16. It's


32 small. We need to look in
32
blocks 27/54 for the list of
its entries.

38
Ex.: Finding “/local/files/fairytale.txt”
(small file)
4. Look in block 27 for
"files" (and then 54 if
necessary) -> inode 32.

5. Go to inode 32. It's


32 33 34

small. We need to look in


2
block 32 for the list of its
entries.
32

32
6. Look in block 32 for
"fairytale.txt" -> inode 47.

39
Ex.: Finding “/local/files/fairytale.txt”
(small file)
7. go to inode 47. It's
small. We need to look in
blocks 80,89,87 in order for
its 1,057 bytes of payload
data.
32 33 34

32

32

40
Ex.: Finding “/medfile” (large file)
1. go to inode 1. It's small.
We need to look in block
25 for the list of its entries.

2. Look in block 25 for


32 33 34

2
"medfile" -> inode 16.

3. Go to inode 16. It's


large. We need to look in
block 26 for the first 256
payload block numbers.

41
Ex.: Finding “/medfile” (large file)
4. Read through numbers
in block 26. First, go to
block 80 for the first 512
payload bytes. Then, go to
block 87 for the second 512
32 33 34

2
payload bytes.

5. After doing this 256


times, go to block 30 and
repeat. Then continue with
all remaining singly-indirect
blocks in the inode.
42
Ex.: Finding “/largefile” (large file)
Question: What is the
number of the block that
stores the first 512 bytes of
largefile?
32 33 34

43
Ex.: Finding “/largefile” (large file)
1. go to inode 1. It's small.
We need to look in block
25 for the list of its entries.

2. Look in block 25 for


32 33 34

2
"largefile" -> inode 16.

3. Go to inode 16. It's


large. For the first seven
block numbers, go to those
blocks and read their 256
block numbers to get
payload blocks. 44
Ex.: Finding “/largefile” (large file)
4. For the eighth block, go
to block 30. For each block
number, go to that block
and read in its block
numbers to get payload
32 33 34

2
blocks.

First payload block number


= 80.

45
Recap
• Recap: the Unix V6 Filesystem so far Lecture 4 takeaway: The
• Practice: doubly-indirect addressing Unix V6 Filesystem
• Directories and filename lookup represents directories as
• Practice: filename lookup files, with payloads
containing directory entries.
Lookup begins at the root
directory for absolute paths.

Next time: how do we interact with the


filesystem in our programs?
46

You might also like