File Systems — Inodes, Directories, File Operations
957 words
5 min read
Visual companion
Python
Type and operator map
Python Week 1: the first filter for runtime behavior
View
Revision summary
What this note is really saying
Short form
# File Systems — Inodes, Directories, File Operations ## 🎯 Learning Objectives - Explain the role of inodes in Unix file systems - Differentiate between contiguous, linked, and indexed allocation - Calculate maximum file size for indexed allocation schemes - Trace directory operations and path resolution - Compare...
File Systems — Inodes, Directories, File Operations
🎯 Learning Objectives
- Explain the role of inodes in Unix file systems
- Differentiate between contiguous, linked, and indexed allocation
- Calculate maximum file size for indexed allocation schemes
- Trace directory operations and path resolution
- Compare RAID levels 0, 1, 5, 6, 10
1. File Concepts
1.1 File Attributes
| Attribute | Description |
|---|---|
| Name | Human-readable identifier |
| Identifier | Unique file descriptor (inode number) |
| Type | Regular, directory, device, etc. |
| Location | Pointer to file data on disk |
| Size | Current file size |
| Protection | Read/write/execute permissions |
| Timestamps | Creation, access, modification times |
1.2 File Operations
cint fd = open("file.txt", O_RDWR); // Open file → returns file descriptor char buf[1024]; int n = read(fd, buf, 1024); // Read bytes int n = write(fd, buf, n); // Write bytes off_t pos = lseek(fd, 100, SEEK_SET); // Reposition file offset int ret = close(fd); // Close file
2. Directory Structure
2.1 Single-Level vs Tree-Structured
(Diagram)
2.2 Path Resolution
(Diagram)
3. Inodes (Index Nodes)
3.1 Intuition
An inode is the metadata structure for a file in Unix systems. It stores everything about a file except its name (which is stored in the directory).
3.2 Inode Structure
(Diagram)
Typical inode fields in ext2/ext3:
| Field | Bytes | Description |
|---|---|---|
| Mode | 2 | File type and permissions |
| UID | 2 | Owner user ID |
| Size | 4 | File size in bytes |
| GID | 2 | Group ID |
| Links count | 2 | Number of hard links |
| Blocks | 4 | Number of blocks |
| Timestamps | 4×3 | atime, mtime, ctime |
| Direct blocks | 12×4 | 12 direct pointers (48K @ 4KB blocks) |
| Single indirect | 4 | Points to block of block pointers |
| Double indirect | 4 | Points to block of indirect blocks |
| Triple indirect | 4 | Points to block of double indirect |
3.3 Maximum File Size Calculation
Given:
- Block size = 4KB (4096 bytes)
- Block pointer = 4 bytes
- Pointers per block = 4096 / 4 = 1024
| Level | Calculation | Size |
|---|---|---|
| Direct (12) | 12 × 4KB | 48 KB |
| Single indirect | 1024 × 4KB | 4 MB |
| Double indirect | 1024 × 1024 × 4KB | 4 GB |
| Triple indirect | 1024 × 1024 × 1024 × 4KB | 4 TB |
| Maximum file size | 48KB + 4MB + 4GB + 4TB | ~4 TB |
4. File Allocation Methods
4.1 Contiguous Allocation
File occupies consecutive blocks on disk.
| Pros | Cons |
|---|---|
| Fast sequential access | External fragmentation |
| Simple implementation | Need to know file size upfront |
4.2 Linked Allocation
Each block points to the next block.
| Pros | Cons |
|---|---|
| No external fragmentation | Very slow random access |
| Can grow dynamically | Link overhead, reliability |
4.3 Indexed Allocation
All block pointers are stored in an index block.
| Pros | Cons |
|---|---|
| Fast random access | Index block overhead for small files |
| No fragmentation | Maximum file size limited by index block |
5. Free Space Management
5.1 Bitmap
A string of bits where each bit represents a free block (1 = free, 0 = allocated).
pseudo111001010111...
| Pros | Cons |
|---|---|
| Very fast (single instruction test) | Must be in memory for efficiency |
| Simple | Wastes space for small bitmaps |
5.2 Free List
Linked list of free block addresses.
| Pros | Cons |
|---|---|
| No extra space overhead | Slower (traverse for allocation) |
| Works for any size | Fragmentation possible |
6. RAID
| Level | Description | Min Disks | Pros | Cons |
|---|---|---|---|---|
| RAID 0 | Striping (no redundancy) | 2 | Best performance | Any disk failure = data loss |
| RAID 1 | Mirroring | 2 | Best reliability (N-1 failures) | 50% capacity loss |
| RAID 5 | Striping + Parity | 3 | Good balance | Slow writes (parity calc) |
| RAID 6 | Striping + Dual Parity | 4 | Survives 2 disk failures | Even slower writes |
| RAID 10 | Mirror + Stripe | 4 | Fast + reliable | Expensive (50% loss) |
7. Common Pitfalls
Pitfall 1: Deleting an open file
In Unix, you can
rm a file while someone has it open. The file data isn't freed until all file descriptors are closed. The inode persists but the directory entry is removed (link count → 0).Pitfall 2: Hard links vs symbolic links
- Hard link: Same inode, different directory entry. Can't cross file systems.
- Symbolic link: Special file pointing to pathname. Can cross file systems.
Pitfall 3: Inode exhaustion
Creating many tiny files exhausts the fixed inode table even if plenty of disk space remains.
8. 📝 Practice Questions
Q1: Calculate the maximum file size for a system with 1KB blocks, 4-byte pointers, and the same 12 direct + indirect scheme.Answer:
- Direct: 12 × 1KB = 12KB
- Single: (1024/4) × 1KB = 256 × 1KB = 256KB
- Double: 256 × 256 × 1KB = 256 × 256KB = 64MB
- Triple: 256 × 256 × 256 × 1KB = 256 × 64MB = 16GB
- Max: 12KB + 256KB + 64MB + 16GB ≈ 16.06GB Q2: What is stored in an inode vs what is stored in a directory entry?
Answer: Inode stores metadata (permissions, timestamps, block pointers). Directory entry stores just the name and inode number. The inode doesn't know its filename! Q3: Why does RAID 5 have a "write penalty"?Answer: A single write requires: read old data, read old parity, write new data, write new parity = 4 I/O operations for 1 write. This is the "RAID 5 write penalty." Q4: Explain why symbolic links can cross file systems but hard links cannot.Answer: Hard links share the same inode number, which is unique only within a single file system. Symbolic links store a pathname string, which can reference any file accessible through the namespace. Q5: A file has 12 direct blocks, single, double, and triple indirect. Block size = 4KB. How many blocks needed to store a 5GB file?Answer: A 5GB file needs:
- 12 direct blocks = 48KB (0.01% of file)
- 1 single indirect block containing 1024 pointers → 4MB
- 1 double indirect block + 1024 indirect blocks → 4GB (via pointers)
- Triple indirect for the remaining ~1GB
9. 🔗 Cross-References
- Week 10 - I/O & Disk: How file system operations map to disk I/O
- Week 2 - xv6: File system implementation in xv6
- BSCS4024 (Computer Networks): Network file systems (NFS) Join Discord PreviousVirtual MemoryNextI/O & Disk Scheduling