Clock all as well, why don't we get cranking on this? Again, I'm Carl, if you don't know that already. And what we're going to be starting on today is the last part of the semester, if you will. So we finished up with virtual memory. And I'm actually going to be taking the first lesson of disk drives. And if you will, storage systems. That is to say, storage that is persistent when you flip off the power switch on that. And Jeff should be here throughout the rest of the semester. So I appreciate having had all of you. But let's see what we can talk about as far as I guess I'm going to see if there's any lingering questions about virtual memory. See if I can't answer any questions about, if you will, assignment 3.1. Remember, that thing above is do this upcoming Friday for core map. If you have not, let's see, if you are behind, as Jeff already sent out an announcement about this, do prioritize 3.1 over 2.2 if for no other reason that 3.1 does not require 2.2 on this. So if you still have a janky, if you will, syscall stuff, make sure that this stuff is points under your belt before you go on. And then 3.2, obviously, is going to need to have both a working 3.1 and a 2.2. But at least you want to make sure that you do first what is do first on this. So again, midterm, last Friday on that, that is currently in the process of being graded. Please be merciful on us. Staffers are going to have a fun week for the next week or so. So we're going to try to get this back to you. Ideally, well, definitely it has to be back within two weeks, possibly a little bit sooner, no promises on that. And we'll certainly have grading rubrics about that too. But in the meantime, start focusing on 3.1 and the rest of the class on this. So I'd say just kind of questions I can answer about, if you will, just like Cormap, virtual memory, anything kind of lingering from. I know there was already the one. Any other question? Yes. So if you have a Cormap. OK, the question is, in Cormap allocation, let's say that we have, let's say, a request to allocate pages for, let's say, two or three pages. Your question is, do the underlying physical frames have to be contiguous also? It's in Cormap. OK. Actually, yes and why? Why do they actually? Remember, this was one of the issues we were talking about in terms of, if you will, different types of address spaces and different ways of implementing that.  Well, actually, it's more than that. It uses segments, which is multiple base and bounds on this. Why is it that if we have a request to, if you will, Cormap allocate pages with, let's say, n equals 2, that we have to find two consecutive physical pages on this? We have two consecutive virtual pages. And we all know that the whole point of virtual memory is to try to get around that limitation. But we're kind of taking a step backwards, aren't we? We're saying, in the case of allocate pages, we also need two physical pages on this. Ideas? Think about the MIPS processor on this. How is MIPS addressing memory when it's in kernel mode? Yes? Yeah, the offset calculation. Everyone hear that? OK, Dave's exactly right about this. When we're in kernel mode, well, there actually is a way you can use the TLB. But we're going to kind of ignore that for the purposes of OS 161. For practical purposes, when you're in kernel mode in OS 161, all virtual addressing is done through the simple offset direct mapped, which tells you what? Since it's 1 to 1, if you have consecutive virtual pages, therefore, you have to have consecutive physical pages, because it is simply a plus or minus by a constant. Everyone understand that? OK, so again, there's pluses and minuses to different types of virtual memory. And remember, one of the nice things about, if you will, base and bound, and like this offset, is it's very easy to implement, and it's quick to calculate. You don't have to fuss around with the TLB. But one of the downsides is that it still has the problem of fragmentation. So good question. Sorry about the long answer to that, but nutshell version is that, yes, you have to have consecutive physical pages on this. So I'm sorry. Yes. Is there any way that that will lead to it? Most definitely, because as a matter of fact, let's kind of tie that in with assignment 3.2 on this. Let's say that in designing my data structures, that IK Malek who knows 100 pages of virtual memory on this. What is that going to tell me? I'm going to have to grab 100 pages of physical memory on this, which, depending upon the memory pressure of the system, is definitely going to lead to inefficient organization and fragmentation on this. And eventually, it could get to the point where I'm going to have to start rejecting requests. Because I could have, let's say, 200 physical frames available, but they're scattered throughout my core map on this. As opposed to I need, let's say, 10 consecutive pages, and none of them are consecutive. So I have to return, if you will, an error to the caller on this, because of exactly this problem. Does that answer your question? Yes. So what's it meant? OK, well, you're ahead of this. OK, now if we take another step and go to, let's say, swapping. Let's say that I want to, I'm under memory pressure, and I have a request for, let's say, 10 virtual pages through alloc k pages on this. So I now know that I need to allocate 10 consecutive physical pages on this. So I'm going to have to find 10 consecutive physical pages in my core map. Does that sound like an easy task? I'm already under memory pressure. And remember, Jeff talked about in the last class before, the midterm quiz, about eviction policies.  So do we have a problem? Houston says yes. So the TLDR on this is make it easy on yourself in terms of designing your data structures on this. And I can tell you right now, aside from the tests that Jeff is going to be running for assigned at 3.1, there is no place else in OS 161 that directly requests more than one, if you will, physical frame at a time. And don't you do it either, unless you want to make work for yourself later on. You can get by with it for assignment 3.2. But excuse me, when it comes time for, if you will, assignment 3.3 and eviction, essentially when you're under memory pressure on this, you're going to really paint yourself into a corner. So the nutshell version is make sure that all of your own k-malach requests are going to be, if you will, a page frame or less in size on this. And it's going to make life a lot easier. This is actually a real, this is not just academic. In Linux, there is, or Linux, if you will, or Linux, or whatever your religion is, there is actually a bit of a holy war that's been going on for quite a while in terms of the size of the kernel stack for a particular task, as they call it. Should it be 4k, or should it be 8k on this? And as you can already see, this would actually be a kind of a good final exam question. What are the pros and cons of 4k versus 8k stacks on this? So and again, we're assuming that, if you will, the hardware level implementation is still a 4k page, such as you're already used to with MIPS on this. Well, when you're talking about getting an 8k stack on this, it sometimes does create problems. And this is in, if you will, a real life production operating system. So again, yes. This is due to a limitation of direct map addressing that, yes, we have to get contiguous pages. Now, there was another question that was asked before, and Alzheimer's is setting in. Who was it, and what was the? What was it again? Kid 2. Oh, OK. Yes, OK. Quick version on this is, hey, wait a minute. I thought the whole purpose of assignment 3 is that that's what, if you will, finally starts freeing memory on this. But can k free, let's say, if you will free memory even during assignment 2? Yes, it can. If you will, there's two levels to getting memory in essentially not just OS 161, but any system, if you will. In other words, if I want to get, let's say, 8 bytes, I call, let's say I'm in a kernel, I call Kmalik, give me 8 bytes. And Kmalik checks its own internal storage if you will memory that it's using. And if it has 8 bytes to spare, it simply returns that memory to the user. And when you call k free on it, it will actually be reclaimed by the Malik free routines on this. When it needs, it runs out of its own internal storage, then and only then goes to the frame allocators. That's the alloc k pages and free k pages that you people are writing as part of assignment 3 on this.  So in other words, in dumb VM, we have an initial request for one 4k page. We always have to start somewhere on this. But once we have that, let's say the calling user says, give me 10 bytes on this, and then later freeze it, that will actually be reclaimed by the system on that. Where it will not be reclaimed is, let's say I get to the point where the Malik and free routines decide that I no longer need an entire 4k page.  And remember that cute little comment, it says, do nothing. That's where the memory leak occurs. So as long as you're not returning 4k pages, yes, you actually do return memory, even with assignment 2 on this. So to a certain extent, yes, you're even reclaiming memory. But obviously, eventually you will kind of bump the system because if you, let's say, run a bunch of processes each time you fork off a process, it's going to require certainly much more memory than you can accommodate with just a few bytes. Other questions I can answer about? Memory, assignment 3. In case of swapping out something, does that mean that if I want to swap out, say there will be a allocated 10 configures to us. If I have to choose, I cannot, there will never be a possibility that half of it is swapped out. It has to be from the beginning. Not sure what you're asking. In other words, if I need a service or request, is this from user space or kernel space? Yes, in user space, I need to allocate more space now. But there is no space available in physical memory. So say the policy which I used to swap out something, chooses a page, can it ever choose a page in the middle of, say there are 10 configures to us, can it ever choose a page, say in the fixed block? Right, I think what you're talking about is when we're in user mode and we have a request for, let's say the user, if you will, wants to, let's say, malloc 10 pages, if you will. What's going to happen is, remember, you're going to have to implement on-demand paging, is what it will work out to. But you're going to see a series of page faults on 10 consecutive pages on this. But since this is actually something that can go through the TLB and we can redirect the addresses, the underlying physical pages do not need to be consecutive on this. So that's why it's going to be much easier for us to surface, if you will, a request from user mode that says, give me 10 pages on this. Even if I did, it's possible to allocate it, if you will, all at once. But I could say, let's redirect this page to this physical frame, this page to that physical frame, and set up the TLB to make it appear as if it is, if you will, continuous in memory. All righty? And that is actually one of the key points of Assignment 3.2, yes? So I want to understand, when you mem copy, so when you're copying memory from the parent address page to the child address page, how is the address being part of the parent physical address and the child's physical address? Ah, good question. This is something that you're all going to have to tussle with in Assignment 3.2 and much more in Assignment 3.3. In general, you only have to worry about handling one address space at a time. But there are some corner cases, one of which is, if you will, AS copy on this. How do I fork? Obviously, he's going to be calling AS copy. I need to move the contents of memory from what's in one user's address space to another user's address space on this. So how can I actually do it? Well, quick version is take a look at how DumbVM does it. And that will actually, it's a clutch that works kind of for Assignment 3.2, but it will definitely cause you problems when it comes time for Assignment 3.3. DumbVM, I saw it, it uses a macro called PIDAC, KVM, I think. All that does is that switches the address from physical to virtual on this. But it calls directly down to, I think, it's either mem move or mem copy or something like that. So all right. Yes. Now, that will work for Assignment 3.2. It will not work for Assignment 3.3. Why will it not work for Assignment 3.3? What does mem move assume? We are moving from what to what, yes. Yeah. Problem with Assignment 3.3? Yeah. In other words, what might be my source might not be in physical memory in the first place. It might have already been evicted out to someplace on the disk drive. So that's something that's going to be a case that we're going to have to handle when it comes time for the last part of the assignment. Yeah. Take a look at how it's handled, essentially, for 3.2 and then take it. These are good questions on this. Probably one last question, and we can scoot. Yes. Well, when we say we're copying an address space, remember what's really going on is we're copying the values of the underlying data as they appear in the same virtual addresses. What we're really doing is we're grabbing different areas of physical memory. So we're doing a mem copy from one physical memory to another physical memory. But within those two address spaces, the virtual addresses appear to be the same, albeit to two different processes. Answer your question? That's a design implementation. That is one way of handling it. In other words, if you have, let's say, AS determines that it has to copy from data that currently resides on disk, I could, in effect, simulate a page fault and say I need to pull it into memory. I could also, let's say, maybe set up some sort of a kludgy buffer. Another way of doing it in production systems is, you know what, I'm just going to leave that bugger on disk. And I'm going to take the page of the target process and also point it to the same thing on disk. So I don't have to do anything. Again, procrastination pays on this. So that's very much a design implementation. All righty? These are really good questions. It goes to show I think you people are thinking a lot. I would say when it comes time for assignment 3.2, even more so, have the staff review your design documents before you start coding too much on this. I don't want you to go down to a wrong rabbit hole and you have to back off on this. So sit down with your partners, come up with a rough idea, and as soon as you can, grab one of the staffers or maybe two of the staffers and say, take a look at this and let me know what's good, what's bad, et cetera on this. All right, on to hard drives.  Terminology, again, up until now, if you will, memory is something that loses its contents when you flip the power switch off. So we need a way to preserve contents. We also need a way to store a lot of values because, roughly speaking, hard drives are a lot bigger than memory and they're certainly more persistent than memory on that. And when we say hard drives, I'm going to be a little bit sloppy but Jeff is already distinguishing here. Hard disk drives is in mechanical things, the things that spin around and solid state drives which is really a type of memory but for the purposes of this class, going to treat it as a type of hard drive if you will, stable storage on this. So, what do we have here? We've got the two different types here and then flash, if you, it's, and there's some, yeah, here we are, there we go. Trade-offs between the two. You can think of flash memory as being kind of a halfway point between typical dynamic memory and mechanical hard drives, which is to say that mechanical drives, well, they are bigger, they're slower and they're cheaper but as Jeff is saying here, that gap is closing. It's not been erased entirely on this that mechanical drives are continuing to get bigger and faster but flash drives are beginning to catch up. Even if they do catch up in terms of cost, there's going to be some other issues though that we're going to get to at the end of this class though that you need to kind of keep in mind in terms of implementation. You probably heard a lot about wear leveling and the asynchronous read-write access times. This is something that designers of file systems have to be aware of. So there's still some advantages to mechanical hard drives and in any event when we design our file systems, we need to kind of optimize things for the particular strengths and weaknesses of our storage substrate on this. All right, well, why study spinning as inning discs here? Yes, flash is the future but probably hard drives are never going to go completely away. Even in the way there are still in some data centers, dusty tape backups that are still being used and those should have gone the way of the dodo a long time ago but you still see them around. Hard drives are going to be around for a good long while on this. Now, this next point here. Hierarchical file systems are dead, long live search. What's Jeff getting at with that? Hierarchical file systems are essentially what you would call a file system. Something like NTFS on Windows or X4 on Linux or what have all of those are examples of hierarchical and what we mean by the hierarchy is it has a concept of a root directory and subdirectories on this.  That's the classic file implementation. It's a great way of organizing things. However, it does have its limits. Especially we're kind of getting to the point where with huge globs of data it's not all that user friendly on this. You people when you have been coding for OS 161 have you and like what's the name of that function or where can I find out more about something? What do you do? Do you vim every file in the OS 161 tree? You probably use this thing called grep. That's where I first discovered it myself. I was forced and that's what Jeff is getting at here. Grep and the unit command find. Remember find dot and slash named to find a particular file. What that allows you to do is in more human friendly terms search a blob of whatever it is data code for stuff in a way that is not necessarily hierarchical. I don't need to know what the paths are. In other words, I wanna know something that has to do with core map. Well, where is it? I can grep my source code and it's gonna tell me what these files are and I can just I don't care about the path I'll just kind of copy pasta and jump right to those files. So that's what Jeff's talking about here. Search is becoming certainly more and more important and from an end user non-technical perspective end users do not give two hoots and a holler about what subdirectory they are in. They simply wanna know where are my spring break pictures on this? Is it in this folder or that folder or wherever it else? I don't care. Now the thing is you're going to as technicians still going to need to know about if you will file systems because that's still what's going on under the hood. I don't know how much longer that's going to be going on but when you issue grep, grep is a Unix command that, guess what, runs with a file system and it calls internally sys open, sys read, reads through the file, pipes it, all that stuff. So it still needs to have a pretty good and efficient file system underneath that. So it's not something that's going to be going away anytime completely soon. Next point here, just talking about is when we're going to different storage substrates, again, this is an allusion to the move from mechanical rotational devices to flash drives, that is definitely going to, it already is having a big impact in how we design our file systems on this because a lot of, let's say, we've got problems with rotational drives, namely the fact that they can crash a lot more often. We've got certain types of delays with mechanical drives that we don't have with flash drives and vice versa on this. Well, the traditional file systems have been written with the old storage substrates in mind and those may no longer, if you will, be useful as a matter of, that's one of the things that I have been bashing my own head against a concrete wall in phone lab for the last and decades and that is we've got these things called Android phones that essentially what Google did is it did a drag and drop of a traditional Unix file system. We've got Linux and we've got the policies that were originally developed for a desktop with spinning mechanical drives and we're now using them for mobile phones with soldered in batteries and completely flashed storage substrate and we are finding this is actually kind of a search hole that's out there. You can really bash Android or for that matter anything like that because you know what, this is not optimized for this. Of course it wasn't designed for this, it was designed for that. So that's one of the things that just trying to get at here. Different, if you will, hardware should lead to different types of policies on this. Make sense? What's new? I guess not. All right, but even though we are evolving in terms of types of technologies what we're trying to say here is let's look at very abstract design principles and maybe that's going to help us come up with better ways of approaching things like flash storage substrates here. Next part here. Let's actually deconstruct in this case literally a mechanical hard drive. What are we talking about? We've got a platter. You know that silver thing of a big that spins around internally if you've ever opened up a mechanical hard drive. Spindle, that is, well that's the thing in the middle along which the things spin. And it spins and spins 4215,000 RPM. By the way, those numbers have not really changed in recent years which already alludes to some of the problems we're getting towards. We can improve certain areas of disks but other areas are really not changing all that much. The head that is if you of the, like the read-write head if I'm really dating myself back to days of tape recorders and cassettes and reel-to-reel well that's the thing that reads the mechanical substrate on this. And the platters, well that is, well it's here, oh and as Jeff says let's just take a look at a picture. This by the way you can already see how old this is. It is an IDE connection right down there about the spindle, okay and then the thing spins and spins right here.  So you can already see that's kinda intricate. Yeah it is. Which is why you get all these warnings about thou shalt not drop and be gentle when, if you will, putting your laptop down. Oh by the way if you wanna have some fun these rare earth magnets are wicked strong, right?  One of the reasons why they did that is, I speak from experience, right? Alright, terminology on this and this is something that you do want to commit this to memory. It's not a whole lot but these are definitely gonna show up on the final exams. Tracks, those are the things that, well track, sector, cylinder. The cylinder, that is, well, back in the Cretaceous era when I was dealing with floppy disk drives there was only one platter and so what we used to talk about was a track and a sector and well we essentially did not have things pancake on that. So it was simply one track but now what's happening is we've got a bunch of pancakes with multiple tracks so three dimensionally it kind of looks like a cylinder. Make sense? So you may have heard like cylinder and track are interchangeable, it's just that the cylinder is the 3D version of what a tractor track is. One last thing, if you are taking notes on this you've probably heard the term block that is a virtualization of this. In other words, these terms here track, sector and cylinder refers to what's actually on the physical disks as opposed to we are going to virtualize it in terms of how it appears to the software by simply instead of twiddling around with these tracks and sectors and cylinders by the way you used to actually have to do that. Poor me, I used to have to when I was programming my Apple to tell the disk drive specifically which track and which sector and move the stupid disk arm myself by calling there were actually software switches to turn on the step motor for this phase, yada yada yada. That's all taken care of in firmware. Thank your friends, the computer engineers for doing that all for you because it's essentially something you don't wanna have to deal with. The hard disk drive manufacturers know this stuff a lot better than let's say someone who is a software systems designer. So all of this at a certain level gets abstracted out and rather than specifying a specific track, a specific sector in a specific cylinder or what have you, we just say give me block one million or one billion or one trillion. I do mean one trillion because let's face it these things get bigger and bigger and bigger. There we go, disk drive location diagram. This is one pancake and you can see your track cylinder. There's some differences, for example, this particular diagram implies that we are using, what is it, constant, well actually I shouldn't say that. Essentially we are not packing more sectors on outer tracks than we are on inner tracks. That's one optimization that sometimes comes into play and that's something that for the most part you don't have to worry about but it's out there. Do we want, let's see here, maybe YouTube fun video time. Let's at least get this thing started a little bit. Okay, we get that, okay, come on, come on. So the rocket is beginning to take off. Everyone hear that? It actually does sound like that and it's probably this person was reading a file or what have you. What's happening right now, I mean stop that right there, is it is probably getting some sort of metadata and then going to the data or maybe it's doing some mini copy. If you see it going back and forth, back and forth, back and forth, there's probably a reason assuming there's not a bug at work. It's getting some data from one thing and then maybe either writing to the other thing or maybe getting metadata about let's say a directory and then going back, what have you. So that's actually why the thing is moving. Now let's see here if I can, let's move it. Okay, copy pasta, there we go. Another example, because we are probably grabbing from one area and then moving to the other area. Now you can already see what's one way of optimizing this if at all possible.  What does that tell you about the time interview? If you can see and hear the movement, exactly on this. So if possible, we might want to and Jeff is going to be getting on to this later on, how can we design this to maybe keep the stupid arm movement to a minimum? Maybe kind of keep the target area around the source area. That's not always possible, but it's something we want to keep in mind here. Oh, quick, I don't know what that means. It doesn't make, okay, so it moved once, whoop-de-doo. All right, come on, there we go. That was video number one. Spinny disks are different and what we are getting at here is, well, they move. At least we hope that's the only thing besides the fan on your system that moves. Otherwise there's problems. We already talked about that, they are slow. And by the way, when I say slow, make a mental note of this, they are, there are different degrees of slowness depending upon the type of movement and that also is going to impact some of our file system design here. Integration, what Jeff is saying here is essentially, they're less tightly coupled because, well, you can pull out, your people probably have much more frequently swapped out hard drives than you have memory sticks and much more frequently swapped out memory sticks than you have, let's say CPU sockets on this. So that's literally true, but it also means that more of the goo for file systems or more of the detail is implemented in software as opposed to some of the other areas we've already talked about this semester, specifically the CPU and the memory on this. In other words, there's part that's implemented in hardware and part that's implemented in software, but again, partly due to the fact that these things are so slow, well, that's already a hint. The operating system can keep up with a hard drive. As a matter of fact, it can more than keep up with a hard drive. That's not true of, for example, memory. Remember, Jeff's slide about we need help, that's the whole purpose of the TLB, that it's way too slow for us to be able to do virtual to physical address translation without help of hardware. That's not true in terms of the disk drive. While the disk drive is moving that arm, we can do lots of stuff. And actually not just we can do, we have to do, because we have no choice, we're waiting for it. So we wanna make sure that space is, that time space is used and used well. Electronics fast, mechanics slow. Well, obviously the entire computer fails, but well, hard drives fail a lot more. And certainly in my net admin days, I remember coming in one day and opening the server closet and click, gotta click, gotta click, gotta click, gotta click, gotta click, gotta click. Well, it had been going on all night, yield click of death. So those of you who are net admins, I'm sure have heard about these things fail. So, I should say this too. Disk drives are so big that essentially it is impossible to make a disk drive without, not just some errors, but probably lots of errors on this. So it's actually built into the manufacturing system that disk drive, if you will, people like, was it Seagate and what are the other ones that they're doing under Toshiba Hitachi, they essentially assume that there's going to be end percent of sectors that are just not gonna work from the get go from the assembly line on this. So they build that into their firmware on this. In addition to that, it's a given that there will be a slow leakage of sectors deteriorating. I'm not talking about when the drive finally goes bonkers. What we're getting at with this particular bullet point is while the disk drive is still in use under warranty, you don't even know it. Probably every few days or so, another sector buys the farm on your disk drive. But the thing is, it's internally and silently remapped. And the data is recovered through error recovery techniques. I don't know if Atria is still offering his, he had a nifty course, I think it was like 454, whatever it is, about error detection and recovery on this, where you can, through software and software routines, recover before the sector completely bites the dust on this. So there's actually degrees of failure on this. And again, this is all implemented in the firmware. You don't have to worry about this.  And this is of course the big one, the head crash on this. And, oh yeah, look at this here. So, this is, okay. Come on. When we know that, come where is it? Where is it? Oh, I'm not, okay, I'm nothing. There it is. This is not supposed to be there. It looks like it's a pretty design, no. That is where the goo was already, and by the way, when I say goo, I mean your precious pictures and videos and other unmentionables were physically scraped off the disk. And as the narrator says, you know where that actually winds up? There it is. This thing I'm a bob right here is, well, it's essentially a fancy-schmancy air filter that equalizes air pressure on the inside so that literally your hard disk drive does not explode when you ride an airplane. But on the other hand, it keeps out dirt and other stuff. And all the goo, your precious files from here are now over there. They were vaporized, literally vaporized. And good luck getting that back. Coda to this, the narrator says at the end, always back up.  So, I know Jeff has a saying that there are essentially two types, if you will. I guess it would be one, oh, and binary. And it's like people whose hard drives have not crashed yet and people whose hard drives have already crashed. So, it is what it is. So, oh, and by the way, this also influences file system design on this. What can we do?  Maybe there's some things that we can do in terms of file systems to kind of maybe minimize stuff. And let's say if, let's say the user unplugs the computer or something like that halfway in the middle of writing a file, how can we make sure that even if that file is toast, we don't deep toast the entire disk on it. Why is my clicker not working? Oh, I have to click here, okay. Come on, there we go. Handling failures. Okay, RAID will be covered in another lecture. But essentially since these disks are so prone to failure, we've basically come up with an idea is let's take a whole bunch of these disk drives and put them together for redundancy and possibly speed and some other stuff on this. So, this is actually something that has inspired a lot of design principles on this. And I should say a lot of the stuff when I was talking about disk drives being so big and error correcting, that's also increasingly true of memory. It's not as far along, but we're starting to see that. In other words, if you have terabytes of memory, you can almost guarantee that there will be bit flips that are starting to happen on this. For those of you who are math nerds, you probably know that every few years, or I shouldn't say that, but there's competitions within the mathematics community to compute the value of pi. So, they literally have, let's say, hundreds of gigabytes, terabytes worth of storage on this. They're doing these calculations. They assume that there is going to be errors. Computers, yes, will commit errors. Not that they're trying to, but there will be a bit flip in the memory and they have to be able to handle that, detect it and recover it on this. So, again, Jeff's point here is that disk drives, because of their size and their nature, we're gonna have to deal with a lot of indeterminacy in ways that we didn't before. That's also starting to seep into computer system design in other areas too. We already talked about this. They're slow. As a result, we're going to, hey, look at this. Use the pass to predict the future. We already have talked about that with respect to the eviction algorithm, but with respect to the underlying file system itself, how can we actually optimize things? In other words, if we know that we're reading part of a file and let's say the user has accessed file B after file A in the past, maybe we should kind of pre-read file B when the user reads file A. There's stuff like that that's going on. Increasingly, it's even starting to use AI. Use a cache. In other words, memory is faster than disk drive. So again, let's kind of read ahead procrastination. So again, these are all techniques and themes of OS 161. Again, a great final exam question would be, take something like one of these three things, like procrastination or cache or whatnot and explain how it applies to different systems. In other words, give me an example of how it applies vis-a-vis the file system and maybe how it applies vis-a-vis the memory system on this. So what we would be looking at is can you take these general themes and apply it to different areas of the system overall? That's a real good question that's been asked before. All right, more on slowness here. All right, and again, the thing to keep in mind with slowness is there are degrees of slowness here and what do we have here?  Read or write, seek time. That's, we have to move that lovely arm to the track that we want to go to. Then, well, okay, it's on the track. Well, not quite. Remember Newton's law here. So we're moving, well, it's probably gonna overshoot and then gradually settle in. So that's our settle time and then rotation. Just because we've moved the arm, well, remember we've got that thing, that spinning thing, spinning and spinning? Well, who knows what sector the head is currently over. We have to wait for the thing on average to spin halfway around. And while we're doing that, we're twiddling our silicon thumbs on this. So this is essentially why we have to consider IO, a blocking operation on this. And transfer time. This is the fastest of them, but it is still a lot slower than we're talking about in terms of CPU on this. So questions about these types of times here. This might be a good short answer question. Describe the different types of slowness, if you will, to hard disk drives and compare and contrast them. All right, now, obviously it's slow. The hardware engineers are working at improving this and they are getting improvements in all areas, but at different rates. So interconnect speeds, yes, we can see that's already a little dated on this, but yes, interconnect speeds do go up. Seek times, that is actually not improving rapidly. That's one of the worst areas where they are improving really in linear order. So in other words, if the seek time was one 10 years ago, it might be 1.8 or 2.3 today. So not a whole lot of improvement on seek time on this. Dave, I don't even wanna jump in on that. I don't think it's, yeah. Yeah, what's this? Rotation speed that I know has essentially stagnated on this. Well, you do have, well, in other words, you've got like, what is it, 7,200, 10,000 and 15,000. You've had more, excuse me, have to switch to a filtered brand. You have to, let's say, the rotational speed, you can go from, let's say, 7,200 to 10,000, but eventually it's not going, they're not gonna change from, let's say, 10,000 to 11,000 or what have you. All right, IO crisis here, okay. On the one hand, some things are improving and this definitely continues to improve quite rapidly, even with mechanical drives and that is the amount of storage that you can cram onto those things there. So just think about all those very legally obtained torrents that you have on your hard drives. There's a reason why we have space for them, namely the drive densities have really gone up. Seat times, on the other hand, will have not so. As a matter of fact, so in other words, capacity has gone through the roof. Transfer time has gone up some, seat times have essentially, they've belly flopped. So let's look at these two graphs here. This one here, we are, let's look at the years of, let's say, 91 through 06 and see, let's say, storage space here goes roughly, let's say, this is for, what is it, two and a half inch drive. We're going up one, two, three orders of magnitude, let's see here, I take that back, yep. So one, two, yeah, three orders of magnitude over the course of about 15 years. Contrast that with transfer time from 91 to 06 goes up from 0.7 megabytes to 64, so roughly speaking, two orders of magnitude on this. So, storage has gone up three orders of magnitude, transfer speed has gone up two orders of magnitude and seat time probably budged a little bit, not a whole lot, which is why today it is getting to be increasingly a problem of, let's say, you've got your four terabyte hard drive backing it up, and how do you actually do that, especially in data centers on this, how are we going to act, it's going to take hours, possibly days to accomplish it. All right, so, oh yeah, and what's happened to processors in that time? Well, it's gotten a lot faster, a lot faster too, of course, then processors started to stagnate. But now at least we have multiple process sores, we can parallelize things. My point is, throughout computer systems, some things are improving a lot, some things are improving a little, some things ain't improving at all, for a whole bunch of different reasons. And so, we in software have to work with the physical limitations that the electrical engineers have given us and kind of design our systems, in this case, the file systems accordingly on this. Alrighty, low level, okay. Ah, what we're talking about in this slide here is, let's see how we can get at this file storage substrate on this, we talked about, let's say, something like the CPU, we talked about dividing it up in terms of threads. We talked about, let's say, memory, we're gonna divide it up in terms of, let's say, physical pages and virtual and physical addresses on this. We're gonna have a similar abstraction in terms of the underlying disks. This is what you get to write or read from the software level, and this has been true for probably about 15, 20 years now. The only thing that you can essentially do is tell the disk drive controller, I want to read or write x virtual block, and that's it. You don't get to peek at the underlying disk geometry. Hopefully the hard drive manufacturer, this might be true in server systems, might give you some hints about, let's say, these batches of blocks typically match to consecutive areas, but there's no guarantee because we might have to do some automatic remapping or what have you on this. So this is essentially all we get to see on this. So that's actually everything else. Above that, we're gonna have to implement in hardware. So the stuff about cylinders, tracks, heads, that's all hidden. The lowest we can see is one 512 byte block. On that, we build lots of other goo, and that's things like files, file metadata. Can it be read or written? What type of file is it? Is it a directory? Where is it in the directory? All that stuff. And what we're trying to get at here is the file systems, if you will, there's a lot of stuff, relatively more stuff is implemented in hardware as opposed to software. Obviously there's still stuff that is implemented in hardware, namely the abstracting away of cylinders and heads and whatnot, but we're doing more and more cutesy stuff in software. And that's what Jeff's gonna be talking about. One last thing here, flash. Flash has pros and cons on this. We don't have any moving parts, but we've got other problems here. We've got problems with we're leveling, and we've got problems with asynchronous IO on this. And that's gonna be something that we're gonna have to kind of keep in mind on this. In other words, reads are a lot faster than writes, and we gotta be careful that at a certain level that we don't continuously write to the same area. And whether or not, well they call that wear leveling, if you will, some of that, it could be implemented in hardware, it could be implemented in software. My guess is as time goes along, we're gonna see more and more of this implemented in hardware, and we're going to forget about it at the software level, but we still need to be aware of it, if you will, at the administrator level. Questions? Oh yes, scheduling algorithms. How about that? We talked about CPU scheduling algorithms. Up next, IO scheduling algorithms. Questions? Thanks people.