File Fat Systsems

Question 1

Virtual File-system

Answer 1

Common interface hides– File-system differences

Question 2

Shared Files

Answer 2

If we allow multiple links to a file: Supporting links to directories
would allow loops
* Processes scanning
directories might get
trapped
* Not generally allowed

Question 3

Common File Attributes

Answer 3

• Name
• Unique Identifier
• File type
• Location
• Size
• Access Control Lists/ Flags
• Time and Date (accessed, modified, …)
• Ownership (user/ group)

Question 4

Common File System Operations

Answer 4

• Create
• Open
• Read
• Write
• Seek
• Close
• Link
• Unlink

Question 5

Contiguous Allocation(File allocation)

Answer 5

Each file fills set of adjacent disk blocks in filesystem
Each process is allocated a single continuous block of memory.
Key Points:
Simple & fast: Easy to implement and access.

Base + Limit registers used for protection.

Drawback: Can lead to external fragmentation (small unused holes between blocks).

Hard to grow: If a process needs more memory, it might need to move.

Question 6

Linked-List Allocation

Answer 6

Avoids external fragmentation problem as Blocks no longer need to be contiguous (we accept overhead)
* All blocks can be used, but pointers take space– Fragmentation (in this case internal) confined to last block
* Only offers sequential access– Must follow each block link to reach given file position

In linked list allocation, each file is stored as a linked list of disk blocks.
Each block stores:
Data, and a pointer to the next block in the file.

Question 7

Indexed Allocation

Answer 7

Each file has an index block that contains pointers to all the disk blocks used by the file.
Key Points:
No need for contiguous space — blocks can be scattered anywhere on disk.

Solves the problem of external fragmentation.

Allows random access to any block of the file.
* Can support holes *– i.e. we don’t allocate space for ‘empty’, 0 filled blocks–

Question 8

pros and cons of index allocation

Answer 8

Handles growing files easily.

No external fragmentation.

Fast random access.

Cons:
The index block itself must fit in memory.

Large files may require multi-level indexing (slower).

Question 9

Linked-List: File Allocation Table (FAT)

Answer 9

• Separates pointers from data blocks
• File Allocation Table (FAT) holds block numbers
  – Keep multiple on-disk copies of FAT for resilience
  Typically copy of whole FAT can reside in memory

– Allows fast access to any block in any file
Every block on disk has an entry in the FAT.

Each FAT entry stores the number of the next block in the file.

Files are chains of blocks linked by FAT entries, not direct pointers in blocks.

Question 10

Inode (Index Node)

Answer 10

Stores metadata about a file: permissions, owner, timestamps, size, block pointers, etc.
Has direct, single indirect, double indirect, and triple indirect pointers to data blocks.

Does not store the filename – that’s handled in the directory entry.

Question 11

Direct vs Indirect Pointers

Answer 11

Direct: Point straight to data blocks.

Single Indirect: Points to a block that holds more block pointers.

Double Indirect: A pointer to a block that holds pointers to other blocks of pointers.

Triple Indirect: Three levels deep; allows large file support.

Question 12

Reference Count (Hard Links)

Answer 12

Counts how many directory entries point to the inode.

When count = 0, data can be deleted.

Hard links can’t span file systems or point to directories

Question 13

Symbolic Links (Soft Links)

Answer 13

A file that contains a path to another file.

Can span across file systems.

Can point to non-existent files (broken links).

Question 14

Directory Structure

Answer 14

A directory is a file containing mappings of filename → inode number.

Can become fragmented.

Inodes and directory entries are separate.

Question 15

Efficiency and Waste

Answer 15

Larger block sizes = more data per block, better for large files but may waste space for small ones.

Systems sometimes allow block fragments to minimize waste.

Balance is crucial between access speed and space efficiency.
If you always use small blocks, large files will be slow to access.
If you always use large blocks, small files will waste space.

Question 16

Open File Descriptor Table

Answer 16

Each process has its own File Descriptor Table.

Maps to entries in the system-wide Open File Table.

Includes file position and inode pointer.

Children processes inherit file descriptors from the parent (important for pipes, redirection).

Question 17

Kernel Tables & Inode Caching

Answer 17

The kernel stores inodes in an Active Inode Table to speed up file access.

Inode IDs are valid only within their filesystem—kernel uses a hash of inode + device ID.

Each process has its own open file table, while the system maintains global open files and inode cache.

Question 18

Buffering & Block Caching

Answer 18

Processes read and write bytes
– Disks handle blocks
Buffering bridges this gap using a buffer cache:

Holds disk blocks in memory.

Enables read-ahead and write-behind.

Improves efficiency using LRU (Least Recently Used) strategies.

Question 19

Filesystem Flush & Sync

Answer 19

Buffers marked “dirty” are scheduled to be written to disk.

The system periodically flushes dirty buffers (e.g. on shutdown) to prevent data loss.

sync() system call can force this flush.

Question 20

Delayed Allocation

Answer 20

Writing data is delayed to allow efficient allocation.

When data is finally written, it’s often possible to allocate a contiguous block run, reducing fragmentation.

Question 21

Extents

Answer 21

Modern filesystems (e.g., ext4) use extents
stores files
Improves read speed, reduces metadata, and minimizes fragmentation.

Each extent records:

Logical file block start.

Number of blocks.

Starting disk block.