 All right, good afternoon. So we're doing lab six today. So lab six, very exciting. That will be our file system. So we'll actually start writing some code today, getting you ready to actually finish lab six, hopefully in time so you can get hammered by all your other courses. So who here has actually read lab six a little bit? All right, we got like the right half of the room, the good half of the room. Okay, so let's get into it then. So for this lab, you will be writing a file system. It will be one megabyte and there are a few things already done for you. So things already done for you. It has created a file for you. That is exactly one megabyte. So let's go ahead and look at main. So just so we know what we're doing. Oops. So you don't have to modify main, but you should probably read main to figure out what it's actually doing and to kind of help guide you. Some of these are provided for you, some are not. So your main output of this is a flat file called hello.image and that's supposed to represent your actual hard drive or whatever. And that's where we will put the file system on. So we're not actually going to make it hard drive or anything, we're just going to use a file instead. Yeah, the question? Yeah, so it's not a picture. Typically people call something an image if it's just a bunch of bytes and it just looks like a file. So yeah, this is not actually an image or anything you can draw. Well, you can try and draw anything and try and look at it, but it will be mostly zeros which zero is what is black. So it'll just look like a black image if you try and render it. So this will open something called hello.image and then there's a system call we haven't been introduced to yet called ftruncate and this is just so it resets the size of it. So it makes the size of that file zero and then after that just to wipe out like your old work if you're regenerating this file and then it's going to make it num blocks times block size. So in here we are assuming our disk has blocks of size 1024 or one kilobyte and we're going to assume we have 1024 of them. So if we multiply those two numbers together we're assuming our disk is one megabyte in size. So this will create a one megabyte file and this is just a file for us but in actuality and hardware this would actually be all of the data on your actual physical hard drive. So after that there are a few things that make up a file system so we haven't really seen this before and that's the purpose of this lab. So the first bit to describe a file system is called a super block and that tells you all sorts of information about the file system which we will get into but it tells you what format it's in, what it's called, the volume name, whatever it's called, whenever it's been last modified so on and so forth. And then as part of that, we already know that hey our file system needs to actually it contains inodes which we know of and then inodes point to data blocks which we also kind of know because this is just a bunch of blocks but we actually have to give it a bit more information to actually find out. So other things in the super block it's gonna tell you how many blocks are in the file system, how big they are, so on and so forth and most of the numbers are actually given to you or we can kind of figure them out and we'll go over a few magic numbers today and then the next one we'll go over is the group descriptor table. So this is going to be a small file system where there's only one group table so that's basically a way to break up a very, very, very large file system but ours is really small, it's only one megabyte so we don't have to worry about there being multiple of these and these will tell you like how many inodes there are, how many free blocks there are and how many directories are in use for some reason, I forget why. And then there's going to be two bitmaps because remember we have to keep track of which blocks we're actually using and what inodes we're actually using so the easiest way to keep track of that is just to have a bit zero or one if it's in use and because everything else is just a fixed size and we'll go over a bit of this when we get to memory allocation but it's hopefully a fairly straightforward thing so if you want to check if a block is used, if you want to check if block, I don't know, 10 is in use while you would check if bit 10 in this block bitmap table is a one or a zero, if it's one it's in use, if it's zero it's unused and it's free so you can use it. So we can kind of figure out how many bits are within this so if our block size, whoops, so our block size is 1,024 bytes so if we want to figure out how many bits we have well there are eight bits in a byte so there are 8,092 bits in here so we can keep track of up to that many things which is way more than we have because we are only going to use 1,024 blocks so a lot of that space is actually going to be unused and wasted but we have to, part of the spec says that there has to be a block that has all those bits in it so that's where we actually keep track of what's in used and how the file system actually knows what blocks are free, what blocks are empty and what inodes we can use. So there's one for blocks, one for inodes so another thing to keep in mind here is that blocks they start at index zero which is kind of what we're used to because we're computer people but the inode bitmap it actually starts at index one so they reserve inode zero to have a special meaning of just being the null inode that's not supposed to represent anything so you can't use it, it's defined as being nothing so they start this numbering at index one which you might have some off by one errors and that's why because it starts at one so the next thing is there's an inode table to actually store the inodes themselves so we can kind of figure out how big this inode table needs to be so at the top here is a whole bunch of defines that I give you so the thing about this lab too is you can hard code just random values and hope they work out but you should probably use these macros to give some meaning to the numbers so that they just don't look hard coded and they actually have some meaning so up here there's a define for saying how many bytes large a block is so it's 1,024 and then this is the block offset so if you want to go to block, I don't know, block two of your file while you need to go two blocks of bytes into that file and then that's the start of block two so that's just a little macro so you can go ahead and move at will then here it's the number of blocks in this again we're having a one megabyte file system so there's 1,024 blocks of one kilobyte size and then here this is just a number you're given so there's going to, we're just gonna use 128 inodes and if you look into it here so if we want to figure out how big our inode table needs to be well, whoops we have 128 inodes and then each inode itself if you do like the size of the inode structure which we'll go over later they are 128 bytes per inode so if we multiply these numbers together how many or how many bytes do we need to store all of our inodes so we can whip that up so we need like 16,000-ish bytes to store all of our inodes so inode tables are going to span multiple blocks so if I need 16,384 bytes how many blocks do I need to store all of these inodes who's good at math yeah 16, yeah, so we can go ahead and we can just use Python to cheat if we really want whoops, why am I hitting that but 16 so we can fit eight inodes within a block so if we want to store 128 inodes we need 16 blocks to store all the inodes so if I go here so does that make sense to everyone why we need that much space okay got at least one thumbs up okay so if we draw out what our data blocks look like this is what it looks like so there's a few weird things in the spec when you read it that you will see actually I'll go to that first so also in the lab doc there are two links to help you figure out some of the fields if you are very very confused so there's the first one that is just called the ext2 file system and it will tell you all you need to know about whatever field so if we want to figure out things about the super block you can click about the super block all these structures are provided for you in the code and this kind of explains them a little bit more and what they're given by but I'll try and explain them a bit today but this has lots of different things it explains all the group descriptors it explains everything and then there's also this other link that also has the internal layout of the ext2 file system so again if you want to figure out what each individual field does we can do that and we'll go explore this and try and figure it out so any questions about like the big picture of the lab or where we're at yeah yeah so let's draw a diagram of how this all fits together so if I if I take my whole file system and divide it into blocks so here I have my data blocks and I'll give them all a number there are a few weird things in this file system so by default block zero is said to be reserved so it's just reserved you're not allowed to write anything to it it is not part of the file system there are historical reasons to that main one being in the really old systems that's where your like boot code was to actually boot from that hard drive and actually like boot up a kernel and stuff like that not really used anymore but it's like a historical reserved thing that you're not allowed to use and the other starting off definition of the ext2 file system is you are certain that the file system or the super block starts one kilobyte into the device so in this case since our blocks are one kilobyte in size it means our super block is going to start right at block zero so block zero is going to contain our super block and it is as big as a block so as a fun thing if our block size was a bit bigger like if it was two kilobytes the super block still starts one kilobyte in so depending on the size of it the super block might be on block zero or on block one yeah so block zero you can't use it so this is our file system where our blocks are one kilobyte nope, nope the super block always starts one kilobyte from the beginning the first one kilobyte of your disk or whatever is not allowed to be used whatsoever so it would actually contain code on some things so your first block would be your super block and then that tells you all the information about the file system even that it is an ext2 file system which we will see is literal magic as we will get into and then there's a few other blocks that contain some data that we will also see so block two would like have the group descriptor which we'll see what the contents of that are and then we have block three so you could technically rearrange these blocks into whatever you want this is kind of the recommended arrangement and how everything is defined for you giving you block numbers so block three would contain our block bitmap that keeps track of whether or not blocks are allocated or free then block four here is our inode bitmap that keeps track of what inodes are in use and then after that is our 16 inodes so like block five would contain all the data for inodes one to 16 again because they start at index one and then they would go on for 16 blocks and then the last inode block would be block 20 which would have inodes 113 to 128 and then you're going to create some files here so you're going to create a directory a file and a sim link and what is given to you is a directory so you're going to the recommendation is to use block 21 to have the contents of the root directory then block 22 is going to be given to you we'll see that today that will be the contents of the lost and found directory which is part of the specification and needs to be there and then block 23 is going to be the contents of a hello file that's just going to say hello world in it and we'll see and we see that you're going to be creating a sim link but it's not going to contain any blocks because it's going to have that optimization we talked about before where it's so small we can actually just fit it in to the blocks without actually wasting a whole block okay so any questions about that big setup so that's our overarching setup yep yeah sorry symbolic links the same as soft links so those two words you'll find people just say interchangeably they mean the same thing yeah oh okay all right fake me out all right cool so also what you'll find in the documentation for some of the numbers that you might not be sure about this gives you the entire output of what a correct solution looks like so so you can see some numbers but we're actually going to fill in most of these today except for this so this these numbers you probably have to go back and forth and check out and then there's also another utility we will look at today called fs check and that will tell you it basically does is like an analysis on the file system and tries to check if there's any errors with it likely what will happen with this lab is you will check your file system as you implement a new part and it will fail at a brand new part and you'll get a little bit further along and you know fix the error check it again fix the error check it again might be one of the ways to go about it okay so any other high-level questions before we get into the fun code okay so right super all right so most of these functions you're going to implement are like the right block things so the first one you're going to have to start with as you start at the beginning you start with the super block so all of these functions are kind of given to you they give you the file descriptor of the image and you're supposed to use this l seek that we saw before that changes where the current position is in the file so if you do a right system calls then it would start writing directly to that so we do an l seek to the beginning of block one so now if we do a right system call to the file descriptor it would start writing one kilobyte into the file so does that make sense to everyone because this is how it's going to be the whole time so you probably want to copy and paste this so I move it to the beginning of block one because my super block starts at block one in this case okay so there is a super block structure and it says all of these are in potentially incorrectly set at zero you should set them correctly and delete this comment so right now everything is empty everything is zero so if we go ahead so I change it so you can actually compile it where's my thing oh there's a lot to go over today all right so if we compile it and then we run the program then it creates this hello dot image and then we can do things with it so one thing you might want to do to sandy check your solution as you're going is just dump e2fs and the second argument it takes is just a file and it will tell you all about that file system so it will tell you how many blocks it has how big it is like give you all the information about the super block but if we run it right now it's going to complain at us it's going to say bad magic number in super block while trying to open I don't think this is a valid file system which makes sense because it's all full of zeros so our first thing talking about this bad magic number in the super block and okay yeah there's a question about what does total seven mean so i'll get to that near the end so let's go here oops so this thing says bad magic in the super block so if we go to this documentation we can look it up and see hey super block there's this field called s magic and it says s magic is a 16-bit field identifying the system as ext2 it's currently just a value of ef 53 that's it so if magically these two bytes happen to be at that position in the file magic that's why they call it magic it just means it's an ext2 file system there's nothing more complicated than that it's just some magic number that we use so what you can do to start it off so if you have the code ready you can do this and follow along if not that's okay but in order to not have magic numbers we can whoops we can just define that so we'll just call it the same thing so ext super magic is just the value ef 32 so if we go back to write super block well we can fix this so there's this field magic and we can call it ext2 super magic so now whenever we output it now we're going to have that ef three or ef 53 in that position so if we compile and run it this will be literal magic it says that gives us a different error now it now thinks it's an ext2 file system it doesn't complain about not having any magic there we added some magic which everyone loves magic now just says it's corrupt while trying to open which means we have to do some more work so let's start filling in these fields so if we start at the number some of these fields are pretty straightforwardly named and i kind of give you all the definitions for them so the first one is hey how many i nodes are in this file system so there is currently something just there's a defined called num i nodes and that is the 128 so that's just the number you're going to use we just picked it because that's enough i nodes to support a really small file system then the next one is how many blocks are in this file system again same thing we have a defined called num blocks so far so good now this field is the number of reserve blocks that sometimes the file systems reserve some blocks so that if something if the disk gets full or something like that you can't actually use these blocks so it has some room to move things around for us we don't care we won't reserve anything and then here there's a number of free blocks and a number of free i nodes and this should jive with how many things are actually free in those bitmap tables and everything so there's already some defines for you that tell you what the final result should be if you follow the recommended layout of the file system so there's going to be num free blocks and also going to be num free i nodes so next field says what is the first data block so the first data block is actually not block zero it's where the super block is so the first data block for this file system is actually one and then the next things are already done for you so these are kind of weird fields you'll see it's log block size not just block size so whatever you set this to it's two to the power of whatever this number is plus 10 so if this number is zero it means our block size is one 1024 which is what we want if we made this equal to one it would go up to you know 2048 so on and so forth but for us luckily enough luckily enough for us we can just set it at zero because that's our block size now here we have number blocks per group and number fragments per group and that basically is asking you how big the bitmaps are so it's basically how many bits are in a block so if we use our macros we have block size so that's how many bytes are in our block and if we want the number of bits what should i do times eight perfect so that's how big our blocks is fragments pretty much the same as blocks we won't worry about it so for us we can assume that they're the same then the next one is the number of i nodes per group for us we're only going to have one group so it's going to be the same as the total number of i nodes so it's just going to be num i nodes and i think that is good so we've made some nice progress we can compile everything works we can create a new hello dot image and then we can go ahead and see what we got so now it actually gives us some output so we've made a lot of progress so now it thinks there is a valid super block there and gives us some information about it so let's dive into it so now it gives us all this information the file system volume name is hello it's last mounted on never it's uuid is some leet coffee coffee see its magic number revision da da da da da da and eventually when you're done you can go ahead now it actually looks kind of like this that's provided for you so you can go ahead and make the numbers actually line up if they haven't but they should yeah sorry yeah so the log log block size is zero because this is actually it's going to be two to the power of 10 plus whatever this number is so right now the log block size is zero so it's going to be two to the power of 10 plus zero which is 10 to the power of 10 is 1024 yeah so we can just leave that zero and we're good all right cool so that gets us started doing that and we can see here that gives us all that fun information we want but we can see some weird things like this the last right time was December 31st at 1969 so that's a little bit old so you can actually kind of tell where the timestamps start so remember everything's initialized to zero so it's just reading zero and apparently to this zero time beginning of the universe 1969 so that's when it started that's apparently when the universe started so don't ask questions about it so if we wanted to fix that we can see that we can probably guess that this last right time and last check probably correspond to this w time so this is right time so at the beginning there there's a variable for you called current time that will tell you the current time so instead of that we could write current time and then last check current time and hopefully we get something a bit more recent than 1969 so now we modified it again so now our last right time is right now so you'll find you'll discover more about the file system maybe fields you miss but this is generally most of them and you'll go back and forth and kind of debug until you actually have a valid file system so you can see that here well this gives you a hint at your next step if you want to progress and it says a block group is missing an inode table so it currently doesn't have an inode table because well we haven't made one yet so any questions about where we're at so far so we actually so i pretty much did the super block for you so the next thing is going to be so as you're going through this well you can use that to kind of guide you as to what to do next so i more or less did write super bike block properly so the next one is going to be this group file descriptor so this group descriptor table it starts at block two i probably shouldn't use block two there's actually macros to give you block two there's like block number macros but here i'd start at block two and then it has a zxt2 block descriptor structure and here it tells you all the fields so these just say what block or yeah what block is my block bitmap in which is given to you at the top in the defines where's my inode bitmap where does my inode table start how many free blocks do i have how many free inodes do i have and how many directories do i have and then at the end of all these which you'll probably copy and paste it just takes that structure and then writes it directly to the disk and because we did that seek at the beginning of block two it would just write it directly at the beginning getting a block two so that it's actually now part of the file in the correct place all right any questions about that so we got 20 minutes left okay so more defines up here so there are a certain number of defined inodes that you are not allowed to use so other ones so zero means null it's not even something you can allocate one it has a special meaning where it is a bad inode then surprisingly enough the root directory it's just given a special inode two so the root directory is always inode two and you can verify this on your actual system so i can go ahead and look at my actual system look at my directory and see that hey this is my root directory there's a dot and a dot dot and over here is the inode number and it's two it's literally just two so how do you know what the root directory of your file system is inode two that's the answer so you'll find the more you get into learning about your actual computer and operating systems there's just magic numbers people made up and that's how anything is found yeah so inode one supposed to just represent a bad inode that you're not supposed to ever use and then i don't know how that's different than zero inode which is a null inode so but apparently they wanted it yeah sorry oh yeah so i can yeah so oh yeah well that's a good point so it looks like the one inodes actually used here so you'll see that these directories are actually not real directories so we've been through like proc before right and we know that that those aren't real files those are just kernel interfaces and just looks like a file so like the proc directory is file descriptor one so it's just yeah i guess it's a placeholder for just things that don't actually exist on the file system like it's not a physical file it's something the kernel makes up it needs an inode number because it needs to have a name and actually exist but kernel doesn't really care so it's they're all inode one so you'll see weird things like that so there's a few other ones that are defined for other uses so they are reserved up to inode 10 so the first inode you're actually allowed to use for your own purposes is inode 11 so here if you follow the recommended layout whoops i think they should also be defined sorry yeah so here are the recommended inode numbers to use so it says use inode 11 for the lost and found directory and i actually give you the lost and found directory implementation we can look at right after then says use inode 12 for hello world which i believe is the sim link or the other way around i think that's a file and then the inode to use for the sim link or soft link called hello so use 13 and then that's last inode and then these are all the block numbers to use so you could fill in that group descriptor table by using these block numbers and then you go fill in the other ones with all their values and such so okay so let us go into the directory one so making a directory is kind of more involved so i give you an example directory so as part of the specification it says there has to be a lost and found directory in the root directory so i give you the lost and found directory but you have to actually make the root directory yourself so let's see what that looks like because it's a little bit weird so yeah so there's two parts of it right so your lost and found directory it will have an inode component and then it will have the actual data so we've kind of seen the inode before so do you want me to go over the inode of the directory or just go into how the data is or we don't care inode okay so there are some nice functions in the inode table for you so what this will do there is a function called write inode it writes and it writes that inode in the correct place starting at the inode table which saves you a bit of work so we don't actually have to look at that code sorry write inode table okay so if you write an inode table well we create our inode so there's struct inode and that represents an inode so it's exactly the layout we saw in class whenever yesterday or one day or whenever we went over inodes and it has all the structures you would assume so there's this mode that keeps track of all the permissions and they look a bit ugly but these are all the all the ones so as part of the mode it tells you what type of file it is so this defined here is the bit that says whether it's a directory or not and then these are read permission for the user write permission for the user and then execute permission for the user and then read execute for the group read execute for other so that's just all the permissions other things in here is like who owns the file so it's just again a number the user id of the owner of the file so in this case we're going to say root owns it root is just another magic number it's user id zero so if root owns a file it's user id zero and same with the group owner which is gid or group id so that's zero and then other things in it are the size of the file so in this case all our directory entry will fit in a single block and the weird thing about ext2 is like this would actually be the size of the file so if it's like hello world and it's only 12 bytes long the size of the file would be 12 bytes but if you look at the definition for directory entries they have to fill a whole block so it always has to be multiple of the block size and for the purposes of this lab all of our directories will fit in a single block because there's some complicated things you have to do if it's over a block so for this every we assume everything fits on a block so directory entry is block size which I should probably use the macro for and then here are all the access times so I just say they're all equal to the current time and then we have the number of links to it so there's supposed to be two links to it so two hard links to it and as part of this lab you'll have to count the number of hard links the utilities there that actually check the file system will help you with the numbers because it will double check that they're right and then the next one is how many blocks it occupies remember when we went through them for some reason blocks are defined in an inode as being 512 all the time so to move from inode block size to our block size well there are two inode blocks that contribute one of our blocks and then these are the pointers so the block array is just an array of pointers and in this case what they're pointing to is just the block number so the contents of the file are the contents of this directory are actually going to be on the lost and found block number which is just 11 or sorry which is just 22 so we're going to store the contents of the directory at block 22 and then we call write inode and we call write inode give it the inode index and then this function will take that inode structure and actually find the right place for it in the inode table so you don't have to worry about figuring out what block it's in or anything like that it will go ahead and do it for you and then after it does that it writes it now it's on the disk and everyone is happy okay any questions about the inode so you're just creating so this one's done for you and then you'll create a directory file and a sim link so for the actual contents of the file directories are a bit weird so here we defined as part of our inode where the contents of the file should live so we do that block offset thing to go to the lost and found block which again is 22 and then whatever data we write will be available there so so the contents of a directory are just a bunch of directory entries which are essentially just a little tuple that don't tell you that much information so if we go and look at the structure so as part of it I wasn't lying to you before so it says the entry just has what inode should this entry refer to and then there's a weird record keeping length so that's how long this entire entry is so you don't have to worry about this because it has some weird rules where that always has to be a multiple of four or in other words it has to be a line to a four byte boundary so I give you helper functions where you don't have to make sure it's a line to four it does it for you and then here is the name length so it's just how long is the name and then this field the name is the actual bytes that make up that name and you'll see here that you can have a file name of up to a 255 characters so that's the limit of a single file name within a directory all right do we notice anything like kind of odd here about the types so my name can only be up to 255 and I can support up to a 16-bit length any alarm bells for anyone or just me so if I had like something like that it is that big enough to represent it 2 the 8 is you know 2 the 8 2 the 8 is 256 yeah yeah so this was like an oopsie in the spec so this name length given how big a file name could be is actually too big like the upper byte is always going to be zero so if you look at other revisions of this they repurpose that byte to use as something else so but for us we'll just ignore it it's just a fun little fact so let's go back down to it with it right lost so we're just going to make a bunch of entries so there are some entries that must be within a directory so there must be a dot and a dot dot so that's not anything your shell made up or anything those are actual physical entries inside of a directory so here we create an entry this equals zero that just zeroes out the whole structure so we have a fresh start and then there's a macro for you to actually set the fields and actually it does the offset for you so everything is aligned and it it actually populates that record length as being the correct value for you so here we say that we want to modify the current entry we want to make it the inode point to the lost and found inode and we want the entry name to be dot so dot always points to yourself so again this is just the tuple inode name and then for the details it computes all the lengths for you and then we write that entry to the block so it's actually there and that function will actually do the right thing as well so you'll see here that i have a bytes remaining variable so i have this because and this is why i gave it to you because directory entries are weird and you have to keep track you have to actually fill the entire block and all the numbers have to line up so you actually have to keep track of how many bytes are left in your block so the record length is how big that entire entry is and that's calculated for you as part of that macro so just subtract it from the block size and then make whatever other entries you need so the other entry we need is the parent entry so we need an entry for dot dot and the lost and found directory is going to be found within the root directory so if you do dot dot from there it should go to the root directory and that's just given as the inode 2 so the parent of lost and found is root so we create an entry for dot dot we do the same thing we keep track of the number of bytes remaining and then at the end there's only going to be two entries in lost and found so we have to make an entry that contains all the rest of the bytes for the block so it just needs a record length of bytes remaining and then we write it and then that's it so that's a directory so directories aren't that special so yeah uh yeah so the question is does the root directory also have a parent and yes but the root directory gets to be recursive so the root directory's parent is itself so we can see that too if we go look at this and look at your actual file system so you'll see dot and dot dot both point to two so both the current directory and the parents root directory is equal to two and we'll see that the parents yeah okay so let's go ahead and try some other things since we don't have that much time so other things we're going to want to do that will help you along this lab is let's see so that fs check is going to be helpful so as you go through this you'll have fs check and you can do it with your image and it will essentially analyze it make sure everything lines up so in this case it says the block bitmap for group zero is not in group which we didn't set it typically with this the first error is the one you should pay attention to and then the rest it's probably nonsense because the first one didn't make any sense and then it's just trying and guessing but it's also asked if you want to fix things which is kind of funny so i can say yes yes and then it gives me nice little warnings like i know table for group zero is not in group warning severe data loss possible which is definitely a warning you'd love to see so of course i will hit yes and then it says here it says relocating group zero is block to blocks that i don't want and then it checks and it's also giving us a bunch of warnings this doesn't bode well but we'll try and go on so if these utilities start giving you snarky messages you probably have screwed up so you should probably just abandon abandon all hope and just look at the first error try and fix it and go on from that because it tries to do all sorts of random stuff and you'll see how far along you get by how snarky it gets okay so yeah there's the fun thing too about once you're done or further along you can actually see the contents of your file system like any other one so here i can make a directory called mount so it's just a directory sitting in here there's no contents of it and then what the mount command will actually do is use that directory and put the file system there so this is in the lab doc so if you use oloop it means use a file and here i'll use the solution so after this command if it's successful and you have a valid file system that file system is now available through that mount directory so if i cd into mount it looks like anything else but this is going to be your file system that you make so you set all of these numbers so if we look at it we see that hey the root directory is dot which is zero and then we can see why there's actually a parent of root because it might not actually be the root of the file system right so i actually mounted this in the mount directory so what the kernel did as part of the mount command is change the file system's root parent to point to mount because that's where i just put it so this gigantic i-node number here well that's going to be the same number as as mount mount okay not the same number as mount because the original mount that is on the file system so this actually looks like the file system you mounted on it yeah it overwrites it sorry so here goes into the root file system of our file system and dot dot is the original mount entry so if we unmount it and look at it that's what it would be and these are all the contents of our files we can use them at will and i guess we're out of time i think that's everything important so if you need more help or whatever finish this lab as soon as possible so you can do other not more important things but things that will help you not get stressed out as much because nothing is more important than operating systems of course so just remember pulling for you