 All righty, welcome back to Operating System, so inodes today. So how files are actually stored? We actually get to learn what LS does today, so that'll be fun. So here's what an inode actually is. It's how you represent the file on disk. Last lecture, we ended up with that index node that essentially just is a block full of pointers. And we said that it could only support a file up to 18 megabytes. That's not very great. So this is how files are actually stored. So it's called an inode. It has all the information about the file, so the mode. So those are the permissions, read, write, et cetera. Owners, so each file is owned by a user and a group. Timestamps, which are just stored on the inode itself. So when you modified it, when you created it, that the dot, which you can change at will. So if you want to make your files created in 1970, you can. The number of blocks that this file takes, and then this gray area is actually pointers to blocks that stores the information or the contents of that file. So there are some pointers that are just directly point to a block. And that way, accessing those blocks is really fast, because I don't have to read any other blocks from this to figure out where they're pointers. So there's going to be a set number of direct blocks. So that's just pointers directly to a block. In the case of inodes, there are 12 direct blocks. So there are 12 pointers that point directly to the block. So the first index or the zeroth index here would be block zero of that file. The next index would be where the block is for the next index, so on and so forth. Then there is one pointer reserved for single indirect. And that's the idea of index nodes we had before. So it points to a block that is just full of pointers to other blocks. And those pointers will point to blocks that actually store the data. And then if we want to have a file that's bigger, so bigger than that 16 megabytes, then we go on to double direct, which is like having two levels of page tables. So it will point to a block. And because we followed it through the double indirect block, while this is full of pointers that points to another block, that's full of pointers that finally points to the data block. So we can use more blocks for the file. And if we have an even bigger file, there is triple indirect blocks that will do the same thing just with another level. So any questions about that one? It's pretty much page tables. So the only difference here is in terms of speed. So if it's in a direct block to figure out where block 0 is in the file, well, I just have to look at the inode and it points me to wherever that data is directly. I don't have to read another block from the disk, which would be slower. So I can store up to 12 of them, like the first 12 blocks of the file, really fast. I can look at the inode itself. And then the single indirect is that idea we had before of just going to a block full of pointers, but I would have to read that whole block in. Yeah, so this represents the contents of a file. Yeah. No, there's no redundancy in it. So the direct blocks are like the first 12 blocks. And the 13th block would be the first entry in the single and direct block. So the idea is that, well, more levels are slower. So I'll use as many levels as I need to to just represent that. And I'll fill up all the fast ones before I fill up the slow ones. So index, whatever block index 13 is, would be the first entry in the single and direct one. Yeah. No, this is for a single file. So these blocks are the contents of that file, like the index thing, so they're listed in order. Yeah, in directory, there'd be multiple inodes, and we'll get to play with them today. There could be, but let's do the calculation to see how big a file could be if we did triple and direct. Yep. Yeah, maximum size of file would be if we fill up all of them. Yep. So file limits is like for emails and stuff, that's because the server has a limit. So the server just doesn't want you to fill it up. The file, you can try and upload a file of any size, but it's up to the server to actually just reject it if it's like 12 terabytes of garbage or something like that. So that's just a server limit. Yeah. Yeah, so the inode refers to this entire structure. So this is everything about a file you could want. So all the timestamps, who owns it, permissions, and where the contents of the file actually are. Yep. Nope. Yeah, if you'd have a really big file, you can't use multiple inodes, just use one inode, but you'd probably be in the triple indirect land where you'd have to start using it. So let's, oh, yep. Yeah, all the blocks are the same size. So it's whatever the block size on your disk is. Okay, so, yeah. So the idea behind this, like I said before, if it's a small file, you just use direct pointers. If it's a larger files, well, then I have to resort to using index blocks and it's a bit slower, but I'll use as many levels as I need to to actually represent the file. There's actually an optimization here. So if the file is really, really small, well, it actually stores the contents of that file on the inode itself. So it uses that space for pointers and you will discover that in lab six because you will be making that optimization as well. So some files might not actually consume blocks on the disk if they're really, really small. So here's our inode problem. So our index block, usually it stores 12 direct pointers, one single, one double, and a triple indirect. So if our block disk size is eight kilobytes and a pointer to a block is four bytes and indirect blocks only consist of direct pointers, there's no metadata or anything like that, what is the maximum size of file managed by this index block? Well, we can have 12, eight kilobyte blocks through direct pointers and then through the single indirect, well, if we fill up a whole block full of pointers, it's to the 11, so we can fit to the 11 on a single block. So it'd be to the 11 times the block size, which is what we figured out before, which is 16 megabytes. And if you go through, well, here's the number of pointers for our indirect table. This is how many pointers we can fit on a block. So the total number of addressable blocks is 12 through the direct to the 11 through just the single indirect and then through double to indirect, it would be to the 11 to the power of two because each of them can point to another block that's full. And for the triple indirect, it's the same thing, but to the power of three. So this two, I can be lazy, this two to the 11 to the power of three, well, that's going to be the dominant term. So if I want to estimate the maximum file size, it's about that, which would be two to the 33. And then if I multiply two to the 33 by the block size, which is to the 13, that means the maximum size of the file is two to the 49 or 64 terabytes. Seems a bit more reasonable than 16 megabytes. Yep. So the inode itself would also be stored on the disk. So you'll also figure this out in lab six. So the file system will set aside some blocks to just store inodes. So there'll be essentially just a giant array of inodes stored on some blocks. So they'll also be stored on separate blocks, so. All right, any questions about that? So that seems more reasonable for a file size limit. So this is your limit right now. On Linux, a single file can be up to 64 terabytes. Pass that if you want a bigger file. Yeah, then you have to go to quad indirect blocks or something like that, but this should keep us okay for a while yet. So any questions about that? Pretty big file. All right. So now we get to discuss what the hell a directory actually is. So we have to talk about what a hard link is. So a hard link is a pointer to an inode. And guess what? This is what a file that you see is. So the names in your directory, they're not the files themselves, all the names are in a directory is just a way to refer to an inode. So to do .txt, if I create a file like that, it will point to an inode and that inode describes that file name and describes where it is on disk, who owns it and everything like that. So directory entries, aka just a file name, they're called a hard link. Hard link is just name to inode. So any questions about that? So that is what is in our directory. So we can play with this. So multiple hard links can actually point to the same inode. And deleting a file only removes a hard link. The file can be hard links somewhere else. You might notice that there is, if you look at the system calls, there is no system called called rm or delete or anything. The closest thing is something called unlink. So we can play with this a little bit. So let's create a file called todo.txt. Say hello there. So we've all done LS before. So if I do something like that, do we know what all these things actually mean? Here, I'll get rid of the A. So do you know what all those columns actually mean for this file? Yep, ish. For everyone else yet. Mystery number, okay. So that's the, yeah, that's the user owner. Then that's the group owner. So there's 13 size of the file. And then here, timestamp probably when I last modified or created it, last modified it, and then the name. Okay, but we don't know what this number is. Anyone know what this number is? All right, let's give you a hint. So you can create hard links if you want through a command called ln. So ln will create a hard link. And the first argument is, well, a name and you take whatever that iNode, or that name points to, whatever iNode that points to, and you can create a new name that also points to the same iNode. So I'll create b.txt. So now if I look in my directory, I have todo.txt and b.txt, and they both point to the same iNode. So if I look at the contents of b.txt, if they point to the same iNode and iNode describes everything about the file, including its contents, what should I see? Yeah, hello there. So I do that, I see hello there. And it looks the exact same because both of these names refer to the exact same iNode. So I'll do ls again. We don't know what this number is. Do we have any guesses now? Yeah, a number of references to this iNode. So that's what that number actually means, which I assume no one would have any idea what that meant before this lecture. If you did, you didn't need this course. Yeah, so what's the difference between this and CP? So let's learn another ls switch. So if I add i onto this, it will create a column for me that tells me the iNode. So if I do this, this column is now the iNode that that name refers to. So I can see here that both b.txt and todo.txt refer to the exact same iNode. So you were asking about copy. So if I do something like this, so what should that do? If that's making complete copy of the file, would that be a new iNode or point to the same iNode or what? New iNode, right? Because I can modify c.txt independent of todo.txt, so it should be a new iNode. So let's just verify that. So yeah, we can see c.txt is now a new iNode. There's only one thing pointing to it, which is c.txt. So copy would create a new iNode and then make that iNode look exactly the same whenever it copied it. But otherwise after that, it's kind of like forking, they're like independent at that point. So just copied it, now they're independent. All right, yep. So shortcuts are slightly different and we'll explore them next because they get another fun name. All right, any more questions about this? All right, well also knowing that number, we can see that, let's go i. So dot and dot dot are just names in the directory and they also have iNodes. So each directory also gets an iNode and we just said that this is the number of things that point to it, number of names that point to this iNode. So this is two and this is three. Why would this be two for dot? So why is the number of links to, or the number of names to the iNode of dot equal to two? Yeah. Yeah, so dot is itself. So that's one reference to this iNode because dot is always the current directory and if I back up one directory and do the same thing, well there's a directory in this directory that iNode is called test directory. So it's called test directory here and it refers to the exact same iNode as dot. So that's the second reference and dot dot, well that refers to this 28 iNodes directory which also has a parent so that's why it's three. So you can also see how popular your directory is through doing the same thing and counting, how many references are there to this actual directory. All right, so any questions about this before we carry on and make our lives even more, well, more fun? Yep, yep, yeah. So three to the parent because dot dot in this directory refers to the parent, in the parent dot refers to itself and then above the parent it has a name, right? So that would be three. Yeah, yep, so if I make directory okay and do the same thing, now yeah, dot went up to three because now I'm the parent of this directory so it increased the count by one because in that directory dot dot would refer to this directory too. So you can see how popular you are. So if I created another one, same idea, goes up to four, you can see how popular you are by that number too, I guess. All right, any other questions about that? Let's remove those. Yeah, yep, yeah, you can see, well, you can see how many directories point to you. So, all right, so do do. All right, soft links are shortcuts or sim links so they have several different names depending on what operating system you're using and what you wanna call them. So usually in Linux, shortcuts are called soft links or sometimes they'll be called sim links so if I say sim link or soft link they refer to the exact same thing. So all they are is instead of a name pointing to an inode it points to another name. So if I create a soft link called b.txt I can point it to the name to do.txt and then for the curl to resolve this, well if you refer to b.txt it knows to look up to do.txt and through that that would have to eventually be a hard link that points to an inode that actually represents something. So soft links don't really need to exist they can have some flexibility but it gets a bit weird so it's just a name so whatever they're referring to you can just delete it or get rid of it and the soft link will now just be broken and if you try to use it it'll just give you file not found. Let's just play with it for a bit. So, do do do. So what we have in this directory let's just get rid of, oh wait before that let's get rid of b.txt. C's a copy, okay. So let's create a new hard link called c.txt just to make sure that we understand it so to do.txt it says hello there if I go ahead and I make a hard link called c.txt for it and then through c.txt I modify it what happens if I try to look at the contents of to do.txt? Yeah it should be modified as well because that's the file so I can modify it through different names doesn't matter as long as it just goes to an inode actually represents the contents of that file. So a soft link is the same command but you do a dash s for soft link or sim link whatever you wanna call it so I can create a shortcut soft link sim link whatever you wanna call called b.txt and it will be b.txt should refer to to do.txt. So if I look at it now shortcuts or sim links show up as just a name to a name so now if I try to refer to b.txt it will give me to do.txt so if I cat it it'll go ahead give me hello all but you'll see here if we do ls-i it gets its own inode so technically that to do.txt has to be stored somewhere so that's stored on an inode but it's really small so that's where optimization comes in it has all permissions because well all you care about is what it points to the permissions just protect the name so generally you just give it all permissions and that's the default and that's it so whenever I refer to b.txt kernel will go to to do.txt to find the inode and then finally give you an inode if it's there so the reason why we have this is if you have hard links everyone remember what a dag is a directed acyclic graph so your file system is a dag but with simlinks you're allowed to create cycles and everything so it's a bit more flexible like that and it's a yeah it's more fun so if I wanted to create a cycle what's an easy way to create a cycle that is infinite using simlinks or soft links whatever you want to call them back to b alright so I could do something silly I could get rid of to do.txt and create to do.txt that points to b.txt I can see I made it mad too I guess that's new but I create a cycle so if I look at b.txt it'll say oh go to to do.txt and then to do.txt it says go to b.txt what do you think happens if I try to look at the contents of either of those files crash yeah the sizes yeah so the size of the inode that represents your simlink is the size of the name it's referring to so to do.txt is eight b.txt is five so it's the length of the string because technically that string needs to be stored somewhere as well yeah no so so wait which inode yeah so right now that I think c.txt points you to it because it had hello all in it so c.txt still had a reference to it so it didn't get deleted yeah if I didn't have c.txt well then I have no reference to that inode and then it might actually get deleted so this rm command here we can so right now I have two links to this file so if I do rm rm doesn't actually delete anything right because I can delete one of those names the file still around it exists as long as there's a name referring to that inode and if I even strace rm I can see that the system call it used was unlink all unlink does is remove the name from the directory and that's it so as long as there is that's why it needs to keep track of the number of references to that inode so as long as there is at least one reference that inode should still be active and it shouldn't be deleted and this is also why this is also kind of how your recycling bin works so what your recycling bin works it how your recycling bin works is well instead of whatever you remove a file your recycling bin can keep a reference to that inode just in case it needs to bring it back so as long as your recycling bin has a reference to that inode that the contents of the file won't ever be deleted and to restore it that's why to recover a 20 gigabyte file from your recycling bin it takes no time at all because all it does is recreate the name points to the same inode that's all it has to do doesn't matter how big the file is yeah yeah as soon as you lose the last reference the kernel that's the one keeping track of anything so if it wanted to it could delete that contents turns out deleting contents is slow so it would technically just leave it alone on the disk and just mark it as unused and that's also why you can recover data from drives because while actually deleting it is slow but you might notice that even if you delete all references to it as long as you're really really quick well the inode might actually still exist somewhere it's just marked as inactive so it's just a process of scanning all the inodes and seeing if it still refers to something and you can recover your files that way so that's how data recovery works and some people make a lot of money doing that yeah, yeah you're not restoring any space or anything it still exists but it's better than being deleted, right? yeah so the recycling bin will delete it at like get rid of its reference after like 30 days or whatever or whenever you say clean it up and then it can actually free that space yeah so soft links are a real file but they just refer to a name sometimes that's actually a useful thing so if you want to it gives you like another layer of indirection so you could have essentially a shortcut to I don't know one example is like you could have a sim link called Python that points to the actual Python binary, right? and if you want to upgrade your version of Python all you have to do is change that sim link and then everyone starts using the new Python binary or something like that and it's more flexible that way so that's one way if you look at your VM your Python executable is probably a sim link your compiler may also be a sim link a bunch of other things are sim links just makes changing things a lot easier and it's just kind of nice sometimes yeah so if I delete so oh wait so first keep that thought let's look at our cycle so let's try and cat b.txt well we think this is just an infinite loop and our kernel's done but now well was the kernel smart or was cat smart? cat was smart? all right so if our guess is cat was smart what would we use to see who's smart? strace, let's strace cat and see what it did so we got too many levels open b.txt too many levels I only opened it once the kernel is smart so you can see it never even tried the open to do.txt I just did an open system call and it got negative one so it got an error and my error was eloop too many levels of symbolic links from the kernel so the kernel is smart and the kernel will stop you from hurting yourself I guess because this could be a very complicated number of links like loop of symbolic links I could get up to like 20 and point it to the next one so the kernel is the one that's smart plus makes sense you wouldn't expect every single program to deal with symbolic links and do it properly especially if they don't even know what symbolic links are because I could have given you guys symbolic links and done this to you and would you have ever figured it out? Probably not all right so what was the other question if I just delete a symbolic link so a symbolic link will just point to another name so I can't delete the I note it refers to so here let's get rid of stuff so c.txt so I'll recreate to do.txt so what do you want me to delete here? so just delete to do.txt or just remove it, unlink it so if I do that then b.txt is just name to a name it's still going to point to do.txt to do.txt just doesn't exist anymore so if I try to cat this it will also look kind of confusing so let's say b.txt no such directory or file which gets a bit confusing because b.txt does exist what doesn't exist is to do.txt so it gets a bit confusing all right any other questions about that one? We've kind of figured it out so so yeah what about if we did all of this so touch will just create a new file and reset all of the parameters of it like all the time stamps then here we create a hard link called b.txt to refer to the same inode as to do.txt then if we create a soft link called c.txt that points to to do.txt and then similarly for move all move does it doesn't move anything all it does is rename that name so it doesn't actually move anything that's why no matter how big the file is move is fast so it doesn't matter because all it's doing is changing the name it's not changing the inode or anything like that the contents of the file stay the same all it does is just change the name points to the same inode so now if we do remove b.txt well what does the file system look like before and after the remove commands so for this before the move we would have c as a sim link that points to to do.txt because soft links or sim links are name to name and then to do.txt and b.txt refer to the same inode so if I do this move all I'm doing is changing the entry called to do.txt to d.txt so or to yeah to d.txt so now d.txt and b.txt refer to the same inode and c.txt because it's a soft link just refers to the same name to do.txt which doesn't exist anymore which is the exact same thing we just saw so now if I do the remove b.txt well it's gonna be the same thing I just removed that name that inode still exists all my data still exists I'm all good so any questions about that whirlwind of ls and other things you can do too that are fun is if you want to see information about a file like all the information that's on the inode you can use stat so if I stat c.txt it will tell me whoops so if I stat c.txt it'll tell me all the information about it so aside so this is the name that I refer to it in directory that's not on the inode itself but all the rest of this information is on the inode so tells you the size of the file in bytes the number of blocks it takes which looks weird that my file that's ten bytes takes up eight blocks why when it just take up one well ends up it does but for some reason don't ask me why when that refers to blocks they are of a set size so those blocks for some reason again don't ask me why they are five hundred and twelve bytes why I don't know they're just hard hard-coded five hundred and twelve this tells me my IO block size so that's my real block size on a device so if I take four thousand ninety six and divide by five hundred and twelve that's where the eight blocks comes from so it only actually takes one IO block but it takes eight five hundred and twelve byte blocks because that's their weird hard-coded value and don't ask me why because I'm not that old although that's debatable I guess to you guys and then they'll also tell you some other information that we kind gloss over so the device is what physical device is files actually located on so if I had multiple drives it would be have a different number here that has the I know number itself the number of links to it this is the mode and then the owner with the user ID the group owner with the group ID and then timestamps so this is when it was last access so last read the contents of the file this is when the contents of the file were last modified this change might think change and modify mean the same thing so this change means if the I know it self was changed so modify is the contents like the actual contents of the file and change is any modifications to the I know it self why it's kind of confusing I don't know and then birth is whatever this file this I know it was originally created and all of these timestamps you can change at will if you know the correct system call and you have permission so that's why generally I don't really care about timestamps because you could change them if I wanted to I could change it to I created this file in 1969 and yet that was way before I was actually born so don't make jokes about that so yeah you can just change these all you want in your lab six while you'll be creating I knowed so you can put whatever time you want the marker just checks if you have like a time of the same right year because yeah but you can put whatever time you want there so any questions about this stuff so if you've like an elective course cough cough you can change the timestamps and be like yeah totally totally submitted before the due date maybe this course is maybe less less trustful but yeah timestamps are just data on the I knowed well yeah yeah all the numbers after the dog yep yes so here so like these numbers right yeah so the timestamps have like nanosecond level precision sometime why it needs to be that precise well but they are that precise on some systems mostly they went up to like sixty four bits you can shovel of information there so I guess someone figured why not I think originally they were millisecond level but hey now they're like nanosecond which I guess is cool do you really need that probably not but if you want to see the nanosecond granularity you can use that yeah how do you modify them so yeah you can use the touch command so touch actually just modifies the timestamps and here stamp use this time stamp instead of the current time modify whatever you want access time modified time where you want so touch will do that so let's see if I just stat c dot txt I can see all of the timestamps are like fourteen twenty one forty thirty if I do touch if you give it no arguments I think it just sets it to the current time all of them so let's see if that's real so yeah it doesn't change the birth but it updates the modify access and change time all to be whenever I just ran that touch command and they're all the same but you can that's essentially what the touch command does but all at the end of the day it's just a system call that you make as long as you own the file you can change whatever you want about it so all touch does is update these timestamps it doesn't change the contents of the file or anything right any questions about that I probably should have taught you that but I mean it was one man page away in Unix everything kind of looks like a file so directories also have an i-node and there's nothing special about them except the contents of a directory are just have to follow a specific format you'll find out that directories all they are essentially a list of tuples and the tuples are just named to i-node and that's all directory is this is full of name to i-node name to i-node that's all directory is however many entries are in the directory well that depends how many names are in this directory so for example right now ls-la the actual directory which is like this i-node this i-node whatever 60 at the end well that would have the contents of that i-node would actually be like dot to this dot dot to this i-node b.txt to this i-node c.txt to this i-node that's all a directory is it's not special so the v-node can represent different things like a socket or a pipe or anything like that so in the case that your file descriptor refers to an actual file that v-node will actually be an i-node because that's how it can access the bytes of this file through an i-node so if your file descriptor is a real file that v-node is actually an i-node which is cool now we figured out how that kind of works any other questions with that stuff yep so the v-node is just like a virtual node in the case that that file descriptor represents a real file the v-node would be an i-node because that's how I access those bytes through the i-node that knows where they're actually located on the disk and everything like that yep index node yeah so i index node because we started off with the idea of an index allocation that's what this is essentially just multiple levels and slightly complicated although it's not bad after we have got through the hell of page tables so basically the same idea as multi-level page tables alright so we can do quick quiz so what's stored on an i-node so quick is the file name stored on the i-node no you're at right file name where's the file name stored in the directory right because the directory is just named to i-node that's where the names exist just in the directories so the containing directory name is that in the i-node nope yeah that's just within the current directory it would have an i-node or a name called . that refers to itself is the file size in the i-node yep is the file type in the i-node spoiler yeah number of soft links to the file yep yeah so there's a few other bits that you'll see in lab six that tell what type of file it says for i-nodes basically i-nodes can be like soft links directories or regular files and that's stored in the i-node itself so it has like three options and you'll see more of that in lab six too because you get to create your own i-nodes alright so the soft number of soft links to the file that's not stored in the i-node because well they're just names in the directory that point to other names the location of the soft link also not in the i-node what about the number of hard links to the file in the i-node yeah so that's that links one and if the links drops to zero then we can actually delete it although your operating system is probably going to be lazy and just market is unused because it's actually slow to delete file what about the location of the hard links hmm no not really access rights yep timestamps yep and I accidentally showed you how to change them what about the file contents they point to the file contents in the case that we optimize it and it's like really short it might be but that's like a little caveat what about the order list of data blocks yeah well that's kind of what the pointers actually are so let's see if we're right so yeah so soft links we don't know, number of hard links we do know the location of the hard links the i-node itself doesn't know what names refer to it it's just a dumb data structure that just points to the contents of the file so if you just know an i-node number well from the i-node itself you don't know what names actually refer to it you'd have to walk the entire file system to figure out all the names that refer to that i-node if you want to yep yeah so in so technically a soft link is also an i-node so I said name to name that's just a shortcut technically an i-node or a soft link is name to an i-node that i-node has a name yep yeah so in this case this i-node which is points to a name the contents of that i-node is just to do .txt so it really looks just like a file like the contents but you just interpret the contents of file as a name instead so here the size is eight so the sim link itself would be an i-node so a directory is only name to i-nodes and it's a bit of a roundabout process because technically a soft link is name to an i-node and that i-node points to the name but usually when you think about it you just think of a soft link as name to name because that's how you use it the intermediate step doesn't really matter that much yep so if I just go ahead and create to do .txt so like right now if I edit b.txt so yeah if I edit b.txt while it would follow me through to to do .txt then get that i-node and then that's where things are actually stored so yeah if I modify this then it should actually modify to do .txt because I modified the contents of that i-node so if I can't it's the same thing right because I eventually get that i-node the only way to actually like change the contents of the i-node or the soft link itself is just changing the name if you wanted to uh I don't know if you can open it in an editor hey oh wait what's my soft link called oh yeah so sometimes you can tell programs to not follow soft links um because that's one level of exploit for some web servers if you can just upload any random file well an attacker if you allow sim links can just create a sim link that brings them up to root and then they can access any file on your system through that sim link so generally web servers will turn off following sim links so if you put a sim link in a web web server directory the web server won't actually follow it but that's like a fun security fact because yeah soft links if you just let users create soft links that's uh not great all right well we use a lot of time oops so file systems are going to cache data blocks and try and speed things up they're going to be lazy so one thing like writing data to the disk is slow especially since to modify it I would have had to read it into memory so what they do is just use a cache so file blocks that are cache and main memory there'll be some file system cache to cache the blocks I read in from a device and generally whenever I'm reading blocks if I'm likely to reference the same block over and over again so if I'm modifying a file or something like that so using the same block over and over again is something called temporal locality so it's if I just used it it's likely I'm going to use it again and logically if blocks are near each other you might use them so if I open the first block of a file and I'm modifying the entire thing I'm probably going to modify the second block of the file so if I want to speed things up I can just read multiple blocks at a time or prefetch them and load them into memory so things get faster so what your kernel could do also is whoever you modify a file it could just write it to memory and not the disk and try and fool you into thinking it went really really fast and there can be a kernel thread that actually does the writing to disk in the background when it's otherwise not doing anything so sometimes when you modify a file and then you pull out the power cord well your disk is supposed to be persistent but if it was actually cached and it didn't write it out you might not actually see your changes on the disk and that's what the commands flush and sync do they will trigger and force that write cache to clear out and actually write to the device I've encountered this a few times and we're probably over time where I copied file to USB drive and happened instant like that even though I knew it was a crappy USB drive that's because all it did was fill up a cache and didn't actually write it to the device then I called sync and that took forever because it was actually forcing a write to the USB drive and with that we're out of time so just remember pulling for you we're on this together