Skip to main content
Link
Menu
Expand
(external link)
Document
Search
Copy
Copied
Search cs492-stevens
Lectures
Lecture 35 File Systems Template
35 -
Outline
File Allocation
Recap: Addressing
Contiguous Allocation
Linked List Allocation
File Allocation Table
Indexed Allocation (Inodes)
Inode Indirection
Exercise
Announcements
Directories
Reading:
File Allocation
Contiguous
Linked List
File Allocation Table (FAT)
Indexed (Inodes)
Directories
Each file occupies a contiguous disk blocks
Each file is a linked list of blocks
Requires at least 2 disk accesses:
Translation from file offset:
Pros:
Cons:
a file is defined by a starting block address
and the number of blocks in the file
directory stores first and last block address
blocks can be scattered across the disk
(start and size stored in directory)
block
address
block
offset
1)
a)
b)
c)
d)
2)
MOS 4.1 - 4.2; 4.3.1 - 4.3.3; 4.3.7
Quiz 4 this Friday
Create your project groups on Canvas.
Please try to do this by Today.
File Systems
Disk (Block Device)
File Data
logical
block
kernel block
0
0
1
N
1
2
M
...
...
file offset
block address/number/index
block offset
logical block address/number/index
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
allocation in blocks (regardless of file size)
first bytes of block contain pointer to next
1 to read starting block from directory block
1 to read starting block from directory block
each table entry corresponds to a disk block
entry contains pointer to next block or -1
load table from disk on startup and periodically
write back
index node (inode) keeps block indexes along
with file metadata/attributes
directory only needs to map name to inode
Simple to implement
Space inefficiency
File growth
Good performance on access
only store start block # and # of blocks
external fragmentation / compaction, etc.
files can't grow into other files
entire file can be read sequentially
1 to access data at block address
Q accesses to traverse Q blocks
MOS Figure 4-12
file offset
starting
block address
file offset
block size
block size
=
+
=
%
MOS Figure 4-13
Translation from file offset:
Requires many accesses:
We can improve the random access time with RAM!
Keep the pointers in a separate table in memory
instead of in blocks
Avoid traversal by creating data structure for
each file that holds pointers to file's data blocks
blocks to
traverse
file offset
block size - pointer size
=
block
offset
file
offset
block
size
pointer
size
pointer
size
=
%
-
+
account for the pointer at the
beginning of the block
1
3
5
7
9
11
2
4
6
8
10
12
file A start
Pros:
Cons:
-
-
-
Simple to implement
Inefficient random access
Efficient space usage
only stores the starting address
traverse linked list on every access
easy to grow files, no wasted space
MOS Figure 4-14
1
3
5
7
9
11
2
4
6
8
10
12
file A start
Translation from file offset:
Access performance:
Access performance:
Inodes are the implementation of choice for many
operating systems, including Linux's ext4 and
Windows NTFS
Inode entries are pointers:
Max file size grows exponentially with indirection!
Exact inode structure depends on file system
A file system's inode looks like the following:
Disk blocks are 1 kB.
What is the maximum file size in this system?
Directories map file names to:
As mentioned, these can be in-band or out-of-band
Directory file's contents are entries
block to
traverse
block
offset
file offset
file offset
block size
block size
=
=
%
Don't need to account for pointer anymore
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
1 read to disk for starting block from directory
1 read to disk to get inode # from directory
directly to data blocks
(direct)
(contiguous allocation)
(linked list / FAT)
(indexed allocation)
format of the entry can vary by file system
start block of file
start block of file
inode number of file
(singly indirect)
(doubly indirect)
etc.
on Linux, to see inodes
how do we find a file?
root has a special inode number (0, 1, 2)
inodes can span multiple blocks
lookup is simple
walk down chain of inodes by searching for path
components
Resolving a file from a path starts from root.
finding a file
finding an inode
Recall the disk layout
Keep all inodes in a dedicated region as an array
how do we find an inode?
to blocks of pointers to
data blocks
to blocks of pointers of
blocks of pointers to
data blocks
1 access to disk for data
1 access to disk for data
Q accesses to RAM to find block number
1 read to disk for reading inode index table
Pros:
Cons:
-
-
-
Same advantages as FAT
Entire table stored in RAM
Faster random access time
simple, efficient space usage
1 table entry per block is infeasible for very
large disks (256 GB - 5 TB)
Used on old DOS systems (smaller disks back
then), still used on some USB flash drives and
UEFI partitions
RAM is much faster to read than disk
MOS Figure 4-15
inodes
blocks
data
blocks
Translation from file offset:
file block
index
block
address
block
offset
file offset
inode.blocks[file_block_index]
file offset
block size
block size
=
=
=
%
Pros:
Cons:
-
-
-
-
Efficient random access
Supporting large files
Lower RAM overhead than FAT
Efficient space usage
Limited by inode table entries, but we can get
around this with indirection
block_t *
block_t **
block_t ***
MOS Figure 4-35
direct pointers to data blocks
ls -i
struct inode {
struct attributes; // not important
uint64_t direct[10];
uint64_t indir1[2];
}
df -i
file
file
file
foo
foo
foo
12
23
19
10
17
start
start
inode
length
end
MOS Figure 4-16
MOS Figure 4-32
Example: original FAT (MS-DOS)
Navigation
Example: UNIX Inodes
later extended with 2 more bytes in FAT32
for larger block addresses as disks got
bigger
metadata
root
2
inode
2801
inode
2859
data
directory
inode
directory
data block
(directory entries)
filenames
filenames
filenames
foo.txt
bin
bashrc
45686
27755
45686
204819
3
27961
1048829
2801
2859
8729
2126048
8820
10833
bar
dev
hosts
baz.c
etc
passwd
dir1/
home
dir2/
usr
inode
inode
inode
map file names to inode numbers
2 questions:
Example: /etc/passwd
Super
block
Free Space
Mgmt.
Inodes
Root
Dir
Files & Directories