https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=Operating_Systems_2020W_Lecture_12 2026-06-02T22:26:50Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=Operating_Systems_2020W_Lecture_12&diff=22577&oldid=prev 2020-03-20T02:34:40Z

<p>Created page with &quot;==Video== Video from the lecture given on February 14, 2020 [https://homeostasis.scs.carleton.ca/~soma/os-2020w/lectures/comp3000-2020w-lec12-20200214.m4v is now available]....&quot;</p> <p><b>New page</b></p><div>==Video==<br /> <br /> Video from the lecture given on February 14, 2020 [https://homeostasis.scs.carleton.ca/~soma/os-2020w/lectures/comp3000-2020w-lec12-20200214.m4v is now available].<br /> <br /> ==Notes==<br /> <br /> &lt;pre&gt;<br /> Lecture 12<br /> ----------<br /> <br /> * Assignment 2 hints<br /> - Q3<br /> - Q1<br /> - Q2<br /> - Q4<br /> - Q6<br /> - Q14<br /> - Q17 walkthrough<br /> * Assignment 1 solutions<br /> <br /> You cannot decide between physical and logical sizes based on which is bigger.<br /> - because of coarse allocation (can only allocate in blocks), physical size can be bigger than logical size<br /> - but files can have holes, which means logical size is bigger than physical size<br /> <br /> <br /> RAM means addreses (pointers), code + data (variables, etc) in a process<br /> - they go away when a process terminates<br /> <br /> logical/physical size refers to properties of files (data stored persistently<br /> on disk, referred to by a filename)<br /> - can figure out both based on info in the inode of a file<br /> - fstat/lstat tells you about inodes<br /> <br /> a hole in a file is a range of null bytes (zeros) that aren&#039;t explicitly stored<br /> in blocks on disk<br /> - instead, there is just a note that &quot;byte range X-Y is all zeros&quot;<br /> - why bother allocating blocks for zeros?<br /> - if you write to this part of the file, blocks will be allocated<br /> (allocation is thus lazy)<br /> <br /> <br /> RAM is allocated with sbrk, anonymous mmaps, and malloc<br /> disk space is allocated with file operations (open, read, write, close, seek)<br /> - mmap can be used to map disk files into ram, but the size of the file<br /> is then fixed<br /> <br /> Midterm is on Assignment 1 and 2<br /> <br /> du reports physical size of files<br /> <br /> <br /> &quot;one trillion zeros&quot; &lt;--- how many bytes does this consume?<br /> <br /> note all files have to take up some space<br /> - for their inode<br /> - so &quot;holes&quot; can be stored in an inode sometimes, depending<br /> on the design of the filesystem, or maybe just using one data block<br /> <br /> How do you get files to show up in lost+found?<br /> - you lose a directory<br /> - no directory means no names for files<br /> - but if those inodes are still allocated, fsck will find them and say<br /> &quot;hey, I have these allocated inodes but no filenames for them.<br /> I don&#039;t know where they belong so I should put them in lost+found&quot;<br /> <br /> - ideally, make lots of directories and files<br /> - I suggest rsync -a /etc &lt;your mountpoint&gt;<br /> - will get you lots of files<br /> - make sure your mountpoint is writable (after mounting)<br /> (do it as root or change the ownership of the directory in the top of<br /> the filesystem to be your current user)<br /> - then study the structure of the filesystem using dumpe2fs<br /> - find out the group number based on inode<br /> - find inode table blocks for that group<br /> &lt;/pre&gt;</div>

Soma