 All right, welcome, holy, this is late. All right, welcome back to operating system. So inodes, we get to finally figure out what LS does. So this is an exciting day. So last lecture, we left off at figuring out how we actually represent files and how we get to their contents. And we left off at an index block, which could hold up to what? 16 megabytes, something like that. And we thought that was not adequate. So the actual structure of how you actually refer to the contents of a file is something called an inode, which is short for index node. And this is exactly what it looks like. So the inode itself describes everything about the contents of the file. So one thing it stores is the mode. So those are all the permissions that you see when you do LS. They're stored on the inode. It stores the owners. So whoever, whatever user owns the file and whatever group owns the file has the timestamps. So when it was last modified, created, all that stuff is stored on the inode itself. The number of blocks that this file consumes is also stored on the inode itself. And then in the gray there, that's pointers to blocks that actually represent the contents of that file. So what we said before, if we just had a block full of pointers, that would be kind of slow because we would have to read that block to read the values of the pointers and follow them over and over again. So the way that inodes are laid out is there are different levels. And depending on how big the file is, that just forces me to use the higher and higher levels, which are slower. So what it will do is set aside some direct blocks on the inode itself. So the first, in this case, 12 blocks will be stored on the inode. Sorry, the first 12 pointers to blocks will be stored on the inode itself. So they will point directly to a block, and that block will have the data. So block zero of this file would be stored at index zero in the direct block and point directly to a block that has the data. If the file is larger than 12 blocks, then I go to the single indirect blocks, which is what we had last lecture. So it points to a block that probably is full of pointers to other blocks, and then we can find the data there. And that brings us up to our 16 megabyte limit. If the file was even bigger than 16 megabytes plus 12 blocks, then we go to the double indirect blocks. And this is like the same idea with multi-level page tables. So through the double indirect pointer, that points to a block that's full of pointers that points to other blocks that would have the actual data in them. And then if my file is even bigger than that, then I get to the triple indirect blocks. So same idea, I just add another level and it can support bigger and bigger files. So, why it has that breakdown is they want to be efficient for small files and also support large ones. So they'll always use the faster iNodes first. So if your file is only as small and is 12 blocks or less, it will just use the direct blocks and won't waste a block that's just full of pointers. And if it's larger, well then we have to grow and grow and grow until eventually, well, we might get up to the triple indirect blocks. And also the way this works is it will just populate it in order of speed. So if my file is only 12 blocks and I fill up all of these direct blocks, well, if I need another block for this file because it's growing, then I have to, the next fastest is through the single indirect. So I would need to make a block for all of my single indirect ones and then make an entry there to store my 13th block because I've wasted, or well not wasted, but I've used all my direct blocks. So my 13th one would have to go through the single indirect table and then I would, for the next 14, or for the next blocks from block 14 onwards, I would wait until I fill up this table until I get to double indirect blocks. So any questions about that? Yeah, nope, nope. All right, so let's see the maximum file size we can support now. So if our iNode has an index block that stores 12 direct pointers, one single indirect, one double, and one triple indirect, and our block size is eight kilobytes, and a pointer to block is four bytes, and assuming that our indirect blocks are just full of pointers so it doesn't have any metadata or anything, well, we should be able to calculate what the maximum size of the file is that supported by this. So in this case, we can figure out, like we did before, how many pointers we actually can fit on a single block or in our indirect table. So it is the block size, which is two of the 13 divided by two of the two, which is our pointer size. So we can fit two of the 11 pointers on a single block. So if we want to figure out how many addressable blocks we have through this iNode, well, we have to add them all up. So there are 12 blocks we can point to through the direct pointers, and then through the single indirect block, we can point to two of the 11. If we have a double indirect block, it's just two of the 11 to the power of two because we're going through two levels and through the triple indirect block, well, it's two of the 11 to the power of three. So instead of adding all these up to get a super precise answer, while this two of the 11 to the power of three, that term is gonna dominate all the other ones. So we can just approximate it to say that the maximum file size would be, or the maximum number of blocks we can point to is two of the 11 and all of that to the power of three, which is two of the power of 33. So that's how many blocks we could refer to. So if we want to compute the maximum size of the file, it would be two to the 33 times the block size, which is two to the 13. That gets us two to the 48, which is 64 terabytes. So the maximum size of the file we can have is 64 terabytes plus a little more. So is that more reasonable for a maximum file size? What would I have to do if I want a file that's bigger than 64 terabytes? Yeah. Yeah, add a quad indirect pointer or something like that, and that would give me another two of the 11. So that would what? Bump it up to 128 exabytes or something like that. So that should keep us warm for it. Well, this should keep us good for a few more years at least. So any questions about the maximum size of the file represented by an inode? All right, so now the fun part. So now we get to figure out what directories actually are and what names actually are. So there are hard links and they are just pointers to inodes and this is how you have been interacting with inodes for your entire life. You've never seen an inode before, but you've been using them because every name in your directory just points to an inode. So if I create to-do.txt, that points to an inode and that name to inode is called a hardlink and it just points to one inode. So what I can do is I can create multiple hardlinks to the same inode, which is where your life gets a bit weird. So let's go to this and do some demo stuff. So to-do, so let's create a file called to-do.txt. Contents of this file are hello and if I do ls, does everyone know what all these numbers mean when I do ls for this file? So anyone wanna tell me what this means? Yeah. Yeah, so yep. Yeah, so these are permissions for the file and they're always in order, read, write, execute and then this is some other bits. So the first three are the permissions for the owner of the file, which is the owner of the file is me, John. The next three are the permissions for anyone in the same group. So the group name is also John and then the last three bits are the permissions for anyone else that is not that user or that group. So in this case, anyone can read this file. Anyone know what this number means? Has this just been a mystery for your whole life? All right, well, let's see if we can figure it. So yeah, the other thing, so that's the name of the user that owns this file. This is the name of the group that owns this file. What's this number mean? Let's see, so to-do.txt, it says hello and then probably a new line. How big the file is in bytes. So I just made it a bit bigger. What about this? Yeah, time last edited, time last modified, something like that and then finally the name of the file. So I will introduce to you a new column you haven't seen before. So if I add dash i on this, this will add a new column that tells me what the inode this name refers to. So if I do that, this number right here is the inode number that that name refers to. So now I can do fun things. So if I want to, I can create a hard link through a command called ln. And the first argument is the name and whatever inode that points to, I'm going to make the next name also point to the same inode. So if I do ln to-do.txt and b.txt, I create a name called b.txt and it points to the same inode as to-do.txt. So if I do that and ls again, I can see in this column, they both refer to the exact same inode which represents the contents of the file. And now this number that we don't know what the hell it was has increased. Any guesses as to what this number is now? So let's add another. So if I create another hard link to this inode, numbers went up. Any guesses? Yeah, number of links are just number of names that point to that same inode. So in this case, before taking this course, it kind of looks like they're all different files, but if I look at them, to-do.txt and b.txt, the contents looks the same. What happens if I modify, let's say b.txt and just remove all this stuff? So I modified b.txt and not to-do.txt. What do I expect to see if I cat to-do.txt now? Yeah, just hello. So in this case, hello because, well, currently all these things in the directory point to the same inode. And the inode is what stores the actual information about the file, like where its contents are located. So if I modify it through any of that name, I'm changing the contents that are on the blocks that the inode refers to. So if I change one, I change them all because they all point to the same inode, which actually represents the contents of your file. So any questions about that? Yep, like if I do move and move like that to another directory. So we can make a directory called temp and move c there, so like that, and that way you want me to do. So if I do that, this number is still three, but in this directory, I can only see b and to-do.txt. Yeah, and within temp, the inode's still the same. So we've kind of figured out what move actually does. It doesn't copy or do anything. All move does is change the name. So if I do like move b.txt to, I don't know, e.txt, all I did was change the name from b.txt to e.txt, but they still point to the same inode. So that's why if you do move, even it doesn't actually move the contents of anything at all. So even if that was 20 gigabytes or something like that, still happens like that, because all I'm doing is changing the name. I'm not doing anything with the inode itself. They're still pointing to the same inode. And also this is kind of how your recycle bin works as well. So the operating system is smart enough that, well, how would I get rid of e.txt? Yeah, RM. So RM, we think that just removes things. Spoiler alert, it doesn't remove a thing. So if I, RM, e.txt, I assume that the contents are all gone, but what really happens is all I did is remove that name, and there are still two names pointing to that inode. So I'm not actually going to delete anything. I just got rid of a name. In fact, if you look at the system calls, there's no system call called RM or anything like that because it doesn't remove anything. What RM actually does, if we S-trace it, it does a system call called unlink, which just removes that name inode pair. And eventually, if I remove a bunch of things, if I finally remove, right now there's only one reference to this inode, if I finally remove to do.txt, and now I have zero references to that inode, then I could, my kernel could actually delete that file or something could happen. Yeah, I could reuse that space for something else and then actually remove it. But it's not gonna actually remove it until we have zero references to that inode. And that is basically how your recycle bin works. So when you try and delete a file, if you're on Windows or you're using some GUI or something like that, well, in order to prevent your file from being deleted, what they'll do is create a hard link for you in the recycle bin that still points to that inode so that it is kept alive just in case you want to recover it. And that's also why recovery happens like that because all they're doing is keeping that inode around and if you recover it, all it does is recreate the name and point it to that same inode. Yeah. If Windows takes longer to recover, then they're not great. Then this is also why we don't use Windows. But it should be like that. So there are some exceptions where if you have multiple drives or did you have multiple drives or something like that? Okay, well, then that's another reason not to use Windows because it should be like that, right? As long as we still have a reference to that inode, it's all good. And this is also why you can actually recover data because guess what? Even though there's no references to an inode, it's actually slow to zero out the data or anything like that. So your operating system is just going to market as unused but all that data is still going to be there. That's why you can sometimes recover files even though you have deleted them because all the data would still be on the drive. It would just be marked as inactive. So if you do like a data recovery process, what it'll do is go through all of the inactive things and see if that inode still exists there and see if it still points to valid content and if you react close enough or fast enough, likely you'll still have all your content physically on the disk and you'll be able to recover it. So all it would have to do is mark it back as active and boom, you recovered your files. So any questions about that fun stuff? Yeah. Yeah, so sometimes we delete stuff. So right now since I'm doing terminal commands, there's no recycle bin but if you do it through like Windows Explorer or some GUI thing, it will essentially whenever you remove something through that interface, it will make a hard link in that trash bin and usually they'll keep it around for like 30 days or something and then after 30 days, they'll get rid of it and that would be the last pointer to that inode and then it could actually get deleted and reused for things. So that's one way to recover stuff. All right, any other questions before we make this even more fun? All right, let's get to it then. So if there are hard links, there are also soft links. So these are also known as shortcuts or in Windows LAN, pretty much the same thing or sometimes they're called soft links. Sometimes we call them SIM links or symbolic links. So I usually say SIM links. So if I say SIM links, it means soft links and what soft links are are basically a way to refer to a different name. So soft link, you can think of it abstractly as just name to a name. So I can create a soft link called B.txt that points to another name instead of an inode. So it points to to do.txt. So if I try to access B.txt, the kernel can figure out that, hey, to access B.txt, the contents of that and find that inode, I have to look at the name to do.txt and then through to do.txt, I can actually find the inode and then actually find the contents of that file. So your soft links, because they're named a name, the target like what they're referring to might not exist. You can delete soft links and no one will notice. Like nothing is actually keeping track of them and sometimes we can create unresolvable soft links and that would lead to some type of exception. So we can go back. So everyone remember what a DAG is to from your algorithms course, a directed acyclic graph. So your file system through the hard links are a directed acyclic graph. If you add sim links or soft links into the mix, well, soft links allow you to create cycles and break that directed acyclic graph. So you can only create cycles through soft links. That's one of the reasons why they exist and they actually proved to be somewhat useful. So let's see. So to create a soft link, same thing, I can use the ln command, but I can give it dash s to create a soft link. So I can create a soft link to to do.txt called b.txt. So now if I ls here, I can see that b.txt while it points to to do.txt. And I see some weirder things. So I can see it just gives it all permissions because the permissions are actually protecting what it refers to. So they just give you all permissions because at the end of the day, you will, that thing's freaking out. At the end of the day, you'll go to to do.txt, then go to that inode and then you'll use the permissions from that inode. But now if I try to do cat to do.txt or b.txt, I get the same contents because I can follow them through and they eventually get to the same inode. So any questions about that? All right. So technically the good way to think of simlinks is just name to name. Technically they also take up an inode. So this b.txt to store the information about it, it would also be on an inode. So you can see the inode number here, but the contents of that inode is just the name that it's referring to. So we'll see that the name is eight or the size of this file is eight bytes, which is exactly to do.txt. So it's exactly the same size as that. Yep. So what if I rename or move to do.txt and call it C? So in that case, I don't change the soft link at all, but it still refers to the name to do.txt. But now if I try to access it, well, let's see. What would happen if I try to cat b.txt? So b.txt exists, but if I run this, you'll see no such file or directory, which is kind of confusing because b.txt does exist, but what it points to to do.txt does not exist. So that's no such file directory. So it gets a bit confusing with the error messages, but it'll give you an error. Yep. Soft link to soft link. So, well, what about, I don't have it to do. What about if I just create a to do again? It's like that. So b.txt to to do.txt, and then to do.txt is a sim link to b.txt. So what do you think happens if I, oh no, if I do that, it'll just hang infinite loop over and over again, says, gives me an error, too many levels of symbolic links. Okay, well now I'm curious, who's smart? Did whoever wrote cat, did it follow a few times and is that error from cat or is that error from the kernel? How would I figure out what that error comes from? Ah, I could strace it. Great, we took this course. So if I strace it, so that's why I told you, so here's our error message. It does a few stupid things that are unrelated. I can see up here, this is where I tried to open it. So I tried to open to do.txt and immediately I got an error. So it didn't even try and do anything with b.txt. So from the kernel itself, I got negative one, so that's an error and the error no was eloop. So the kernel gave me an error. So all that error checking is done in the kernel itself. It told me there's too many levels of symbolic links. Fun, kernel saved us. So yes, you can create cycles and yes, the kernel developers are smart. All right, any other questions for that one? Yeah, yeah. So I could also do a hard link to that inode. So say I do a hard link to b.txt. So that points to to do.txt and I'll call it, I don't know, d.txt. So in that case, if I make this a hard link to that soft link, it's going to refer to the same inode. So in b.txt, it's this inode and the contents of that inode have to do.txt in them. So if I create a hard link called d.txt to this inode, then the contents of that are also to do.txt. So it's, sorry, if we have, yeah, so it's slightly different than if we just created a new soft link from d.txt to do because then they would be different inodes from b, b and d would be different inodes, but right now they're the same inode. So we have two here, which is very unusual. But this, technically, if I use the command to change what this soft link pointed to, I would change both of them. So if I change this from to do to, I don't know, e or something like that, and this would also change to e because they point to the same inode. But if they were two separate ones, then I wouldn't change the other one. All right, get rid of that. All right, any other questions or fun things we can do? How does CP work? So what file actually exists now? Okay, this still exists. So if I CP c to e, what should that hopefully do? So if I do CP, I can look and see that they are in fact different inodes and it kind of works like fork. So they should be exact copies of each other whenever you hit CP, but then after that, independent, right? Kind of like we had before. So they are different inodes. So they refer to different contents. And then as part of CP, it would have to, for every block in the original file, it would have to make a duplicate block, copy all the bytes over, and then in the new one, it points to those blocks instead. And they are now independent. So now if I change c.txt to hello there, well, if I look at the contents of c.txt, it's hello there, but if I look at e, it's still the same because it's a different inode that points to different contents. All right, any other questions about that? Yeah, so what happens if I try to do a copy on right here? So there are, so that, again, that exact copy on right idea does apply to file systems. So yeah, so this, that CP could do copy on right, right before I modified the file, it could actually share the data. And there are in fact file systems that are called copy on right file systems that do exactly that. So this one, I believe the default one does not do copy on right, but you can use the exact same copy right idea and apply it to this. It looks pretty much exactly like memory. So there are copy on right file systems and they exist. Yeah, so they'd have to keep track if like they're sharing data blocks between two different inodes and things like that, just like how you had to do that in lab three, whatever it was. So yeah, there would need to be some more structure so they can keep track if they're sharing or what, or what, if they need to make another copy and everything. But it does exist that same idea can apply to file systems. All right, any other fun questions? Alrighty. So we can look at this. So if we do something like this, so the touch command, oh wait, before we get into that, we can look. So if you want to see all the contents about an inode, you can use the stat command. So that's also a system call. And it tells you lots of information about the file. So it tells you the file name, which is just what you called it with stat. So that's not on the inode itself. The rest of this information is stored on the inode itself. So it will tell you how many bytes that file actually is, then how many blocks it takes up on the disk and how big a block on the disk actually is. And you might wonder why the heck, e.txt is only seven bytes long and my IO block is like four kilobytes. Why does this take up eight blocks instead of just one? Assuming I only have to fill blocks at a time. So this is stupid. The block number here is beyond crazy. Don't ask me why. So this block number is how many hard coded 512 byte blocks you're using. Why it's that number? I have no idea because this file would actually just consume a single IO block. But if you do the math, an IO block is 4096 and then if you divide by these hard coded 512 blocks, you get eight. So eight blocks here actually means only one block on my hard drive. So this number will always be a multiple of eight. Do not ask me why they hard coded the blocks here to be 512. I have no idea, but that's what it means. So you will encounter that in lab six when you're making your own file system because your block size isn't gonna be 512. It'll be a different number, but you'll have to encounter this silly blocks field and just know that some hard coded value. So some other information that'll be on the inode that we haven't really gone in detail with, it will also tell you what device this file is located on. So this would be my solid state drive on this machine. Tells you the number of the inode itself, the number of hard links to it, all of its permissions, who owns it, what group owns it, when it was last accessed, when it was last modified and when it was last changed. So change and modify usually mean the same thing. The difference here is modify refers to the contents of that file and change refers to the inode itself. So change is when the inode was last modified, modify is when the file contents were last modified and birth is whenever this inode was created. So all these timestamps exist on the inode itself and you're free to modify them as you wish, which is why timestamps on files mean nothing because you can change them. So how I could change them, like if I run a command called touch, what touch will do is reset like the change access and modified to essentially right now. So let's see modify is at, was that 339? Change is at 339. If I do touch and then I started again, I'll see that I updated all of them to the same value and it was when I ran that command at 345. So you can also use touch to modify your timestamps if you want. If I wanted to, I could set to 1968 or something like that and you're free to modify timestamps as you wish. Your timestamps don't actually mean anything. They're just for you and yeah, now you know the trick of this course. So now if your friends, if you want to prove to your friends, you have written something in the 60s, you can by the file timestamp, but the file timestamp doesn't actually mean anything and you'll figure out that in lab six, you'll create these timestamps too. So knowing this course, you can cause lots of problems with people that are like taking English courses and stuff like that because you can just make up any date you want. So any questions about that fun stuff that I probably shouldn't have told you. Yeah, yeah, so if you look at, oh God, why shouldn't show you this? But if you look at the touch command, there's a time parameter that lets you set it to whatever you want. So if you know the timestamp, you can just set it to whatever you want. I didn't show you that. So do not use that maliciously. This course is like great power, great responsibility, all that fun stuff. All right, any other questions aside from something that is slightly dubious? Yeah, yeah, so touch will also create a file. Nope, so touch, if I just do touch and then f.txt, all it does is create a new file called f.txt and that would also create a new inode, but the size of it would be zero. So it's just, essentially it just creates a new empty file by default. All right, any other questions with that? I really shouldn't have told you that. All right, so back to this. So you can probably follow this. So if it starts with touch.txt, that creates a new inode that has no content so it's empty called todo.txt. If we make a hard link to it, both of those would point to the same inode and then if we create a soft link called c.txt, well that would point to todo.txt and then if we do this move command, what move is going to do is just rename todo.txt to d.txt. So in that case, like we did before, it would change d.txt, it also points to the same inode but now todo.txt doesn't exist in this directory. So now if we remove b.txt, our file system looks like this. So c.txt just refers to the name todo.txt, although technically c.txt refers to an inode and the contents of the inode are todo.txt but generally for simlinks, that doesn't really matter. We just think of it as name to name and d is just points to the inode itself. So any questions about that? So now we can figure out what a directory is. So directories behave the same as files, just on the inode. There's a type that tells you what that inode actually represents. One of the options is a regular file. Another option is a simlink and the contents are interpreted as a name to point to. The last one is a directory and all a directory is, is just a bunch of name to inode tuples. So if I, let's clean this up a little bit. So if I do slash all, I can see everything in this current directory and all directories are, are just name to inode tuples. So for each, so in the directory for this directory, which is referred to by, so dot refers to the current directory. So the current directory would also be an inode. So an inode 60 in this case, the contents of that inode would be all the name inode tuples that represent all the files in this directory. So it would have a dot entry that refers to this inode, a dot, dot entry, which refers to this inode, a c.txt entry that refers to this inode and e.txt that refers to this inode. So that's all directory is. It is not that special. It is just name to inode. That's it. And now we can go through because we can see here that this dot, so this current directory has two hard links to it. Why would it have two hard links to it? From slash or it's parent. So here, if I go up one, so if I go to the parent directory, while this directory, which I call test directory, that name inode is probably in it, right? So if I do this, I can see that it has a name called test directory and it refers to the same inode. So that's how I get to that directory. So that's one hard link to that inode and then the other hard link is the dot that is in that directory itself. So that's my two hard links to it. And this one has three because the parent, well, it's referred to by dot dot. So dot dot refers to it. And then if I back up in this 27 inodes directory, well, dot refers to itself. And then in its parent, it's called 27, 28 inodes. Yeah. Yeah, here I'll go up one. So in this case, if I make a directory in here, let's say D1, then in that case, yeah, I've just increased the number of references to the current directory. Because in this D1 directory, it would have an entry called dot dot that points to this one. All right, so if I make another directory, D2, same thing, I just increased it to four because there would be a dot dot in that directory. So on and so forth. So you can see how popular directory is by just seeing how many hard links there are to it. Basically tells you how many directories are within it. So if I look at, I don't know, let's see how popular root is. Oh, so whoops, that's not root. So yeah, root's fairly popular, 19. So it has 19 other directories in it. And you can see here that, oh, some things are actually sim links. So bin is actually a sim link to user bin. So that way, if I, doesn't matter if I refer to LS, like if I do a full path, I can refer to LS as slash bin LS or slash user slash bin LS. They go to the same thing because I have a sim link there. So it only actually exists in one location, but through a sim link, you essentially just create another name that you can access it through, through just another, just a sim link. There's another one for lib. It goes to user lib, sbin, user sbin, all that fun stuff. So any questions about, yep. Oh yeah, so LSLAI versus what? Oh, oh no. So the order of these arguments don't matter. So all A does is, it shows you all the hidden ones. So anything A just shows you any entries that begin with a dot and I just add that inode column and they can be in any order. All right, any other, yep, oh no. Yeah, yeah, so you will be very familiar with how inodes are stored, but they're stored on the disk as well. So there will be some blocks set aside that just store inodes, like a giant array of inodes. So there'll just be a giant array of inodes also stored on blocks. So, yeah. Kind of disappointing, right? That's how it works, but that's how it works. Everything is just, most things are just arrays and just some abstractions so it fools you. But files, we had no idea what they were before this class. Now we should have a good idea of LS and you can really screw with your friends through hard links if they haven't taken this course, right? Just you can hard link multiple like C files to one another and just have them massacre their own code and you can screw with your friends real good after taking this course. So this course should be required so you can just not be screwed with after taking it because yeah, you can cause a lot of havoc but I never told you that. All right, any other questions? All right. So we can go through this real quick. So what's stored on an inode? Well, let's go through the answers. So the file names not stored on an inode, names only exist within the directories. If you, the containing directory is also not stored within an inode that inode can be referred to in multiple directories like when we move that file to another one and you don't know, given an inode you don't know what names refer to this inode unless you just walk the entire file system and kind of brute force it to figure out what actually points to this. What else is stored on the inode while the file size is stored in the inode? The file type is stored on the inode. So usually they represent regular files, SIM links and directories. The number of soft links to file are not stored on an inode. They have no idea. A soft link is just a separate inode. It's just name to a name and they don't know about the location of any other soft link but the inode knows the number of hard links to this file because while the curl needs to keep track of it so that knows when it can actually erase the file or mark it as unused whenever there are no names that refer to that file. Well, then I can't use it so I could delete it. The location of the hard links, well, they're not known. The access rights are stored on the inode, timestamps are stored on the inode and the file contents are sometimes stored directly on the inode. So if the contents of the file are really, really, really small there is an optimization where it will store the contents on the inode itself instead of using a disk block and you will make that optimization in lab six. So that optimization is actually for symbolic links. So if we go back to this, let's create a new symbolic link. So if I create a new symbolic link called todo.txt well, the inode is storing e.txt or the contents of that inode but if I stat todo.txt it will tell me that it's a symbolic link but it'll also tell me that's consuming zero blocks on my hard drive so that the contents which are e.txt are being stored not on a block they're being actually stored on this inode itself and you will make that optimization in your lab six because it's defined, yep. So an IO block is the actual size of a block on your disk. Yeah, so in this case my blocks are four kilobytes. Actually, technically not on the disk technically it's what your file system thinks a block is which may not match your disk but for the purposes of this course we'll think of them as the same thing. All right, any questions about that stuff? Look, oh, crap. All right, we're almost out of time. So the file system writing data to disk is slow so whatever it reads a block from a disk it'll essentially read it into a page and they'll be cached in something called a file system cache and typically it will keep that cache around because if I'm modifying a file well I don't wanna read it back into memory every single time that would be slow. So if I'm using it over and over again well that's called temporal locality because if I use it once I'll probably use it again in short order and also if I modify the first block of the file I'm probably likely to modify the second block so I might as well read it in. So what your kernel will also do is it won't write anything out to the disk until you actually force it to because that's just really slow so that's why you need to object your USB drive because sometimes if I copy a big file in to it it'll be only copied in cached and the operating system will know that hey I should write this to that drive but it won't actually write that drive so there might be a kernel thread that writes those files periodically to disk but if I hit safely eject drive it forces all those writes to happen so that your USB drive has all the data in it. So I guess we're out of time. So with that just remember pulling for you.