https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=Operating_Systems_2026F_Lecture_12 2026-11-15T20:21:18Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=Operating_Systems_2026F_Lecture_12&diff=25213&oldid=prev 2026-11-04T15:28:44Z

<p>Created page with &quot;==Video== Video from the lectures given on November 3rd and 4th, 2026 are now available: * [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec12a-20261103.mp4 Lecture 12A] * [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec12b-20261104.mp4 Lecture 12B] ==Notes== ===Lecture 12A=== &lt;pre&gt; Lecture 12A ----------- A1 is graded A2 is being graded, almost done Midterm is to be graded Remember that people made compu...&quot;</p> <p><b>New page</b></p><div>==Video==<br /> <br /> Video from the lectures given on November 3rd and 4th, 2026 are now available:<br /> * [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec12a-20261103.mp4 Lecture 12A]<br /> * [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec12b-20261104.mp4 Lecture 12B]<br /> <br /> ==Notes==<br /> <br /> ===Lecture 12A===<br /> <br /> &lt;pre&gt;<br /> Lecture 12A<br /> -----------<br /> A1 is graded<br /> A2 is being graded, almost done<br /> Midterm is to be graded<br /> <br /> <br /> Remember that people made computers work before the Internet (search engines, AI, etc)<br /> - how did they do it?<br /> <br /> Filesystems<br /> - files<br /> - and how they are stored<br /> <br /> <br /> CPU &lt;---&gt; Memory<br /> |<br /> I/O devices<br /> <br /> I/O device directly talks to memory: DMA<br /> - direct memory access<br /> <br /> <br /> I/O devices<br /> - screen<br /> - keyboard, mouse, touchscreen<br /> - network<br /> - storage &lt;--- our focus<br /> <br /> When we talk about storage, we distinguish between<br /> volatile and non-volatile memory<br /> - does it save its contents when power is lost?<br /> <br /> volatile storage is pretty simple in structure<br /> - RAM, basically<br /> - put in an address, get back one or more bytes<br /> <br /> How much data do you get from RAM at a time?<br /> - at least a &quot;word&quot;, i.e., the size of a register<br /> - today, generally 64 bits<br /> - but generally you load a cache line worth from main memory<br /> - some multiple of the word size<br /> <br /> <br /> memory hierarchy<br /> - computers have many ways to store information<br /> - each method of storage involves a trade-off between<br /> durability, speed, &amp; cost<br /> - speed involving latency and bandwidth<br /> - so to make things fast but use lots of storage,<br /> you have to play a balancing game<br /> <br /> What storage do we have? (from fastest to slowest)<br /> - registers<br /> - TLB &lt;-- for virtual memory, later discussion<br /> - cache (L1, L2, L3, ?)<br /> - RAM (DRAM)<br /> - SSD<br /> - hard drives<br /> - tapes<br /> <br /> Tapes -<br /> - cheap: just tape!<br /> - big: just add more tape!<br /> - slow: sequential can be okay, but random access is SLOW<br /> <br /> hard drives -<br /> - not so cheap: magnetic platters<br /> - big because of high density recording (also for tapes)<br /> - but also kinda slow (for random access)<br /> <br /> <br /> Why do we care about the technology of hard drives?<br /> - because it informs the design of filesystems<br /> <br /> How do we store data in a way that makes the best use of the performance characteristics of the device?<br /> <br /> For RAM, we just have address spaces<br /> - not much difference between sequential and random access<br /> (in theory), so maps well<br /> - but actually random access of RAM is slow,<br /> but we deal with that in other ways<br /> <br /> Virtual memory<br /> - make volatile storage fast<br /> - and account for not having enough of it<br /> <br /> filesystems<br /> - make persistent storage useful and fast<br /> - so need to encourage sequential data access and<br /> discourage random data access<br /> - and when random data access happens, want to limit<br /> the randomness<br /> <br /> Files and directories work well for this<br /> - mostly programs read only a small fraction of files on a system<br /> - and for those files, they are mostly accessed sequentially<br /> <br /> This abstraction isn&#039;t essential<br /> - disk storage is an array of blocks<br /> (as an abstraction)<br /> - a block is a fixed unit of storage<br /> - 512 bytes or a multiple (4K, 8K)<br /> <br /> caching<br /> <br /> what is a cache?<br /> - faster storage that stores copies of data<br /> <br /> cache is never authoritative, it is just a fast copy<br /> - higher in the memory hierarchy<br /> <br /> a cached copy is normally disposable<br /> - can throw it away if you need the space<br /> <br /> On Linux, filesystems are abstractions over block storage<br /> - provide extensive caching infrastructure<br /> <br /> <br /> So what layers are we talking about with filesystems?<br /> - storage &lt;- the device that actually stores the data<br /> - volume management &lt;- reorganize storage<br /> - interface &lt;- block device, way we get the data<br /> - filesystem &lt;- abstraction over block device,<br /> turns it into files<br /> <br /> From a user&#039;s perspective, a filesystem is a hierarchical key value store<br /> - /path/to/something =&gt; data<br /> <br /> But what if I want to use multiple filesystems at the same time?<br /> - how do I name the filesystems?<br /> <br /> On MS-DOS and older windows -<br /> filesystems would have letter names<br /> <br /> In UNIX, we mount filesystems<br /> - associate a directory with a filesystem<br /> - so all files and directories in the filesystem are under that directory<br /> - the mountpoint directory is where the filesystem&#039;s files are integrated as part of the mount<br /> - if the mountpoint directory has any files...<br /> they get hidden<br /> &lt;/pre&gt;<br /> <br /> ===Lecture 12B===<br /> <br /> &lt;pre&gt;<br /> Lecture 12B<br /> -----------<br /> A1 is graded (uploading today)<br /> A2 is being graded, should be done soon<br /> Then we&#039;ll be grading the midterm<br /> <br /> Remember you need to be able to solve problems without a search engine or AI<br /> - figure out the right questions to ask: answers are easy, questions are hard<br /> <br /> <br /> Filesystems<br /> <br /> CPU &lt;---&gt; RAM<br /> |<br /> I/O devices<br /> <br /> Real picture is much more complicated<br /> - I/O devices can be entire computers<br /> - really, everything but the simplest embedded system<br /> is a network of computers, but pretending to act<br /> like the above<br /> <br /> Recall I/O devices are<br /> - keyboard, mouse, touchscreen<br /> - screen/GPU<br /> - disks &lt;--- filesystems<br /> - network<br /> <br /> Memory hierarchy<br /> - many different kinds of storage technologies<br /> - different trade-offs between speed, durability, and cost<br /> - speed is relevant in sequential vs random access to data<br /> <br /> Data on tape is stored as magnetic fluxes<br /> - very little magnets<br /> A read/write head allows us to access the bits stored in these magnetic regions<br /> <br /> Reading a tape sequentially is very fast<br /> Reading a tape randomly is very slow<br /> - lots of fast forwarding &amp; rewinding<br /> <br /> To use this sort of medium, you have to use the right abstractions to make it efficient<br /> <br /> Key technologies in the memory hierarchy<br /> (fastest to slowest, also smallest to biggest)<br /> <br /> registers (on the CPU), 64 bits each<br /> TLB &lt;--- for virtual memory, 64-256K?<br /> cache (L1, L2, L3) &lt;--- few megabytes<br /> RAM &lt;--- gigabytes<br /> SSDs &lt;--- many gigabytes to terabytes<br /> hard drives &lt;--- terabytes<br /> tapes &lt;--- as much as you want<br /> <br /> Speed is really about latency versus bandwidth<br /> - you can always increase bandwidth by duplication<br /> (more hard drives, more tapes, etc)<br /> <br /> bandwidth: bytes per second<br /> latency: time for first byte (request to response)<br /> (seek time)<br /> <br /> <br /> We have two basic abstractions for accessing stored data<br /> - address space &lt;--- assumes random access is fast<br /> - file &lt;--- assumes random access is slow<br /> <br /> In an address space, there is no assumed pattern to which addresses will be access in which order<br /> - but in practice, sequential reads are faster!<br /> (not part of the abstraction)<br /> <br /> But with files, assumption is that any application will only access a small fraction of the files on a system<br /> - and, it will want most of the data in those files it accesses<br /> <br /> <br /> address space: address -&gt; byte (or a word)<br /> filesystem: /path/to/a/file -&gt; stream of bytes<br /> <br /> file systems are implemented on block devices:<br /> - block number -&gt; block contents (multiple of 512 bytes, typically 4K or 8K)<br /> <br /> UNIX abstracts I/O devices into character and block devices<br /> - character devices are not cached<br /> - not necessarily accessed character by character<br /> - block devices are cached<br /> <br /> What is cache?<br /> - a cache in CS is faster storage that is used to<br /> store copies of data from slower storage<br /> <br /> Operating systems cache files in RAM to make access to them faster<br /> <br /> So what&#039;s a filesystem?<br /> - data structure for mapping pathnames to data<br /> - typically designed to be persistent and stored in sets of blocks stored on SSDs or hard drives<br /> - but could be anything that can map pathnames to data<br /> <br /> When you make a filesystem on a block device, you are &quot;formatting&quot; it, i.e., you&#039;re initializing a data structure for storing files<br /> - if there was an existing data structure (filesystem), it isn&#039;t there anymore even if most of its data is still technically present - you can&#039;t access it anymore!<br /> <br /> But what if you don&#039;t want to use the whole block device for one filesystem?<br /> - or, what if you want multiple devices to be combined into one filesystem?<br /> <br /> We can split block devices up using partitions<br /> <br /> We can join block devices together using logical volume management<br /> <br /> What is mounting?<br /> - associating a filesystem with a directory<br /> - so files and directories in the filesystem<br /> now appear under the mountpoint directory<br /> &lt;/pre&gt;</div>

Soma