Question 7 of 7

Question 7 (20 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

(a) Hard vs. soft real-time systems. A hard real-time system treats every deadline as absolute: missing even one deadline is a system failure, so the scheduler must guarantee, in advance, that every task's worst-case execution time fits before its deadline (e.g. an automotive airbag-deployment controller, or a pacemaker's pacing-pulse timer — a late response is not merely degraded service, it can be fatal or destructive). A soft real-time system still assigns priority to meeting deadlines, but an occasional miss degrades quality rather than causing catastrophic failure (e.g. a video-streaming client that drops or delays a frame under load — the viewer notices a stutter, nothing worse). Consequently hard real-time systems need specialised, statically-analysable schedulers (e.g. Rate-Monotonic or Earliest-Deadline-First with formal schedulability tests) and typically dedicate/reserve resources, while soft real-time needs, such as multimedia playback, can be handled by giving real-time tasks scheduling priority within a general-purpose OS without a formal guarantee.

(b) File protection. The motivation is controlling who may read, write, execute or delete a file, since a multi-user system stores many users' files on shared storage and an unprotected file system would let any process read or corrupt any other user's data. A widely used technique is the access-control list / permission-bits scheme (e.g. Unix-style owner/group/other read-write-execute bits): each file carries a small set of permission fields, and the OS checks the requesting process's identity against those fields on every open/read/write/execute attempt, denying the operation if the identity does not have the required bit set. Example: a source-code file owned by a developer can be set readable-and-writable by the owner, readable-only by their team's group, and completely inaccessible to other users, so a colleague outside the project cannot even read (let alone corrupt) it.

(c) Contiguous allocation. Each file is stored as a single run of consecutive disk blocks, recorded in the directory entry as just a starting block address plus a length. Advantages: both sequential access (read the next block = just advance to the physically next block, no lookup needed) and direct/random access (block $i$ of the file is simply starting-block $+ i$, a single arithmetic step) are extremely fast, and the directory entry is minimal (two numbers). Shortcomings: the classic dynamic-storage-allocation problem resurfaces — files are created and deleted over time, fragmenting free space into scattered holes exactly like the variable-partition memory allocation of Question 6, so finding one large-enough contiguous run for a new or growing file becomes increasingly hard (requiring periodic compaction); and a file cannot easily grow in place if the blocks immediately after it are already allocated to another file, without moving the whole file. Example: a 10-block video file allocated blocks 50–59 reads sequentially with zero seek overhead within the run, but if the user later wants to append 5 more blocks and blocks 60–64 already belong to another file, the OS must either relocate the entire 15-block file elsewhere or fragment it, losing the pure-contiguous benefit.

(d) RAID. RAID improves reliability by storing redundant information across multiple physical disks so that the failure of one drive does not lose data: RAID 1 (mirroring) keeps a full duplicate copy of every block on a second disk, so a single-disk failure loses nothing (the mirror is used instead); RAID 5 instead stripes data across $N$ disks and adds one parity block per stripe (rotated across drives), so any single missing disk's data can be reconstructed on the fly from the surviving data blocks and parity via XOR. RAID improves performance through striping: a file's blocks are spread across several disks (RAID 0-style striping, also present inside RAID 5), so multiple blocks of one large read/write can be serviced by different disks' read/write heads in parallel, multiplying effective throughput roughly by the number of drives involved. Example: a database server on RAID 5 across 5 disks gets both near-4-disk-wide striped read/write throughput (one disk's capacity is spent on rotating parity) and survives any single drive failure by reconstructing the missing disk's blocks from the other four plus parity, without taking the system offline.