Storage in the computer: Punched cards to the cloud storage

flowchart LR
    CPU["CPU & RAM"] -->|Transient Data| RAM["Primary Memory (RAM)"]
    RAM -->|Scratchpad| CPU
    CPU <-->|Load/Store| STORAGE["Secondary Memory"]
    STORAGE <-->|Persistent Data| DISK["HDD / SSD / Cloud"]

    flowchart TD
      FS[FAT] --> CT[Contiguous Allocation]
      FS --> LT[Linked Allocation]
      MFS[Modern FS] --> EX[Extent-Based Allocation]

Storage in the Computer: From Punched Cards to the Cloud

Long before terabyte SSDs and infinite cloud buckets, computers stored data on humble media—punch cards, magnetic tape, even cassette recorders. Each generation solved yesterday’s limits and introduced new challenges in capacity, speed, cost and reliability.

1. Early Sequential Storage

• Punched Cards (1950s): IBM cards held 80 characters per card. Entire programmes in FORTRAN or COBOL arrived as decks that readers scanned one card after another—purely sequential access. Dropping or misordering cards meant rerunning an entire job.

• Magnetic Tape (1960s–70s): Reel-to-reel tapes stored millions of bytes, but still required spooling past unwanted data. Backup and archive mainstays suffered from slow rewind times.

graph TD
    A["1950 - Punched Cards (80 bytes/card)"] --> B["1965 - Magnetic Tape (MBs/reel)"]
    B --> C["1975 - Floppy Disk (KBs–MBs)"]
    C --> D["1980 - Hard Disk Drive (MBs–GBs)"]
    D --> E["1995 - Optical Discs (CD/DVD)"]
    E --> F["2005 - SSD (GBs–TBs)"]
    F --> G["2015 - Cloud Storage (Virtually unlimited)"]

2. Random Access Arrives

• Floppy Disks: Introduced concentric tracks and sectors. Read/write heads could jump directly to a track—true random access. Capacities ranged from 160 KB (8″) to 1.44 MB (3.5″), limited by head precision and media quality.

• Macintosh Cassette Recorder: Early Apple II and some Mac clones used audio cassettes when ROM and RAM were expensive. Sequential but affordable—until disk drives became cost-effective.

3. File System Addressing Evolves

Operating systems map files to physical blocks. Early schemes used varying strategies for allocation and access:

3.1 Contiguous (FAT12/16)

• Contiguous (FAT12/16): Each file is stored in a single, uninterrupted block of space on the disk. This makes reading fast and efficient because the data is laid out sequentially. However, it introduces a significant limitation that affects usability over time.

  What happens if a contiguous block is not available?

  In file systems that use contiguous allocation (like early FAT12/16), each file must occupy a single, uninterrupted block of space on the disk. This model makes file reading fast and efficient, but it has a serious limitation: if the disk does not have a large enough free block to hold the entire file, the system cannot store the file — even if the total free space is sufficient.

  When such a situation arises, one of the following occurs:

  • The file write may fail: The operating system might reject the file with an error message like “disk full” because it can't find a single large enough block.
  • Disk reorganisation may be triggered: Some systems try to rearrange files to create contiguous space, but this is time-consuming and not always successful.

  Example: Imagine you try to save a 10MB video file on a disk that has 20MB of free space, but scattered in small chunks — say 5MB, 3MB, 4MB, and 8MB. Although the total space is more than enough, there's no single block of 10MB available. In a system using contiguous allocation, the file cannot be saved at all.

  📘

  Real-world Example: Think of trying to park a bus in a crowded lot. Even if total parking space is enough, unless there's one long enough stretch, you can't park at all. That’s how contiguous file allocation works.

  Note: This limitation is a key reason why modern file systems moved to more flexible allocation methods like linked allocation and extent-based storage, which allow files to be split across non-contiguous blocks.

flowchart LR
    Start[File A] --> B1[Block 1]
    B1 --> B2[Block 2]
    B2 --> B3[Block 3]

3.2 Linked (FAT12/16)

• Linked (FAT12/16): Instead of requiring a file to occupy a single continuous space, the file is broken into blocks (or clusters), and each block contains a pointer to the next block in the sequence. This allows the file to be stored in scattered locations, making better use of available space.

  How does it work?

  When a file is saved, the system stores its data wherever free space is available and adds a pointer at the end of each block to indicate the location of the next block. The operating system follows this chain of pointers to read the file in order.

  Advantages:

  • Files don’t require a single large block of space — any available blocks can be used.
  • Minimises external fragmentation.

  Disadvantages:

  • To read the entire file, the system must follow each pointer, increasing read overhead.
  • If any block or pointer becomes corrupted, the entire file chain may be lost.
  📘

  Real-world Example: Imagine reading a novel where each page says “To continue, turn to page X.” The story continues, but you're constantly flipping through the book — slower and harder to follow.

  Note: Linked allocation was an improvement over contiguous methods for handling fragmented space, but its pointer-chasing nature made it less efficient for large or frequently accessed files.

flowchart LR
    Start[File B] --> L1[Block 5]
    L1 --> L2[Block 9]
    L2 --> L3[Block 2]

3.3 Extent-based (NTFS, ext4)

• Extent-based (NTFS, ext4): Modern file systems like NTFS and ext4 use a more efficient system where files are stored in larger continuous segments called extents. Instead of tracking every block, the system records just the starting block and the number of blocks that follow.

  How does it work?

  Each file is described by one or more extents — a pair consisting of a starting block number and a length. This greatly reduces the amount of metadata needed to manage large files, and allows quick access by jumping directly to the desired block ranges.

  Advantages:

  • Reduces metadata overhead — fewer pointers to store and follow.
  • Improves performance for large files, especially sequential reads.
  • Handles fragmentation better by tracking multiple extents if needed.

  Disadvantages:

  • If disk becomes highly fragmented, the number of extents increases and access slows down.
  • Not ideal for very small files unless paired with smart caching or block grouping.
  📘

  Real-world Example: Instead of tracking every page, think of a book's index telling you that Chapters 1–4 are from shelf A, position 20 to 23. It’s simple, efficient, and compact — especially useful for long files.

  Note: Extent-based allocation strikes a balance between performance and flexibility, and is widely used in modern operating systems for everything from media storage to enterprise databases.

Example: File C starts at block 20 and spans 4 blocks.

flowchart LR
    F[File C] --> E1["Extent: Block 20 (length 4)"]
    E1 --> B20[Block 20] --> B21[Block 21] --> B22[Block 22] --> B23[Block 23]

4. Addressing Widths and Scale

Each file system uses binary addresses—8-, 16-, 32- or 64-bit—to index blocks:

• 16-bit → 65 536 addresses (early floppies).
• 32-bit → 4 billion addresses (FAT32, ext2).
• 64-bit → 18 quintillion addresses (NTFS, ext4, APFS).

5. Enterprise Features & Health

RAID and Beyond

RAID (Redundant Array of Independent Disks) is a method of combining multiple physical disks into a single logical unit to improve performance, fault tolerance, or both. RAID configurations are handled at the hardware or software level, and the operating system presents the combined storage as a single drive to applications.

Popular RAID levels include:

• RAID 0 – Striping: Splits data across drives for speed but offers no redundancy.
• RAID 1 – Mirroring: Duplicates the same data on two or more drives for reliability.
• RAID 5 – Striping with parity: Balances speed and fault tolerance by storing parity information to recover from single-drive failure.
• RAID 6 – Double parity: Similar to RAID 5 but can handle two simultaneous disk failures.
• RAID 10 – Striping + Mirroring: Combines speed of RAID 0 with the redundancy of RAID 1.

The operating system abstracts these RAID arrangements and manages data placement, file systems, and access permissions. From the perspective of most software — including programming languages like Python, Java, or C — the location and method of data storage are entirely invisible. A programmer simply interacts with files using paths (e.g., "/home/data/file.txt") and APIs, without needing to know whether the data resides on a local SSD, a RAID array, or a SAN.

6. Scaling Out: SAN and Cloud

Block-level storage is a foundational method of storing data where information is divided into fixed-size chunks called blocks. This model evolved from early disk systems and remains central to modern storage architectures like SANs, enabling high-speed, flexible data access. Unlike file-level systems, block storage gives direct access to raw storage, allowing the operating system to control formatting and organisation.

Block-level storage divides data into fixed-size units called blocks. Each block is like a page in a book — it doesn't carry any information about the file it belongs to. The operating system or file system keeps track of which blocks belong to which files.

Analogy: Imagine storing a book not as one unit, but as individual pages placed in different drawers. You need a catalogue to know which pages (blocks) to retrieve and in what order.

Concept	Analogy	Purpose
Block	A page in a book	Part of a complete file
File System	Table of contents	Keeps track of blocks
Block Storage	Locker with scattered pages	Reassembles data from blocks
File-level Storage	Book on a shelf	Access whole file at once

How Files Are Stored in Blocks:

flowchart LR
    A[File A] --> B1[Block 3]
    A --> B2[Block 7]
    A --> B3[Block 12]

Storage Area Network (SAN) uses block-level storage accessed over a network, typically via Fibre Channel or iSCSI. It provides raw storage volumes to servers, which format and manage the file systems themselves.

Speed & Access Comparison:

Storage Type	Access Speed	Effort to Manage	Use Case
Spinning Disk (RAID)	Low to Medium (100–250 MB/s)	Low to Moderate	General backup, archival
SSD	High (500 MB/s – 5 GB/s)	Low	Workstations, fast boot
SAN	Very High (multi-GB/s with Fibre Channel or iSCSI)	High (requires configuration: zoning, LUN masking, etc.)	Databases, virtualisation, HPC

Why SANs Matter in Distributed and High-Performance Computing:

• Centralised storage: Multiple compute nodes can access the same block storage, essential in clusters.
• Scalability: SANs can grow by adding more storage arrays without touching application servers.
• High-speed data throughput: SANs use dedicated, high-bandwidth networks suitable for workloads with large I/O (e.g., genome processing, video rendering, training ML models).
• Concurrency: SANs support many users accessing data simultaneously, with mechanisms like distributed locking to prevent file corruption.
• Resilience and redundancy: Built-in RAID and replication protect against failures.

Cloud storage via HTTP-based APIs abstracts away physical details. You deal with “objects” or “blocks,” while providers handle data placement, replication, versioning and integrity checks.

7. Why It Matters

Knowledge of storage media evolution helps in choosing the right media, understanding why backups on tape are slow, why SSDs outperform HDDs, and how cloud APIs hide complexity so you can focus on your data—not its plumbing.

In the next section (“Block Diagram of the Computer”), we’ll follow how CPU addresses traverse serial and parallel buses to storage controllers, mapping binary pointers to physical tracks, sectors and flash pages—bringing full circle the journey from punched cards to Python programs.