7a:T4f1,Before random access memory, before magnetic disks with movable heads, before any notion of 'jumping' to a specific location in a file—there was **sequential access**. It is the most primitive, most intuitive, and remarkably, still the most common method of interacting with file data in modern computing systems. Sequential access embodies a simple principle: **read or write data in a linear, ordered sequence from beginning to end**. Like reading a book page by page, or listening to a tape recording from start to finish, sequential access processes information in precisely the order it was stored. This simplicity is not a limitation—it is a profound strength. Sequential access aligns perfectly with physics. Magnetic tape can only move in one direction at a time. Hard disk platters spin continuously, making sequential reads vastly more efficient than scattered random reads. Even modern SSDs, with no moving parts, still benefit from sequential access patterns due to the way flash memory pages and blocks are organized. Understanding sequential access is foundational to understanding *all* file access methods, because every other method is essentially an optimization for specific access patterns that sequential access cannot efficiently serve.7b:T537,Let's examine how sequential read and write operations work at the system call level, understanding exactly what happens when bytes flow between your program and persistent storage. **The read() System Call:** ```c ssize_t read(int fd, void *buf, size_t count); ``` When you call `read(fd, buffer, n)`, the following sequence occurs: 1. **Validate parameters** — Check that fd is valid, buffer is a valid user-space pointer, count is reasonable. 2. **Locate open file table entry** — Follow fd through the process's file descriptor table to the system open file table entry. 3. **Check current offset** — Retrieve the current file pointer from the open file table entry. 4. **Determine bytes to read** — Compare requested count vs. bytes remaining (file_size - current_offset). Use the smaller value. 5. **Buffer cache lookup** — Check if the required file blocks are already in the system buffer cache. 6. **Disk I/O if needed** — If blocks are not cached, issue disk read operations to bring them into memory. 7. **Copy to user space** — Copy the requested bytes from kernel buffer cache to the user's buffer. 8. **Advance file pointer** — Add the number of bytes actually read to the current offset. 9. **Return bytes read** — Return the count of bytes successfully copied (may be less than requested).7c:T462,#include #include #include #include /** * Demonstrates sequential reading with proper error handling. * Shows how to handle partial reads and EOF detection. */ void sequential_read_demo(const char *filename) { int fd = open(filename, O_RDONLY); if (fd < 0) { perror("open"); return; } char buffer[4096]; ssize_t bytes_read; off_t total_bytes = 0; // Classic sequential read loop while ((bytes_read = read(fd, buffer, sizeof(buffer))) > 0) { // Process bytes_read bytes of data // File pointer automatically advances total_bytes += bytes_read; // Note: bytes_read may be less than sizeof(buffer) // This is normal - not an error (short read) // Causes: approaching EOF, signal interruption, etc. } if (bytes_read < 0) { // Actual error occurred perror("read"); } else { // bytes_read == 0 means EOF printf("Read %lld bytes total (EOF reached) ", (long long)total_bytes); } close(fd); }7d:T597,/* * Impact of buffer size on sequential read performance * Reading 100MB file with different buffer sizes * * Typical results on modern system: * * Buffer Size | System Calls | Overhead | Effective Rate * ------------|--------------|-------------|--------------- * 1 byte | 104,857,600 | ~100 seconds| ~1 MB/s * 64 bytes | 1,638,400 | ~1.6 seconds| ~60 MB/s * 4 KB | 25,600 | ~0.025 sec | ~4 GB/s * 64 KB | 1,600 | ~0.002 sec | ~50 GB/s * 1 MB | 100 | ~0.0001 sec | ~1 TB/s (cache hits) * * Note: Beyond ~64KB, benefits plateau as we're limited by * disk throughput, not system call overhead. */ #include #include #include #include #include void benchmark_buffer_size(const char *filename, size_t bufsize) { char *buffer = malloc(bufsize); int fd = open(filename, O_RDONLY); struct timespec start, end; clock_gettime(CLOCK_MONOTONIC, &start); ssize_t bytes; size_t total = 0; while ((bytes = read(fd, buffer, bufsize)) > 0) { total += bytes; } clock_gettime(CLOCK_MONOTONIC, &end); double elapsed = (end.tv_sec - start.tv_sec) + (end.tv_nsec - start.tv_nsec) / 1e9; printf("Buffer %8zu: %.3f seconds, %.2f MB/s ", bufsize, elapsed, (total / 1e6) / elapsed); close(fd); free(buffer); }7e:T495,**Layer 2: C Library Buffering (stdio)** Functions like `fread()`, `fwrite()`, `fgets()` use an intermediate buffer (typically 4KB-8KB) in user space: ```c // This is actually efficient: while ((c = fgetc(file)) != EOF) { process(c); } // fgetc() reads from an internal buffer, not the kernel. // Only refills the buffer with read() every 4KB-8KB. ``` The stdio library provides buffering modes that you can control: - `_IOFBF` — Full buffering (default for regular files) - `_IOLBF` — Line buffering (default for terminals) - `_IONBF` — No buffering **Layer 3: Kernel Buffer Cache** The operating system maintains a buffer cache (page cache in Linux) that holds recently accessed file blocks in RAM. Benefits: - **First read** hits disk, subsequent reads hit cache - **Read-ahead** prefetches sequential data into cache - **Write-back** buffers small writes and flushes efficiently **Layer 4: Disk Controller Cache** Modern disk controllers have 8-256MB of DRAM cache for: - **Read lookahead** — Prefetching subsequent sectors - **Write buffering** — Acknowledging writes before platters - **Command queuing** — Reordering requests for efficiency7f:T785,Sequential access is not merely a historical artifact—it remains the dominant access pattern for numerous critical workloads. Understanding these use cases illuminates why operating systems and storage systems optimize so heavily for sequential I/O. **1. Log Files and Event Streams** Application logs, system logs, transaction logs, and event streams are *inherently* sequential: - **Append-only writes** — New entries are always added at the end - **Linear reads** — Log analysis tools read from start to end (or a time range) - **Time ordering** — Events are naturally ordered by time of occurrence Examples: syslog, web server access logs, database transaction logs (WAL), Kafka message streams. **2. Media Files (Audio, Video, Images)** Media consumption is fundamentally sequential: - **Video playback** — Frames are decoded in order at fixed rate - **Audio streaming** — Samples are read sequentially at sample rate - **Image processing** — Raw images are often processed scanline-by-scanline Exceptions exist (seeking in video), but dominant access is sequential streaming. **3. Backup and Archival** Backup operations involve: - **Copying entire files** — Sequential read of source, sequential write to destination - **Tape drives** — Backup tapes are strictly sequential media - **Archive formats** — tar, zip, and similar formats are designed for sequential access **4. Batch Data Processing** Data pipelines often process files sequentially: - **ETL (Extract-Transform-Load)** — Read input, process, write output - **Scientific computation** — Process large datasets in sweeps - **Map phase of MapReduce** — Sequentially scan input splits **5. File Transfer and Replication** - **Network file transfer** — scp, rsync read files sequentially - **Database replication** — Streaming WAL records sequentially - **Content delivery** — CDN servers stream files to clients80:T575,/* * Comparison: Finding record by ID in a 1GB file * File contains 10 million 100-byte records */ // Sequential scan approach // Must read on average half the file to find a record // Average: 500MB read = ~3 seconds on HDD, ~0.2s on SSD record_t find_sequential(int fd, int target_id) { record_t record; // Read every record until we find the target while (read(fd, &record, sizeof(record)) == sizeof(record)) { if (record.id == target_id) { return record; // Found it! } } // Record not found - traversed entire file return (record_t){0}; } // Random access with index approach // Index tells us exact byte offset of target record // Read exactly one 100-byte record // Time: ~10ms on HDD, ~0.1ms on SSD record_t find_indexed(int fd, int target_id, index_t *index) { // Look up record offset in in-memory index (hash table or tree) off_t offset = index_lookup(index, target_id); // O(1) or O(log n) // Seek directly to record location lseek(fd, offset, SEEK_SET); // Read only the single record we need record_t record; read(fd, &record, sizeof(record)); return record; } /* * Performance comparison for single lookup: * - Sequential: 3000ms (HDD) / 200ms (SSD) * - Indexed: 10ms (HDD) / 0.1ms (SSD) * * That's 300x to 2000x faster! * The difference compounds with query volume. */72:{"json":{"id":"seed_fecf94b1e1e30836921e94340e399fa6","slug":"os-access-methods","category":"Operating Systems","topic":"Access Methods","title":"File Access Methods","description":"Master the fundamental techniques for reading and writing file data. Explore sequential access, direct access, indexed access, and memory-mapped I/O—understanding when each method excels and the architectural tradeoffs that guide system design decisions.","difficulty":"INTERMEDIATE","estimatedMinutes":75,"pages":[{"id":"seed_2eb394d49793de850086ee0a7de8a4d4","title":"Sequential Access","order":0,"content":[{"id":"opening-hook","title":"The Oldest and Most Enduring Access Pattern","content":[{"data":{"content":"$7a"},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will deeply understand the sequential access model—its conceptual underpinnings, the file pointer mechanism, implementation details, performance characteristics on different storage media, real-world use cases, and why this 'primitive' access pattern remains central to modern operating systems and applications.","variant":"info"},"type":"callout"}]},{"id":"conceptual-model","title":"The Conceptual Model of Sequential Access","content":[{"data":{"content":"At its core, sequential access treats a file as a **linear stream of bytes or records**. Imagine a very long tape with data written from one end to the other. To access any piece of data, you must 'play' the tape from wherever you currently are, moving forward (and sometimes backward) through the data stream.\n\nThe defining characteristic of sequential access is the **file pointer** (also called the **file position indicator** or **current position**). This pointer marks your current location within the file. Every read operation retrieves data starting from this pointer and automatically advances the pointer by the number of bytes read. Every write operation writes data starting at the pointer and advances it similarly.\n\n**Key properties of the sequential access model:**"},"type":"text"},{"data":{"items":["**Linear Traversal** — Data is accessed in order, from position 0 through position N-1, where N is the file size.","**Automatic Position Advancement** — After each read or write, the file pointer advances by the number of bytes processed.","**Single Current Position** — At any moment, there is exactly one 'current position' per open file descriptor.","**Forward and Backward Movement** — While forward is natural, the `lseek()` system call allows rewinding or repositioning.","**Record-Oriented or Byte-Oriented** — Depending on the OS and file system, sequential access may operate on fixed-size records or arbitrary byte streams."],"title":{"icon":"Target","text":"Sequential Access Properties","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**The tape metaphor:**\n\nThe tape metaphor is historically accurate—sequential access was literally how tape drives worked. Magnetic tape could only read data as it passed over the read/write head, and the tape could only move in one direction at meaningful speed (rewinding was slow and avoided when possible).\n\nEven though modern storage devices (disks, SSDs) can access arbitrary locations, the sequential model persists because:\n\n1. **Physical efficiency** — Disks achieve maximum throughput with sequential reads/writes\n2. **Simplicity** — The programming model is straightforward and intuitive\n3. **Buffering optimization** — OS caches can predict and prefetch sequential data\n4. **Common workloads** — Most file processing (logs, media, backups) is naturally sequential"},"type":"text"},{"data":{"icon":"Info","title":"Historical Context","content":"Sequential access predates the concept of 'files' entirely. Early computer systems read punched cards or paper tape—inherently sequential media. When magnetic tape was introduced in the 1950s, the sequential model was preserved. Even the original Unix file system was designed with sequential access as the primary paradigm, and this influence persists in POSIX standards today.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"file-pointer-mechanism","title":"The File Pointer Mechanism in Depth","content":[{"data":{"content":"The file pointer is the central abstraction enabling sequential access. Understanding how it works—both conceptually and in terms of OS implementation—is crucial for mastering file I/O.\n\n**What exactly is a file pointer?**\n\nA file pointer is a **non-negative integer offset** representing the byte position within a file where the next read or write will occur. When a file is first opened (without special flags), the file pointer is set to 0, indicating the beginning of the file.\n\nThe file pointer has the following behaviors:"},"type":"text"},{"data":{"rows":[["open()","Set to 0 (or EOF with O_APPEND)","Initial position determined by flags"],["read(n)","Advances by n bytes","Returns bytes read; may be < n at EOF"],["write(n)","Advances by n bytes","May extend file if at or past EOF"],["lseek(offset, whence)","Set to calculated position","Allows random repositioning"],["close()","Pointer discarded","Each open() creates a new pointer"]],"caption":"File Pointer Behavior by Operation","headers":["Operation","Effect on File Pointer","Notes"]},"type":"table"},{"data":{"content":"**Implementation in the Operating System:**\n\nWhen you open a file in Unix/Linux, the OS creates several data structures:\n\n1. **File Descriptor Table** (per-process) — Maps file descriptor integers (0, 1, 2, ...) to entries in the system-wide open file table.\n\n2. **Open File Table** (system-wide) — Contains one entry per open file instance. This entry stores:\n - **The file offset (file pointer)** — The current position for read/write\n - **Access mode** — Read, write, or both\n - **Reference count** — How many file descriptors point here\n - **Pointer to vnode/inode** — The actual file's metadata\n\n3. **Vnode/Inode Table** — Contains file metadata: size, permissions, block locations, etc.\n\nThe crucial insight is that the **file pointer lives in the open file table entry**, not in the file descriptor table or the inode. This has profound implications:"},"type":"text"},{"data":{"fileName":"file_pointer_sharing.c","languages":[{"code":"#include \n#include \n#include \n#include \n\nint main() {\n // Open a file - creates one open file table entry\n int fd = open(\"data.txt\", O_RDONLY);\n char buffer[10];\n \n // Read first 10 bytes - file pointer at position 10\n read(fd, buffer, 10);\n printf(\"Parent read: %.*s\n\", 10, buffer);\n \n // Fork creates a child with SAME open file table entry\n pid_t pid = fork();\n \n if (pid == 0) {\n // Child process\n // Shares the file pointer with parent!\n read(fd, buffer, 10); // Reads bytes 10-19\n printf(\"Child read: %.*s\n\", 10, buffer);\n return 0;\n }\n \n wait(NULL); // Wait for child\n \n // Parent continues - file pointer moved by child!\n read(fd, buffer, 10); // Reads bytes 20-29\n printf(\"Parent read after child: %.*s\n\", 10, buffer);\n \n close(fd);\n return 0;\n}","label":"C","value":"c"}],"showLineNumbers":true},"type":"code"},{"data":{"icon":"AlertCircle","title":"Shared File Pointers After fork()","content":"When you fork() a process, the child inherits file descriptors that point to the **same open file table entries** as the parent. This means they share the same file pointer! Reads/writes in one process affect the other's position. This is a common source of bugs and race conditions in systems programming.","variant":"warning"},"type":"callout"},{"data":{"content":"**Contrast: Independent file pointers with separate open() calls:**\n\nIf two processes both call `open()` on the same file, they get separate open file table entries with independent file pointers. Changes to one pointer do not affect the other.\n\nThis distinction is fundamental to understanding multi-process file I/O and is exploited by various system designs (e.g., append-only logs where multiple writers share a file pointer with O_APPEND semantics)."},"type":"text"}],"titleType":"number","titleNumber":2},{"id":"read-write-operations","title":"Read and Write Operations in Sequential Mode","content":[{"data":{"content":"$7b"},"type":"text"},{"data":{"fileName":"sequential_read_example.c","languages":[{"code":"$7c","label":"C","value":"c"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"**The write() System Call:**\n\n```c\nssize_t write(int fd, const void *buf, size_t count);\n```\n\nWrite follows a similar pattern but with additional considerations:\n\n1. **Validate parameters and permissions** — Check fd is writable, buffer is readable, count is valid.\n\n2. **Locate open file table entry and current offset** — Same as read.\n\n3. **Check O_APPEND flag** — If set, atomically move offset to EOF before writing.\n\n4. **Allocate blocks if extending file** — If writing past current file end, new blocks must be allocated.\n\n5. **Copy from user space to buffer cache** — Data moves from user buffer to kernel buffers.\n\n6. **Mark buffers dirty** — Buffers are marked for eventual write-back to disk.\n\n7. **Advance file pointer** — Add bytes written to current offset.\n\n8. **Return bytes written** — Usually equals count unless error or disk full.\n\n9. **Eventual write-back** — Dirty buffers are written to disk asynchronously (or synchronously with O_SYNC)."},"type":"text"},{"data":{"icon":"Lightbulb","title":"Short Reads vs. Short Writes","content":"Short reads (returning fewer bytes than requested) are normal and expected—always check the return value and loop if necessary. Short writes are more concerning; on regular files they typically indicate disk full conditions or quota exceeded. Always check write return values and handle ENOSPC (no space left on device) appropriately.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"performance-characteristics","title":"Performance Characteristics of Sequential Access","content":[{"data":{"content":"Sequential access achieves the best possible performance on virtually all storage media. Understanding *why* requires examining how different storage technologies respond to access patterns.\n\n**Hard Disk Drives (HDDs):**\n\nMagnetic hard drives consist of spinning platters and a read/write head that physically moves across the platter surface. Accessing data involves three time components:\n\n1. **Seek time** — Time to move the head to the correct track (~3-15ms average)\n2. **Rotational latency** — Time for the platter to rotate the desired sector under the head (~2-8ms average)\n3. **Transfer time** — Time to read/write the data once positioned (~0.01-0.1ms per sector)\n\nFor sequential access, seek time and rotational latency are paid **once** at the beginning. Subsequent reads are pure transfer time as contiguous sectors pass under the head. For random access, seek and rotational latency are paid for **every** access.\n\n**The numbers are stark:**"},"type":"text"},{"data":{"rows":[["Sequential Read","150-250 MB/s","~0.02ms","~5 seconds"],["Random Read","0.5-2 MB/s","~10ms","~15 minutes"],["Ratio","100-200x faster","500x lower","180x faster"]],"caption":"HDD Performance: Sequential vs. Random Access","headers":["Access Pattern","Throughput","Latency per 4KB","Time for 1GB"]},"type":"table"},{"data":{"content":"**Solid State Drives (SSDs):**\n\nSSDs have no moving parts—electrons, not mechanical arms, locate data. This dramatically reduces the sequential vs. random performance gap, but **it still exists**:\n\n1. **Page-level granularity** — SSDs read and write in pages (typically 4-16KB). Sequential access aligns with page boundaries.\n\n2. **Channel parallelism** — SSDs contain multiple flash chips. Sequential access can saturate all channels; random small reads may bottleneck on fewer channels.\n\n3. **Read-ahead optimization** — SSD controllers detect sequential patterns and prefetch subsequent data.\n\n4. **Write amplification** — Random small writes cause more internal housekeeping (garbage collection, wear leveling) than sequential writes.\n\n**SSD performance comparison:**"},"type":"text"},{"data":{"rows":[["Sequential Read","3,000-7,000 MB/s","N/A (streaming)","~0.02ms effective"],["Random Read (4KB)","50-200 MB/s","100K-1M IOPS","~0.02-0.1ms"],["Sequential Write","2,000-5,000 MB/s","N/A (streaming)","~0.02ms effective"],["Random Write (4KB)","100-500 MB/s","100K-500K IOPS","~0.02-0.1ms"]],"caption":"SSD Performance: Sequential vs. Random Access (NVMe)","headers":["Access Pattern","Throughput","IOPS","Latency"]},"type":"table"},{"data":{"content":"**Operating System Optimizations for Sequential Access:**\n\nOperating systems heavily optimize for sequential access patterns:\n\n1. **Read-ahead (Prefetching)** — When the OS detects sequential access, it preemptively reads subsequent blocks into the buffer cache before you request them. This effectively hides disk latency.\n\n2. **Large contiguous allocation** — File systems attempt to allocate sequential files in contiguous disk blocks to maximize sequential performance.\n\n3. **Write coalescing** — Small sequential writes are buffered and written as larger sequential chunks.\n\n4. **Delayed allocation** — Some file systems (ext4, XFS) delay block allocation until write-back, allowing better contiguous placement.\n\n5. **I/O scheduling** — Disk schedulers like CFQ and mq-deadline merge and reorder requests to maximize sequential runs.\n\nThe result: **sequential access often approaches the theoretical maximum throughput of the storage device**, while random access is limited by latency and seek overhead."},"type":"text"},{"data":{"icon":"Zap","title":"The 1000x Rule of Thumb","content":"A classic systems programming heuristic: sequential disk access can be 1000x faster than random access on HDDs. While SSDs narrow this gap dramatically, sequential access still wins—often by 10-50x for throughput-limited workloads. Always prefer sequential access when designing file formats and I/O patterns.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"buffering-strategies","title":"Buffering Strategies for Sequential I/O","content":[{"data":{"content":"Buffering is crucial to achieving good performance with sequential access. It occurs at multiple layers, and understanding each layer helps you write efficient I/O code.\n\n**Layer 1: Application Buffers**\n\nAt the application level, you control buffer size when calling read()/write(). The choice matters:\n\n- **Too small (byte-at-a-time)** — Each byte triggers a system call. System call overhead (~100ns-1μs) dominates, reducing throughput by 100-1000x.\n\n- **Too large** — Memory pressure increases; diminishing returns beyond buffer cache size.\n\n- **Optimal (4KB-1MB)** — Matches file system block size or buffer cache policies; amortizes system call overhead effectively.\n\n**The math:**"},"type":"text"},{"data":{"fileName":"buffer_size_impact.c","languages":[{"code":"$7d","label":"C","value":"c"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"$7e"},"type":"text"},{"data":{"icon":"Lightbulb","title":"Practical Buffer Size Recommendation","content":"For most sequential I/O, use buffer sizes of 64KB to 256KB. Smaller buffers waste CPU on system calls; larger buffers rarely improve throughput beyond disk limits. For memory-constrained environments, 4KB-16KB is a reasonable minimum. Match buffer sizes to file system block sizes when possible.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"real-world-applications","title":"Real-World Applications of Sequential Access","content":[{"data":{"content":"$7f"},"type":"text"},{"data":{"rows":[["Log files","Full scan or tail","Append-only","100%"],["Video playback","Linear streaming","N/A","95%+ (rare seeks)"],["File backup","Full file copy","Sequential write","100%"],["Database bulk load","Sequential read","Append writes","100%"],["Compiler output","N/A","Sequential write","100%"],["Document editing","Full load on open","Full save on close","95%+"]],"caption":"Sequential Access Workload Characteristics","headers":["Workload","Read Pattern","Write Pattern","Sequentiality"]},"type":"table"},{"data":{"icon":"Target","title":"Design for Sequential Access","content":"When designing file formats or I/O-heavy applications, ask: 'Can this workload be sequential?' Restructuring random access patterns into sequential patterns (e.g., sorting before processing, using append-only logs) often yields order-of-magnitude performance improvements.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"limitations","title":"Limitations and When Sequential Access Falls Short","content":[{"data":{"content":"While sequential access is often optimal, certain workloads fundamentally require other access patterns. Recognizing these cases is crucial for selecting the right approach.\n\n**Workloads Where Sequential Access Is Inadequate:**"},"type":"text"},{"data":{"items":["**Database record lookup** — Finding a single record by key requires random access; sequential scan would read entire table.","**Binary search** — Searching sorted data requires jumping to middle, then halves—inherently random access.","**Index-based queries** — Using indexes means following pointers to scattered data locations.","**Memory-mapped file editing** — Document editors modify arbitrary positions without reading/writing entire files.","**Random sampling** — Statistical sampling requires reading random positions throughout a file.","**Interactive applications** — Users jump to arbitrary positions (e.g., video seeking, spreadsheet navigation)."],"title":{"icon":"XCircle","text":"Sequential Access Limitations","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"content":"**The Cost of Inappropriate Sequential Access:**\n\nUsing sequential access where random access is needed leads to severe inefficiency:\n\n1. **Full table scans** — Database without indexes sequentially scans entire tables for single-record queries. O(n) instead of O(log n).\n\n2. **Linear search** — Finding an element in an unsorted file is O(n). With proper indexing and random access, it's O(log n) or O(1).\n\n3. **Read amplification** — To read 1 byte at position 1,000,000, sequential access must read all preceding 999,999 bytes.\n\n4. **Update inefficiency** — Modifying one record in a sequential file may require rewriting the entire file.\n\n**Example: The Database Index Problem**"},"type":"text"},{"data":{"fileName":"sequential_vs_indexed.c","languages":[{"code":"$80","label":"C","value":"c"}],"showLineNumbers":true},"type":"code"},{"data":{"icon":"AlertCircle","title":"Match Access Pattern to Workload","content":"The key insight is not that sequential access is 'better' or 'worse' but that it suits specific workloads. Logs and streaming media are naturally sequential. Databases require indexed random access. Choosing the wrong access pattern can degrade performance by orders of magnitude.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"summary","title":"Summary: Mastering Sequential Access","content":[{"data":{"content":"We've conducted a deep examination of sequential access—the most fundamental file access pattern. Let's consolidate the critical concepts:"},"type":"text"},{"data":{"type":"ordered","items":["**Sequential access reads/writes data linearly** — From byte 0 forward, with the file pointer auto-advancing after each operation.","**The file pointer is per-open-file, not per-fd** — Fork() creates shared pointers; separate open() creates independent pointers.","**Sequential access achieves maximum storage throughput** — 100-1000x faster than random access on HDDs; 10-50x on SSDs.","**Buffering is essential** — Use 64KB+ application buffers to amortize system call overhead.","**OS optimizations (read-ahead, contiguous allocation) enhance sequential performance** — The OS works with you when you access files sequentially.","**Many critical workloads are naturally sequential** — Logs, media, backups, batch processing all benefit enormously.","**Know when sequential doesn't fit** — Indexed lookups, binary search, and interactive editing require random access."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's next:**\n\nSequential access excels when you process files from start to finish, but what if you need to jump directly to a specific record without reading everything before it? The next page explores **Direct (Random) Access**—how to read and write at arbitrary positions within a file, the system calls that enable it, and the performance implications of breaking the sequential pattern."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now have a comprehensive understanding of sequential file access—the conceptual model, implementation mechanics, performance characteristics, and real-world applications. This foundation prepares you to appreciate why and when other access methods are necessary, starting with direct random access.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_719551347d9a608104da9d05edfd8d84","title":"Direct (Random) Access","order":1,"content":null,"isLocked":true},{"id":"seed_1e07a7be76cef59cae82a9b9d7e1119f","title":"Indexed Access","order":2,"content":null,"isLocked":true},{"id":"seed_691aca2ba6c7b0dc0b8ece7bf214130e","title":"Access Method Comparison","order":3,"content":null,"isLocked":true},{"id":"seed_584bee668e8d922a574e2999fedbd138","title":"Memory-Mapped Access","order":4,"content":null,"isLocked":true}]}}