Linux File Systems: How Data Lives on Disk (and How It Differs from Windows)

Without file system:
┌──────────────────────────────────────────────────────┐
│ 0100110101111010010101001010101011101010100101001010...│
│ (just raw bytes — no names, no structure, no meaning) │
└──────────────────────────────────────────────────────┘

With file system:
┌─────────────────────────────────────────────────────────┐
│ Superblock │ Group Descriptors │ Block Bitmap │ ...     │
│                                                          │
│  /home/user/hello.txt  →  inode 42  →  blocks 100, 101 │
│  /var/log/syslog       →  inode 78  →  blocks 200–210  │
│  /bin/bash             →  inode 15  →  blocks 50–80    │
└─────────────────────────────────────────────────────────┘

Physical Disk:
┌────────┬────────┬────────┬────────┬────────┬────────┐
│Block 0 │Block 1 │Block 2 │Block 3 │Block 4 │Block 5 │ ...
│(4 KB)  │(4 KB)  │(4 KB)  │(4 KB)  │(4 KB)  │(4 KB)  │
└────────┴────────┴────────┴────────┴────────┴────────┘

Physical Disk (500 GB):
┌──────────────┬──────────────────┬─────────────────┐
│ Partition 1  │   Partition 2    │  Partition 3     │
│   /boot      │       /          │     /home        │
│   ext4       │     ext4         │     ext4         │
│   (1 GB)     │    (100 GB)      │    (399 GB)      │
└──────────────┴──────────────────┴─────────────────┘

Partition Table (GPT or MBR) at the beginning of the disk
describes the layout.

ext4 Disk Layout:
┌─────────┬──────────┬──────────┬──────────┬──────────┬───────┐
│  Boot   │  Block   │  Block   │  Block   │  Block   │       │
│  Sector │  Group 0 │  Group 1 │  Group 2 │  Group 3 │  ...  │
│ (1 KB)  │          │          │          │          │       │
└─────────┴──────────┴──────────┴──────────┴──────────┴───────┘

Each Block Group:
┌───────────┬───────────┬────────┬────────┬────────┬──────────┐
│Superblock │  Group    │ Block  │ inode  │ inode  │   Data   │
│(backup)   │Descriptor │Bitmap  │Bitmap  │ Table  │  Blocks  │
│           │  Table    │        │        │        │          │
│  4 KB     │  varies   │ 4 KB   │ 4 KB   │varies  │  varies  │
└───────────┴───────────┴────────┴────────┴────────┴──────────┘

# View superblock information
sudo dumpe2fs /dev/sda1 | head -40

# Key fields:
# Filesystem volume name:   my-data
# Filesystem UUID:          a1b2c3d4-...
# Block count:              26214400
# Block size:               4096
# Blocks per group:         32768
# Inodes per group:         8192
# Inode size:               256
# Journal size:             128M
# Filesystem state:         clean

# Recover from backup superblock
sudo e2fsck -b 32768 /dev/sda1   # Use backup at block 32768

inode (256 bytes in ext4):
┌──────────────────────────────────────┐
│  File Type and Permissions (mode)    │  4 bytes
│  Owner UID                           │  4 bytes
│  Group GID                           │  4 bytes
│  File Size (bytes)                   │  8 bytes (64-bit)
│  Timestamps:                         │
│    - atime (last access)             │  4 bytes
│    - ctime (last inode change)       │  4 bytes
│    - mtime (last data modification)  │  4 bytes
│    - crtime (creation time)          │  4 bytes
│  Hard Link Count                     │  4 bytes
│  Block Count                         │  4 bytes
│  Flags                               │  4 bytes
│                                      │
│  Data Block Pointers:                │
│    Extent Tree (ext4)                │  60 bytes
│    OR                                │
│    12 Direct + Indirect + Double     │
│    + Triple Indirect Pointers (ext2) │
│                                      │
│  Extended Attributes (xattr)         │  remaining space
└──────────────────────────────────────┘

# Create a hard link
ln original.txt link.txt

# Both have the same inode number:
ls -li original.txt link.txt
# 42 -rw-r--r-- 2 user group 100 Feb 25 10:00 original.txt
# 42 -rw-r--r-- 2 user group 100 Feb 25 10:00 link.txt
#  ↑                 ↑
# Same inode!    Link count = 2

ext2/ext3 (indirect pointers):
inode
├── Direct Pointer 0  → Block 100
├── Direct Pointer 1  → Block 101
├── ...
├── Direct Pointer 11 → Block 111
├── Indirect Pointer  → [Block 200: ptr→300, ptr→301, ...]
├── Double Indirect   → [Block 400: ptr→[500: ptr→600, ...]]
└── Triple Indirect   → [Block 700: ptr→[800: ptr→[900: ...]]]

ext4 (extents):
inode
├── Extent 0: start=100, length=50    → Blocks 100–149 (200 KB)
├── Extent 1: start=500, length=200   → Blocks 500–699 (800 KB)
└── Extent 2: start=1000, length=1000 → Blocks 1000–1999 (4 MB)

Just 3 entries describe 5 MB of data!
(vs. 1,250 individual pointers in ext2)

Extent Entry:
┌────────────────┬──────────┬────────────────┐
│ Logical Block  │ Length   │ Physical Block  │
│  (file offset) │ (blocks) │ (disk location) │
│   4 bytes      │ 2 bytes  │   6 bytes       │
└────────────────┴──────────┴────────────────┘

Directory /home/user/ (inode 200):

Linear format (small directories):
┌─────────┬───────┬─────────┬──────────┐
│ inode   │ reclen│ name_len│ name     │
│ number  │       │         │          │
├─────────┼───────┼─────────┼──────────┤
│   200   │  12   │    1    │  "."     │  (self)
│   100   │  12   │    2    │  ".."    │  (parent)
│    42   │  24   │    9    │"hello.txt"│
│    78   │  20   │    6    │"photos"  │
│    99   │  28   │   11   │"project.c"│
└─────────┴───────┴─────────┴──────────┘

Hash tree format (large directories, >2 block):
Uses HTree (hash-indexed B-tree) for O(1) average lookup
instead of O(n) linear scan.

1. Root inode (always inode 2) → read directory entries
2. Find "home" → inode 50 → read directory entries
3. Find "user" → inode 100 → read directory entries
4. Find "hello.txt" → inode 42 → read inode metadata
5. Read data blocks from inode 42's extent tree

Writing a new file (3 steps):
1. Allocate inode     ← Power fails here!
2. Write data blocks
3. Update directory

Result: inode allocated but not in any directory
        → "orphan inode" → disk space leaked!

Deleting a file (3 steps):
1. Remove directory entry  ← Power fails here!
2. Free data blocks
3. Free inode

Result: Directory entry gone, but blocks still marked "used"
        → Blocks leaked forever!

Journal Area:
┌──────────────────────────────────────────────────┐
│ Transaction 1:                                    │
│   "About to: allocate inode 42,                  │
│    write blocks 100-102,                          │
│    add 'hello.txt' to dir inode 200"             │
│   Status: COMPLETE                                │
├──────────────────────────────────────────────────┤
│ Transaction 2:                                    │
│   "About to: delete 'old.txt' from dir 200,     │
│    free inode 55, free blocks 300-305"           │
│   Status: IN-PROGRESS                             │
└──────────────────────────────────────────────────┘

Step 1: JOURNAL WRITE (write plan to journal)
        "I will modify blocks X, Y, Z with data A, B, C"

Step 2: JOURNAL COMMIT (mark transaction as committed)
        "Plan is complete and valid"

Step 3: CHECKPOINT (apply changes to actual file system)
        Write actual data to blocks X, Y, Z

Step 4: JOURNAL CLEANUP (free journal space)
        "Transaction applied, journal entry can be reused"

Case 1: Crash during Step 1 (journal write)
  → Transaction incomplete → discard → no damage

Case 2: Crash during Step 2 (before commit)
  → Transaction not committed → discard → no damage

Case 3: Crash during Step 3 (checkpoint)
  → Transaction committed but not all changes applied
  → REPLAY journal: re-apply committed transactions
  → File system consistent in seconds, not hours!

# Check current journal mode
sudo dumpe2fs /dev/sda1 | grep "Journal features"

# Mount with specific mode
sudo mount -o data=journal /dev/sda1 /mnt

# procfs: read CPU info (no file on disk — generated on-the-fly)
cat /proc/cpuinfo

# sysfs: read CPU frequency
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

# tmpfs: ultra-fast temporary files (in RAM, lost on reboot)
df -h /tmp
# tmpfs   7.8G   48M  7.8G  1% /tmp

NTFS Structure:
┌──────────────────────────────────────────────┐
│  Boot Sector │ MFT │ MFT Mirror │ Data Area  │
└──────────────────────────────────────────────┘

MFT (Master File Table):
Every file/directory is an entry in the MFT.
Each MFT entry = 1 KB (fixed size).

/                        ← Root (always exists)
├── boot/                ← May be separate partition (/dev/sda1)
├── home/                ← May be separate partition (/dev/sda3)
│   └── user/
├── mnt/
│   └── usb/             ← USB drive mounted here
├── media/
│   └── cdrom/           ← CD-ROM mounted here
└── tmp/                 ← May be tmpfs (RAM)

All storage devices are "grafted" onto the single tree
using the mount command:

    mount /dev/sda3 /home
    mount /dev/sdb1 /mnt/usb

C:\                      ← System drive
├── Windows\
├── Program Files\
└── Users\

D:\                      ← Data drive (completely separate tree)
├── Projects\
└── Documents\

E:\                      ← USB drive (yet another separate tree)
└── Backup\

Each drive has its own independent tree.
No concept of a unified root.

-rwxr-xr--  1 alice developers 4096 Feb 25 10:00 script.sh

Three levels: Owner (alice), Group (developers), Others
Three permissions each: Read (r), Write (w), Execute (x)

Extended: ACLs for fine-grained control
    setfacl -m u:bob:rx script.sh    # Give bob read+execute

script.bat:
  SYSTEM:        Full Control
  Administrators: Full Control
  alice:          Modify
  bob:            Read & Execute
  developers:     Read

Windows ACLs are more granular by default:
  - 13 individual permissions (vs. Linux's 3)
  - Explicit Allow and Deny entries
  - Inheritance from parent folders

file.txt                    ← Default (unnamed) stream: "Hello World"
file.txt:hidden             ← Named stream: "Secret data"
file.txt:thumbnail          ← Named stream: (image data)

# Windows:
echo "Secret" > file.txt:hidden
more < file.txt:hidden

# Linux cannot see ADS when mounting NTFS
# (potential security issue when transferring files)

echo "Hello" > /home/user/hello.txt

1. VFS: Resolve path /home/user/ → directory inode

2. ext4: Allocate new inode (scan inode bitmap for free entry)
   → inode 42

3. ext4: Initialize inode 42
   → type=regular file, permissions=644, owner=user
   → size=0, timestamps=now

4. ext4: Allocate data block (scan block bitmap)
   → block 1000

5. ext4: Write "Hello\n" to block 1000

6. ext4: Update inode 42
   → size=6, extent: logical_block=0, physical_block=1000, length=1

7. ext4: Add directory entry to /home/user/
   → "hello.txt" → inode 42

8. ext4: Update directory inode (mtime)

9. ext4: Update superblock (free block/inode counts)

All wrapped in a journal transaction!

rm /home/user/hello.txt

1. Remove directory entry "hello.txt" from parent directory
2. Decrement inode 42's link count (hard link count)
3. If link count == 0 AND no process has the file open:
   a. Free data blocks (update block bitmap)
   b. Free inode (update inode bitmap)
   c. Update superblock (free counts)
4. If link count == 0 BUT file is still open:
   → Mark as "orphan" (deleted when last fd closes)

Note: The actual data is NOT erased!
      Only the metadata (bitmaps, directory entry) is updated.
      → This is why "undelete" tools can sometimes recover files.

int fd = open("/home/user/hello.txt", O_RDONLY);
char buf[1024];
read(fd, buf, 1024);

1. open(): Resolve path → inode 42, create file descriptor
2. read():
   a. Check page cache — is the data already in memory?
      YES → Copy from page cache to user buffer (fast!)
      NO  → Continue to step b
   b. Look up extent tree in inode 42
      → Logical block 0 maps to physical block 1000
   c. Submit block I/O request to block layer
   d. Block layer: merge, sort, schedule disk I/O
   e. Disk controller: read physical sector
   f. Data arrives → stored in page cache
   g. Copy from page cache to user buffer
   h. Return to application

# Create a file system
sudo mkfs.ext4 /dev/sdb1

# Mount a file system
sudo mount /dev/sdb1 /mnt/data

# Automatic mounting (edit /etc/fstab)
# /dev/sdb1  /mnt/data  ext4  defaults  0  2

# Check file system for errors
sudo e2fsck -f /dev/sdb1

# View file system information
sudo dumpe2fs /dev/sdb1 | less

# View disk usage
df -h           # File system level
du -sh /home/*  # Directory level

# View inode number
ls -i hello.txt
# 42 hello.txt

# View detailed inode info
stat hello.txt
#   File: hello.txt
#   Size: 6          Blocks: 8     IO Block: 4096  regular file
# Device: 801h/2049d Inode: 42     Links: 1
# Access: (0644/-rw-r--r--)  Uid: (1000/user)   Gid: (1000/user)
# Access: 2026-02-25 10:00:00
# Modify: 2026-02-25 10:00:00
# Change: 2026-02-25 10:00:00
#  Birth: 2026-02-25 10:00:00

# View physical block locations (requires root)
sudo hdparm --fibmap hello.txt
# or
sudo filefrag -v hello.txt
#  ext:  logical_offset: physical_offset:  length:  flags:
#    0:        0..       0:    1000..   1000:      1:  last,eof