 You good? Sweet. Happily, most of the things in that song don't apply to me, although I do have a dog and a cat. And they don't fight too much, although when they fight it's cute. OK, so today we're going to talk, we've sort of talked about last time a fairly traditional file system design, an oldie but goodie, the fast file system. Today we're going to move on and we're going to talk about something quite different. And this is a fun example. Long stretch file systems are also pretty old and corrupt at this point, but it's a fun example of how a fairly radical idea about on disk layout was motivated by some changing technology trends. So we'll talk about that. And then if we have time today or the beginning of class on Friday, Friday we're going to talk about RAID. So I'm going to ask you guys to look at a very old research paper from the 1980s. So we'll talk a little bit about how to approach a research paper, since throughout the next month of lectures I'm going to start interweaving some sort of interesting research works with the remaining material in the class. So this is kind of a good starting point. RAID kind of comes at the end of us talking about file systems and it's an approach to storage that is both useful to know about and came out, emerged from a research project. So that's something we're going to talk about on Friday. OK, so the midterms are ready for you guys to pick up. They are in my lab, so if you come by during office hours, please ask the TA for help. They will retrieve your midterm for you. If you know your seat number, that would be helpful. If you don't, we have the mapping there. But they're all organized that way. So again, I posted this on Discourse, but please, if you want to ask a question about your grade or you think that we made a mistake on the exam, that's certainly possible. We're human beings and we do make mistakes. Please come to us prepared to make an argument that is stronger than I don't like my grade on this question. Go through the midterm, go through the rubric, and make an argument based on the rubric saying, OK, I should have gotten two more points on this question because I actually think I answered this part and you didn't see it or whatever. And talk to the TA who actually graded the exam. So I also think we should give Ali a round of applause for grading the exams. Pretty much all he did for the past couple of weeks. And he was very careful and very thorough. But again, I mean, we make mistakes, so that happens. But please, as you go about this process, keep in mind that the goal of giving the exams back and providing all this feedback is to help you guys learn. So approach it in that way. Overall, the scores on the exams were fine. I can't remember. I think the median was like a 33 out of 50. I'm happy with that. So this was not the train wreck that we had last year. The overall scores in the class are always, when I sign grades, I do it at the very end. And we look at the overall distribution of scores and that changes from year to year. So the class is quote unquote curved on some level, whatever that means. But I don't assign the letter grades for the midterm. So it just gets factored in with everything else. OK, any questions about file system stuff, disk stuff, FFS? Anything up to this point on storage? We're almost done with storage. After Friday, we will be done with storage. We're going to move on and talk about other things. Yeah, Steve? Last week or last time you mentioned how EFT4 is kind of, where does it start to differ from previous? Yeah, so I mean, I would say that FFS is a template that was followed by a lot of what you might call sort of traditional file system designs. That's a great question and I don't know the answer. I don't think that EFT4, well, EFT4, for example, gets away from a lot of sort of, I would argue, the really gross rotational planning that FFS had to do. At this point, remember we were talking about those issues where you had to skip over sectors because I couldn't write fast enough, that's all solved. I mean, new buses are fast enough that that's just not an issue anymore. But there are certainly a lot of the feature set of modern file systems. And I would argue that general approach of EFT4 sort of inherit from FFS and other sort of traditional file system designs. In contrast, what we're going to talk about today is very sort of radically different. And hopefully you'll see that. That's a good question. Any other questions? All right, so FFS was circled in 1982. LFS came out in 91. So what's different about 1991 from 1982? Well, let's see, the top song in 1991 was Everything I Do, I Do It For You. Does anyone even know these songs? Eye of the Tiger? That's a classic, come on. Eye of the Tiger is a better song. So in that sense, 91 was a regression. Gandhi won the Oscar for Best Picture in 1982, A Silence of the Lamb. So in that sense, where I think we're improving here, Gandhi's not a bad film, but come on. Has anyone seen those movies? Has anyone ever heard? OK, Sounds of the Land, people will see, maybe not Gandhi. All right, so what's different about discs? OK, 10 years have gone by. What do you guys think has happened in disc technology? This was probably before you were born anyway. So disc bandwidth is improving. This is due to improvements in disc technologies, improvements in buses, things like this. So I can get things faster. I can get more data off of the disc, and I can get more data to the disc more quickly. Computers have more memory. So this is also significant. So I might have a computer now with 128 megabytes of memory. Ooh, that's fancy schmancy. I think now like an Arduino has more than that. So this is also a big deal. What about seek times? What do you think has happened to seek times? Given our normal understanding of how seek times evolve, seek times followed Moore's law between those times, or anyone want to guess? Slightly better, but still slow. To some degree, this is the one part of this problem that we can't solve using better electronic or computer technology. It's a physical problem. So we've got better buses. We've got thinner tracks, a lot of different other ways that this has improved. But sliding the heads back and forth across the disc is just not getting that much faster. It's not going to. OK. So more and more the problem is seeks themselves. This is increasingly becoming a bottleneck in disc performance. So what can we do to improve this? Well, OK. And the problem, of course, here is that as bandwidth goes up, the seek impact becomes even worse. Because when I can get to the point on the disc where I want to be and do the reads or writes, I'm doing good. But getting there is still a problem. So I've got a bunch of spare memory lying around. What can I do with that? How is that going to help me here? Now that I've got 128 megabytes of memory, I might have a few megabytes free for what? What can I use that memory for? I already talked about this before. How do I use memory to make the disc faster? Yeah. Use it for a cache, OK? And that cache is going to help me, oh, hello. We already covered this as sort of review, right? So this is the buffer cache. And what is the cache particularly good at? Cache is going to really help me with one particular type of operation, not so much with another. Helps me with reads. Why not so much with writes? What's that? Because the writes actually have to get to disk, right? They have to make it to disk in order to persist. So for the file system to be consistent, at some point, when we talked about the trade-offs involved with how long I wait, I actually have to write the file system data structures to disk. So with great caching, I can potentially avoid a lot of reads. But I can't avoid writes forever. I can coalesce some writes using the cache if I want to be a little bit dangerous about things and wait to move it to disk. But at some point, I have to do that right. OK, so now here was the idea behind LFS. I've got a big cache. I'm going to use that cache to soak up a lot of read traffic. Let's imagine that I can use their cache to soak up a very, very high percentage of read traffic. Cache is big enough that reads can be somewhat slow because disk reads are going to be infrequent because I'm only going to have to read things once, get them into the cache, and then after that I'm good. I still have to do writes. This is the problem. So let's focus on how I can make these writes faster. Now, I can still use the cache to help me here because, like I said before, I can allow the cache to coalesce and combine multiple operations to single blocks and single parts of the disk. And then when I'm ready, write them out all at once so I can try to avoid as many cx as possible, but I still have to do the writes at some point. So now, try to, to some degree, to cleanse your mind of the way that EXT4 does block layout and the way that FFS does it. And just consider the following question. What's the best way to avoid cx when I'm writing data to disk? Yeah. Yeah, so the only thing about it is, write everything in the same place. Now, not exactly the same place because then I would lose a lot of information, right? But contiguously. So imagine I just write, write, write, write, write in adjacent blocks. That's the way that I avoid as many cx as possible because once I've completed writing one block, I'm in the exactly right position to write the next block. Now, if you think about how FFS and EXT4 lay things out, this doesn't work because the structures I need to modify are all over the place. The goal of LFS was to come up with a way to avoid as many cx as possible when writing. So LFS was, you know, this was an idea that sort of emerged as a research prototype by a couple of people out at Stanford. And here's the big idea here, which is that it's a log-structured file system. All the writes go to the one place, which is the end of a log. And that log is just something that I append to and append to and append to and append to over and over again as I change different things on disk. You might, that might raise some red flags. So we'll come back and talk about this. But, and so this sounds great. To some degree, this would make the best use of all this growing disk bandwidth I have because I never have to do cx. Of course, the problem here is how do I actually accomplish this? Okay, so let's say that I want to, let's talk about more traditional file system designs that don't do this. Let's say I wanna change one byte of a file. What are the steps that I need to perform? I'm going to modify one byte of a file. Just in general, what are the types of things I need to do? Yeah. Right, so I need to read, I probably need to read the block into memory. Okay, I can then at that point, I can make the modification of the cache. Okay, now I have a dirty block in the cache. Now what do we need to do? So I've done one seek to read the block. Okay, what's next? Right, so I update it, then I have to write the data block out. What else do I have to do? It's not the only piece of information on the disk that I need to modify, yeah. Yeah, I need to update the I node because the modified timestamp has changed. So I need to, and probably actually what I need to do to start, if we go all the way back to the beginning, is actually have to read the I node map because you need to find out where the I node for the file is and where the rest of the data blocks are. So I seek to read the I node, seek to modify the data blocks and all I have to pick up the data block. So I found the I node map, the I node, the data block, update the I node, okay. So what does this look like? So I get the I node map, I get the I node, I write the data block, and then I go back and write the I node. And so if you imagine my disk head and these in FFS like file system, these are at fixed locations on disk. They don't move. So, you know, now if I'm clever, I can try to put these things as close to each other as possible, but there's limits to do in that. All the I nodes are in the same spot or groups of I nodes are in fixed locations on disk, meaning that by definition, some of the data blocks will be close to that array of I nodes and some of them will not, you know, okay. So now let's say that I have this big friendly cache and that's gonna soak up all the reads. So now I can get rid of the seeks to read the I node map because that's gonna be in the cache. I can get rid of the seek to read the I node because I'm gonna assume that's gonna be in the cache. Remember the I nodes are in blocks. So, you know, one block of 4k, how does anyone remember how large EXD4 I nodes were? 128 bytes. So I can get 32 of them into one disk block. So as soon as I read any of the files within this area, I might already have the I node I need because when I brought in one I node, I also brought 31 I nodes that happened to be on the same block, right. Now I still have to do the modification to the data block. These are the writes. The cache doesn't help me here. Eventually I have to do these and I still have to update the I node. So these are the writes that I can't avoid. So what I've done is I've gotten rid of all the pesky reads but I still have one seek here from the I node to the data block. And again, there's limits to, even if I do very intelligent layout, there's limits to how close I can get these together. So what LFS does is it says, okay, I have this append only log that I've been using throughout the lifetime of the disk. When I need to modify something, where do all of the modifications go? Remember, LFS will only write to one location on disk. Where is that location? What's that? So only one spot on this slide where LFS will perform a write. It's right to the end of the log. So there's two writes I have to do here. What are they? I node and the data block. So, okay, so let's imagine I have a current I node and the current data block that are, so these were written before. They're in the log somewhere. These are the current I node and current data block. When I write a new I node and new data block, they end up at the end of the log. You can already see one of the complications here, which is that as I modify things like the I nodes, the I node that was in the log is no longer valid. I've written a newer copy of the I node and so these are essentially free space. They're invalid data. They've been superseded by an additional write that I did at the end of the log. But this is the big idea here, which is that by adjusting my data structures, if I can make all of these writes happen in one spot, then I avoid seeking around the disk, right? So this is a nice idea and this was, there was something I think that was very appealing about log structured file systems, which is one of the reasons they made sort of a big impact when they came out, yeah. Yeah, okay, so, okay, so the question is, how do I know where the updated I node is? Anyone wanna guess? That's the most recent. Well, I mean, so one option proposed by Steve is I start at the end of the log and I just look backwards through all the blocks, right, until I find the most recent. That probably is bad. What's another alternative here? So there's a data structure that I used before, which is thing that's called the I node map that helps me find the I nodes on disk. It contains all the locations of the I nodes on disk. What LFS does is it logs that to the log as well. So you can imagine that the front of the log is always this I node map that contains all the locations of the I nodes on disk, right? And I think I actually just said this, right? So we're only gonna, you know, the goal here is to try to write as much as possible to this one location. So we write to the disk when blocks are evicted from the buffer cache or when the user calls the sync or f sync. This allows me to defer writes as much as possible. This is something that LFS really wants to do, right? It wants to try to combine as much right traffic as possible. So this was the question that was just raised. How do I find the most current version of an I node? LFS maintains an I node map that allows me to look up the location of the I nodes in the file system. How did FFS and how did EXD4 do this? How does EXD4 know where an I node is? Remember, I mean the first step in opening a file is find I node 632, yeah. They're in fixed locations on disk. So this is actually, this is the huge difference between these two file systems. If you imagine, you know, to some degree when you format an EXD4 file system, it sets up these data structures on disk that are there throughout the life of the file system. The I node 10 is always in the same place. And FFS stuff's constantly moving around. So the data structures are constantly in flux. Every time I make modifications to a file and flush them to disk, things move. And so it's more complicated. The data structures that have to be maintained by LFS are more complicated because things are moving around. I can't get away with this idea of just being able to look up things in fixed locations. That doesn't work because every time I make a change, things move. So yeah, okay. Yeah, so I know, you know, essentially FFS just, LFS just applies this approach to everything. Just log it. Put it in the log. And sort of, as long as it knows where certain things are in the log, it can find things that it needs. Yeah, yeah, I mean, if you lose, yeah. So if you lose data, if you lose some file system metadata, you can certainly lose lots of things. What's an easy workaround for that? What would I want to do with certain really, really valuable data structures like the super block and I node maps? What's a way to avoid that problem? Yeah. What's that? I could rate it together. Let's say I just have one disk. Yeah. Yeah, put a backup copy somewhere, right? Remember, whatever what FFS did where every cylinder group had a copy of the super block. So, you know, and a lot of times, remember these metadata structures are small. And so making copies of them to make sure that I don't have this problem is a pretty good idea. It doesn't waste a lot of space. And yeah, I mean, if you lose a whole block of I nodes and suddenly you can't find any of those files, you're gonna be sad. Yeah. So, sorry, I want to make sure this is not unclear. So, FFS and the XC4 do use an I node map. Just the location of the I nodes doesn't change. So, when you, it's somewhere at the beginning of the XC4 file system is a data structure that tells me where all the I nodes are on disk. That just never changes, right? That's important because when you format a disk, you have a certain number of blocks and maybe you're sharing the disk with other things, right? So, you still need to record that information. It's just I nodes never move. On FFS, keep saying LFS, LFS, the I nodes are constantly hopping around because they're being re-lawed and so I have to update that data structure. But you can imagine it's a similar type of data structure. For FFS, the advantage is I could read that in once and then it's in the cache and I just use it over and over again, right? I don't have to worry about updating it ever. They're good questions. Okay. So, essentially, all the file, same thing with anything that I can, any part of the file system metadata I need to write, it just all gets put in the log. That includes the I node, the data structures that record what I nodes are in use and what data blocks are in use. All that stuff is just appended to the log. So here's the problem. Well, here's where things get interesting, okay? You can imagine the first time I format an LFS file system, the log starts on one end of the disk and then it's just growing, growing, growing, growing, growing, growing. And at some point, it gets to the end of the disk. So what do I have to do at that point? So this must mean the disk is full and I just have to report to the user that it's full and sorry, you need to buy a new drive, right? Is that true? Yeah. Yeah, so when the log hits the end of the disk, that is not the end of the LFS file system. There is a lot of unused stuff, garbage in the log that I've never cleaned up. Remember those I nodes and things that were sort of dead in the log before? Those have never been reclaimed. Yeah, Steve. Don't want to seek. Seeks are my enemy. Yeah, remember, whole goal here is cache soaks up reads. So essentially no or very, very small number of reads and writes all go to the end of the log. So you're trying to reduce seeks as much as possible. It's a great question. We'll come back to this. So when I get, when the log gets quote unquote full, what that really means is that I just hit the end and I need to clean the log. So the cleaning process, you can imagine how this works. I start at the end of the log that's active and I use that to identify all of the actual I nodes and data blocks on the disk that are part of the current file system. Everything else is old copies of things, wasted space, whatever. And so I can go through. I can pick up everything that's alive and I can compact it together. I can create a new log that has only active entries and I can restart things again and keep going. So you can think about, I mean, the way to think about this conceptually is you can do this over the entire log. In reality, LFS does this over small segments. So when I get to the end of a particular segment, I clean it. Here's a sort of a silly animation showing how that works. Imagine that I have, you know, these are, maybe these are data blocks and these are I nodes. I move all of the active information into, the other reason to do this with using segments is because I use a clean. I have a part of the disk that's completely free and then I have the part that I'm cleaning and I can move things into the clean part. So I started with this one segment that's very fragmented, this other one that's clean. I compact everything into the unused segment and then I can free everything from the other segment and keep going. And I can start the log either down here or up there. What's the, what do you anticipate being a problem? Why is this a problem? What's that? Yeah, okay, so that's fair. If I didn't have segments on the disk, I would really have to stall the entire file system while this is going on. When I get to the end of the log, if I don't use the segment-based approach, I'm stuck. I can't actually make any changes to the file system until this whole cleaning process is finished. But what else about this strikes you is potentially problematic. Yeah. Okay, so that's a good point. I mean, we haven't talked at any, we haven't talked at all about reliability or fault tolerance here. And during the cleaning, I'm moving a lot of things around. So that could be a problem. What else? Yeah. Well, what about the performance overhead of this operation? You know, cleaning is incredibly IO intensive. I'm going through all of these parts of one part of the disk and I have to copy all their content somewhere else maybe or move them around. So this was sort of like the, this is what created debates over the effectiveness of LFS, right? LFS is great when I'm just depending to the end of the log. So that's awesome. And you might imagine if I was running a benchmark on LFS, it would be like great for the first few minutes as it filled up the log. Then once I get to the point where I actually have to start cleaning stuff, that cleaning overhead starts to become problematic because even if I divide the disk into segments and I'm cleaning a segment while I'm using another segment, that, what is that cleaning produce that I was trying to avoid? Seeks? Yeah. So, you know, so long to this idea that I'm just happily appending things to one location on disk. Now, in parallel with that, I've got to have the disk head jumping all over the place over here to clean up a dirty segment and prepare that space for reuse. So LFS, when you start thinking about LFS on some level, it seems like it's an awesome idea and it's gonna, you know, it's the next best thing since sliced bread. And then when you start thinking about the cleaning, you start to worry. And then this is the cleaning overhead of LFS. The other thing that's really interesting about cleaning is cleaning has a lot to do with how the file system is used. So the rate at which I have to log things, the amount of fragmentation in the segments, things like this. And so LFS had this property, which made for great, like a great research prototype, which is that it seems like it could work great under certain conditions and then work terrible under other conditions. And so depending on how you measured it, people found different things. So, and then you start thinking about, so LFS design spent a lot of time trying to optimize cleaning. So considering things like, when do I run the cleaner? Well, probably I wanna do this while the system is idle because that way I don't interfere with the ongoing operation at the disk. What size segments should be clean? So here's an interesting trade-off. If I use a large segment, then, you know, the bang, so you think about I'm starting this cleaning operation, the bang for my buck is very high because I get a lot of space back. But small segments have this really attractive property as well, which is that if I choose a small segment size, it's possible that a segment is entirely dead. Imagine that there's a spot in the log that everything in there, whether they were data blocks, inodes on their onto status structures has just been updated since it was written. And so there are no active blocks in that part of the disk. And so if I can detect that, I can say, okay, done. The cleaning operation becomes a no-op, essentially. So that's cool. And this was what I was just pointing out. It's cleaning overhead is extremely workload dependent. And so this led to these, so when LFS came out, people thought, oh, this is awesome. And then, unfortunately, other people had time on their hands and decided to run experiments about LFS and found some different things. So the other problem with LFS is the following. So if, now remember, we were presuming all this time that the cache was gonna soak up like all of the reads, almost all of the reads, clearly not all of them. That would be a very effective cache, right? If it was magical enough that you actually never had to read things into it at all. Probably not something that you can build, but hopefully we read things once. So because of how LFS works, what property, let's say that the cache doesn't work as well as I wanted to, and I actually have to do some reads from time to time, what's sort of unfortunate about LFS from that perspective? Compare it to something like AC4 or FFS. And all of this is doing all this work to try to make sure that all the writes go to one spot on the disk, but that's all based on this presumption that I don't have to do any reads. If I do have to do some reads, where are those parts of the disk that I need to read? Where are those things going to be? Yeah. We have to go find it, but where could it be on disk? It's gonna be earlier in the log file, but that could be like anywhere, basically. So one way to think about this is the X-T4 makes a decision at format time that tries to optimize the average case. Most inodes are close to most data blocks because I've created them in these groups throughout the disk. LFS is trying to optimize for this best case, which is that the cache works really well, and in that case, I don't have to do any reads and I can just sit there right into the end of the log, but if the cache doesn't work, then the block allocation on the rest of the disk is just like all over the place, incredibly discontiguous. Same thing when you think about contiguous parts of a file. So remember, EX-T4 has this IDM in extent. So for larger files, that makes sure that a chunk of the file is all together on disk, LFS didn't really think about that. So the extent that EX-T4 would find all in a series of contiguous blocks, LFS is like all over the place. So if the cache doesn't work out, this could be a problem. So there's some sort of, I don't know, this led to kind of an interesting debate. So in 91, the original LFS paper comes out a great acclaim, this is an awesome idea. In 93, there was Margot Seltzer, whose name you guys might recognize as the creator of the torture chamber that is OS 161 that you guys are using. She released the paper that was, that questioned the results and said, this actually doesn't work very well. And what was fun here was that FFS is around, FFS is pretty mature, and so there's this horse race now between FFS and LFS. Clearly, one of the things that the LFS authors wanted to show is that, hey, this works a lot better than this old crufty phylicism design that doesn't do this clever thing that we invented, right? Okay, so we say, now now FFS, there were a couple of small improvements to FFS that we had to make and now it performs LFS. John Oosterhout claims, comes back and says, no, this is poor analysis, I like that. That's like calling a computer scientist stupid, right? Like that's, you wouldn't say that they were stupid, you would just say that they had performed poor analysis. Poor benchmark choice too, that's like saying that you're ugly or something, like you don't dress very well, right? Poor benchmark choice. So, and now in 95, there's another paper. And here now we start to get a little bit more nuanced. So I think people are sort of at this point finding out that what the benchmarks are showing is that it depends a lot on the benchmarks you choose and how the disk is actually used. So, you know, and part of this too, this seems very quaint at the time, but back then file systems were slow enough that you actually tuned them. So, depending on your workload, you would actually tune the file system to achieve a certain amount of performance. I suspect that this is still done today in certain very, very, very specialized settings. And it's certainly done on systems like databases that can have big performance follow-ups. Usterhout describes that paper as misleading, right? So again, so this goes on and on, right? But this is kind of, this is one of those things that's kind of an interesting idea. It's a fun retake on the traditional file system. Question? Well, okay, well let's think about larger disks, right? So, what would be good about a larger disk for LFS? Tending to the file, you can assume that most. Yeah, interesting. Let me come back to that thought. I mean, what's different about large disks as far as seek times are concerned? And when I worked at Microsoft a decade ago, they had a term for these big disks that were coming out in all of these PCs. Big, slow disks. So these drives had great capacity, terrible seek times. Particularly these sort of consumer grade drives. So seek times, remember, is disks get bigger and bigger to some degree, and buses are getting faster and faster, and the density. So when I can find a spot on disk, now I've got this really, really dense medium. And I'm picking up a lot of data, and I've got a super fast bus going back to the processor. This is awesome. I don't know why this is so crummy. Did any of you guys build machines with those old, terrible IDE ribbon cables? Okay. That's one of the things, when you guys get down on your knees at night and thank God for stuff, like you should thank Him for those stupid cables. Those things were terrible. The SATA ones are so much nicer. Thank you. So much easier to build things. So the, I lost my train of thought. Yeah, okay. So seek times are going to, are seek times on these big drives, but what's gonna get worse probably? So what was this, if the assumption, so seek times, because seek times are both sort of, if the assumptions that LFS tries to make hold, seek times are going to help me when I'm writing, but what about reads on big disks? So if I miss the cache, what happens on a bigger and bigger and bigger disk? Yeah, I have to go a lot farther to get that block. So you can kind of, I mean, you can kind of try to convince yourself what happened here, right? I mean, EX-D4, I often actually has done a big survey of modern file system designs, but in a log structured file systems, I don't know, I'm gonna get in trouble with John Boosterhoot if I say this, but never really caught on. There is one interesting application of log structured file systems on flash devices that I will leave you to think about, particularly given some of the characteristics of flash devices that we talked about before, particularly given the fact that flash devices had this way of leveling up. So you can think about if I'm really concerned about making sure that I read, particularly, sorry, if I'm really concerned about making sure that I write to every part of the disk, sort of equally often, how would a log structured file system design help ensure that? And so that's kind of an interesting question. All right, any other questions on LFS? It's a fun, fun design. Small platter diameter, no matter how many platters you have. It seems like depending to the end of the log isn't always efficient because you're gonna have to keep seeking to get to the next part in memory if you reach the outside of the platter. No, okay, so sorry, remember, the log, you can think of the log, like from a layout perspective, the log really requires minimal seeks, right? So the log starts at one side of the disk and just goes to the other. And I can write to every platter, right? I can write to all the spots on all the platters and then I move. So essentially if you were watching LFS append to a log, you would just see the heads like slowly, slowly, slowly creeping across the disk, right? So it really is the minimal amount of head movement required to write data to the disk. That's the goal. And that doesn't really necessarily have anything to do with disk layout. Right? So what I'm saying is like when they finally get to the size of smaller diameter, it needs to go back to the beginning of the... Well remember, at that point, I've got clean-in to do all sorts of other things, right? So yeah, at that point I've filled, but you think about, you know, I've got a disk with a couple gigabytes, I've written quite a bit by that point, right? So yeah, then you get into clean-in and other problems, but to some degree, you know, so that's a great point. Jumping back to the start of a new log is not something that happens very often, right? Most of the time, and you're right, there are little seeks that I have to do periodically when one segment gets cleaned and the log starts here or whatever, but overall, the idea is when I'm inside a segment, I'm just doing, assuming I'm just doing right, I'm just doing the middle amount of seeking as possible. So that's good, so I'm agreeing. All right, any other questions about L, F, S? So again, I mean, just to sort of try to picture in your mind how different the on-disk data structures are between something like LFS and something like IKXD4. It's a fun exercise. Yeah, Zach. For the people who are, I guess, neat freaks, did they ever try to do all the cleaning in the system as a whole? Oh yeah, yeah, I mean, that was one of the, you know, that's one of these like magic tricks that LFS can try to convince you it can do. It's like, oh, you'll never notice the cleaning, you know, we'll do it when you're not watching, right? It's like job and garbage collection. The cleaning is a lot like garbage collection, actually. There's a lot of similarities between it and garbage collection. And, you know, it has a lot of the same features as garbage collection. So I don't know, you guys may have, if you've taken classes with Luke or talked to him about stuff, I mean, one of the concerns that certain people have about the garbage collector in languages like Java and Go and other things is that the garbage collector can kind of run pretty much whenever. So when you run out of memory and the garbage collector suddenly has to do this whole sweep of the pool to find things that are dead and reclaim them, hopefully you're not a robot that needs to like stop and go along the cliff when the garbage collector runs, because if not, you have a problem, right? So the unpredictability caused by garbage collection is an issue, right? Here's just performance problem. But yeah, there's a lot of similarities between garbage collection and log cleaning. Except for the fact that the thing that's awesome about garbage collection is you don't have to call an allocant free. Thank you. There's no cruel in a disk, it's totally worth it. I'm sorry. The debate is over. Dynamic memory allocation for the win. Automatic. Any other questions about LFS? Okay, so let's talk briefly now. I think we have time before we wrap up today to just talk about reading research papers. So I'm gonna assign maybe half a dozen research papers throughout the rest of the year. These are research papers that I like. I think are fun, they're interesting. They have really exciting ideas inside of them and things that follow themes that we've talked about in the class. And we'll talk about them in class, we're gonna go through them together. I would appreciate if you would look at them, like print them off and just look at it and then put it in the bin, right? Or maybe actually read parts of it, like the abstract, which is, I don't know, 150 words, maybe introduction. So let's talk a little bit about how I do this, right? So I know that maybe all of you don't wanna be professors when you grow up. That's not necessarily a bad thing. So why would you read research papers? Does anyone read these things? Does anyone care? The thing that you'll find out, which is really cool, is that there's still some really exciting and novel ideas out there about how to build computer systems. You know, computer systems is a pretty mature area of computer science, but I still read papers at workshops and conferences and I'm like, wow, that's awesome. I hope that that actually happens, right? I hope somebody builds things this way or this is a really radical take on how to do something that's really neat, really exciting. And there are things about computer systems that we're still not quite able to do that we probably will be able to do soon as the result of some of the research that's going on. One interesting example of this, and maybe we should read this paper this year, do you guys hear the big news about Windows? How many people heard the big exciting news about Windows? It's gonna run bash, right? Thank you, you know, again, something else I will be adding to my prayer list and a bunch of other stuff. So that capability, it turns out, actually, as far as I understand, I'll have to look at it more carefully, emerged from a research project that people at MSR did several years ago when they looked at how to map API calls made by Linux-like executables down onto the Windows system called API, right? So there you go. Somebody did research and now you can run Appget on Windows 10, you know, that's cool. Or bash, I mean, who cares about Appget, right? Just having a shell that doesn't stink on Windows is gonna be the best thing to happen to Windows in 50 years. All right, so, and also when you think about reading papers, the normal process that we're gonna go through is to think about what are the design principles here? What's the big idea? And we're gonna try to read papers that have big ideas in them. With RAID, you're talking about an idea that was big, measured in like billions of dollars of economic activity caused by this particular idea. Not every idea that we'll read about is that big. But these are ideas that you can apply in other places when you're building other kinds of systems, when you're solving other kinds of problems. The other reason is that if you're interested in how certain things work, and you don't work at one of these companies, this is frequently the best way to find out how this, so you might wonder like, how does Google store data? How does Facebook do certain things, right? These companies publish research papers and Apple is the one weird exception. Apple doesn't seem to participate in the research community in any way, but Microsoft, Facebook, Google, these companies have people that are doing research. They publish papers about what they're going to do, or what they have, usually what they have done, some production system that's five years old. And these can be interesting, right? So, and these are, again, a fun way to see how these companies are solving problems at scale that we don't even, you don't even really, like we can't, it's hard for us to imagine. I think I looked it up recently. I think Google now has like a million computers located in their data centers around the world, so like imagine trying to maintain that network and use it for all the things they do. And a lot of cases like it's faster than like reading code artifacts, and more illuminating. The research papers will tell you what's interesting about the system. You can go, in certain cases, if the code is open source, you can go read it, but in a lot of cases, if you're interested in just the design principles that are at play, the paper is a better way to do that, okay? I don't know why this slide is in here. I saw it today, I was confused. But you know, the other thing to keep in mind is that the advance of technology is not just about creating new widgets, right? Creating new toys, right? Creating new features. There are fundamental changes that are going on in the world of technology that are really going to continue to reshape how things work. I mean, we've just lived through decades of probably some of the most radical changes in any technology ever. If you think about the internet, if there are still people left on earth a thousand years from now, the internet is what they're going to care about from now. You guys started history, it's like the Bronze Age. It's like thousands of years where they figured out how to use a particular metal. This is the internet era. No one is going to care about any of this other stuff. They're going to be like, oh wow, those people put a lot of incredibly powerful machines and connected them all together. Again, this will be in the textbooks in 500 years. Everything else that we talked about today won't. So what's going on right now? Well, in terms of technology trends that are interesting for you guys to understand, I'm sure you've heard something about the end of Moore's loss scaling. So this exponential roller coaster ride that we've been on is ending. Squeezing more computation out of existing systems is requiring new strategies. And you guys are seeing some of the effect of that. The fact that your smartphone now has four cores in it or eight cores is a result of this. Or sometimes like four little cores and four big cores. Integration of flash. This is maybe a little bit more boring, but it's sort of going on. Computing at these massive scales using large numbers of machines, hundreds of thousands or millions of machines. The battery powered ubiquitous devices, tiny little things that can run in a coin cell battery for years. Tiny little computers that are small that you're so small you can't see them. Lot of people interacting with a lot of different devices. More people interacting with computers in general. How many people, what percentage of the earth is on the internet? Anyone know? Right now. Anyone wanna guess? 100% I like that. It's very optimistic. No way. 30, too low. About half, I think, about 40, 50% right? There are half the people on the earth that aren't even connected to the internet yet. When those people connect, it's gonna be really interesting, right? You know, like high speed networks everywhere. We have a lot of problems right now that are created by either lack of connectivity or crappy connectivity. And these are problems that are gonna go away. Even on an airplane, I promise you, like 50 years from now, you will have a fast network everywhere. It'll be cheap. You won't notice when you move from place to place even on a plane. We're gonna get there, I promise. Even underwater, weird mines and tunnels. What's that? Not in Davis. Not in Davis, sorry. Or not in these lecture halls. People tell me, oh, I've gotta use clickers because students can't get on a lot in my class. I'm like, please kill me now. All right, so we'll come back to this on Friday. I'll give you a little tips. I'm gonna post the information about RAID on Discourse. Please look at it, and we'll talk more about how to read a paper and about RAID on Friday. See you then.