Lab Refresh: 32-bit or 64-bit, FAT32 or NTFS, and a Print Queue Decision
Sunrise Junior College is refreshing the 20-machine lab used for HSC IT practicals. Twelve machines are 2015 desktops with 4 GB RAM and 500 GB hard disks; eight are newer units with 8 GB RAM and 240 GB SSDs. Every machine must run 64-bit Python 3.11, LibreOffice, a browser with ten or more tabs, and a local MySQL server for the PHP practical. The technician proposes three things: install a 32-bit operating system on the twelve older units "because they are slow", format every disk as FAT32 "because it is simpler and works everywhere", and connect all 20 machines to one shared printer served first-come-first-served. A teacher then copies a 5.4 GB virtual machine image to a freshly formatted 32 GB pen drive and Windows refuses with "The file is too large for the destination file system". Four print jobs arrive together at time 0 with print times of 6, 8, 2 and 4 minutes.
1. Evaluate the 32-bit and FAT32 proposals. State what actually causes the 5.4 GB copy to fail, and name the correct file system for (i) the internal disks and (ii) the pen drive.
Read the worked answer
32-bit proposal - reject. A 32-bit OS has a 4 GB address space, and after hardware reservations only about 3.2–3.5 GB is usable, so on a 4 GB machine it throws away memory the machine already owns. Worse, a 32-bit OS cannot execute 64-bit binaries, so one 64-bit Python/MySQL package image cannot be shared across the lab, and the 32-bit MySQL server hits its own memory ceiling with a browser open. Slowness here is a RAM-and-spinning-disk problem, not a bit-width problem; an SSD upgrade and fewer startup apps fix it.
Failure cause. FAT32 caps a single file at 4 GB (4,294,967,295 bytes). 5.4 GB exceeds that, hence the message; Windows setup also refuses to format a FAT32 volume larger than 32 GB, and FAT32 gives no journaling, no per-user permissions and no quotas.
Correct choices. (i) Internal disks: NTFS - journaling survives the six-to-ten power cuts, per-user permissions stop students reading each other's files, and files over 4 GB are allowed. (ii) Pen drive: exFAT - no 4 GB per-file limit, readable and writable on Windows, macOS and Linux, and without the permission friction NTFS causes when the drive moves between machines.
2. The shared printer uses FCFS. Compute average waiting time under FCFS and under non-preemptive SJF for jobs of 6, 8, 2 and 4 minutes arriving at t=0. Which should the lab adopt, and what practical point about printing does the calculation ignore?
Read the worked answer
FCFS (arrival order P1=6, P2=8, P3=2, P4=4):
| Job | Start | Wait |
|---|---|---|
| P1 (6) | 0 | 0 |
| P2 (8) | 6 | 6 |
| P3 (2) | 14 | 14 |
| P4 (4) | 16 | 16 |
Sum = 36, average = 36/4 = 9 minutes.
SJF (order 2, 4, 6, 8): waits are 0, 2, 6, 12 → sum 20, average = 5 minutes. SJF nearly halves the mean wait because the 2-minute job no longer sits behind a 6- and an 8-minute job.
Recommendation. Adopt non-preemptive SJF among jobs already waiting. Preemption is meaningless for a printer, and job lengths are effectively known (page count), so the usual objection to SJF - starvation of long jobs - is limited to batch prints, which the lab can run at closing time.
What the calculation ignores. A spooler already decouples the application from the printer: the queue is served by the print device, so scheduling policy changes only the order, not the throughput. Real fixes are a network printer with a print server and per-student page quotas, rather than a printer tethered to one machine that must stay switched on.
3. The lab plans one central MySQL install on a server machine, with the other 19 connecting over the LAN, instead of 19 local installs. Is that the better call for the 4 GB machines? Give two supporting and two opposing constraints.
Read the worked answer
Supporting. (1) Memory: mysqld plus InnoDB buffers typically costs several hundred megabytes resident. On a 4 GB desktop already running a browser, LibreOffice and Python, a local server is exactly the pressure that makes the machine feel "slow" - moving it off is the cheapest fix available. (2) Consistency: one dataset means the teacher demonstrates once, every student sees the same tables, and backup/restore is one operation instead of twenty.
Opposing. (1) Single point of failure: if the server machine or the switch dies on practical day, all 20 candidates are blocked, whereas a local install fails one candidate at a time. (2) Security and configuration: remote access requires bind-address changes, a non-root account with a host restriction, and port 3306 opened only to the lab subnet - a careless setup exposes the database to the whole campus network.
Judgement. Use the central server for teaching and assessment, but keep a local install on the eight 8 GB SSD machines as an offline fallback, and restrict the server account to the lab subnet with a per-student password rather than a shared root login.