Hello, and welcome back to CS615 System Administration! This is week 02, segment 5‥ When we talked about the physical structure of the traditional hard disk drive in our last video, we mentioned that understanding those aspects would help us better understand other filesystem concepts, and one of those is the topic of this video: partitions and partition tables. That is, this time we'll talk about how to divide a single disk -- physical or virtual. So let's start with a little pop quiz: --- What's wrong with this image? What you see here is the 'Disk Utility' interface on macOS, whіch presents to you a graphical representation of the partitions you might want to create on a disk. In this example, we have a 1 gigabyte disk that we divide into a 100 MB boot partition, a 256 MB root partition called "slash", a small partition of raw disk space left for swap, and a "usr" partition using the remaining disk space. 'Disk Utility' shows us these partitions as pie wedges of the whole disk, which is a bit irritating because... that's not how partitions work. Well, at least not on a traditional hard disk drive. Because... --- suppose it _did_ work that way. Then we'd have our disk drive here and we'd create - a partition, like this. But now as we discussed in our last video, we know that data on the same partition is likely to be accessed sequentially, meaning if we wanted to read a few files from this partition, we'd - end up seeking all over the disk. This would be quite inefficient, to say the least. So let's rethink how partitions are _actually_ laid out on the disk: --- Rather than using a pie wedge, we will use a number of cylinders that we group together - and create a partition that looks like this. That is, all the data on this partition is now stored within this ring of cylinder groups. Accessing this data will be _much_ more efficient, as we now reduced - the seek time and can read and write data from the spinning disk without much movement. So rather than using the pie wedges Apple's 'Disk Utility' showed us, let's visualize our partitions --- like this. So we'd have - one small "boot" partition, which is typically kept at the beginning of the disk. Remember, in our last video we talked about a disk possibly being larger than the BIOS can address? For this reason, the historical layout places the "/boot" partition near the beginning of the disk, so that the OS can boot up and then possibly use partitions that the BIOS cannot, but that the OS _can_ address. Now this is largely a historical factoid as modern BIOSes and boot loaders can handle large disks, but it explains why you still sometimes see separate "/boot" partitions in the first cylinder group of the disk. Next, we might want to create a "swap" partition, - which would then begin right where the "/boot" partition ends and extends to cylinder 228 in this case. After that, we create the - root partition as well as the - "/usr" partition, filling up the remainig cylinder groups. Ok, so we understand why the partitions are arranged by cylinder group, and that is actually precisely _how_ we partition the disk: by describing the layout using cylinders. Let's see what this looks like in practice: --- We start a NetBSD instance... ...and create a new volume, so that we can illustrate the creation of a disk layout just like the one we just presented. We attach the volume to the instance and then wait for it to come up and log in. On NetBSD -- and other BSD versions -- we use the "disklabel" utility to display the partition table, and what it shows us here is 512 bytes per sector, as we'd expect, 2048 sectors per track 1 track per cylinder and a total of 1024 cylinders. This, then, gives us the total number of sectors and thus the total capacity of the drive, as we discussed in our last video. Now note that this disklabel also tells us that both the boot block and the super block are size zero here. What that means, we'll cover in future videos, but let's go ahead and edit the partition table. Here we start out with partition 'a'. We'll start it at sector 63 to match a regular bootable NetBSD partition. Why 63? Sit tight, we'll get to that in the next week, too. But ok, let's specify the size as 100 MB. This now shows us the size in sectors, which we can confirm via some trivial shell arithmetic to indeed be 100 MB. Good. Let's continue then with the next partition, partition 'b'. We'll make this partition a swap partition, have it start at the end of partition 'a', and make it 128 MB in size. Next we use partition 'e' and... [pause] wait, why do we skip partitions 'c' and 'd'? Well, on BSD systems, partition 'd' is traditionally reserved to simply describe the entire disk, and partition 'c' as the part of the disk that's reserved for this OS. Here, too, we'll get back to this again later, so let's continue with editing partition 'e': [continue] We'll make this partition start where our swap partition ends and size it to 256 MB. Now we finally add the last partition, partition 'f', which begins where partition 'e' ends, and extends to the end of the disk. Now that we've finished carving up our disk and writing the partition table, we need to write this disklabel to the disk, and then we can quit. We can display the partition table again using the "disklabel" command, using the cylinder-head-sector addressing here. Now we see how the partitions shown here match what we had illustrated earlier with our cylinders, but we also see that partition 'd' spans the whole disk, as I had just mentioned. Ok, so now we could move on to create filesystems on the partitions, but that's the topic of our next videos, so first let's compare what this looks like on a different operating system. --- Here we start an OmniOS instance and again another volume. Same procedure as before: we wait for the instance, attach the volume, and ssh to it. Now on OmniOS, we use the 'format' utility to inspect out disk. You may remember from our earlier videos, that OmniOS uses ZFS pools by default for the root filesystem, so instead let's look at the separate disk we attached, disk c1t5d0, which is shown here with its geometry of 1022 cylinders with 2 alternate cylinders, 64 heads, and 32 sectors per track. When we select this disk, the tool informs us that no Solaris 'fdisk' partition was detected. This would be the Master Boot Record partition for the disk, so let's create one of those by calling 'fdisk'. We'll accept the defaults and display them here. [pause] This gives us a default partition table in which we notice that similar to the NetBSD 'd' partition there's a partition here reserved to represent the entire disk, partition '2', labeled "backup". We also notice that this OS has two cylinders reserved, partitions 8 and 9, which it may use for alternate boot blocks. Again, more on that in our next video. [continue] But this is not the layout we want, so let's call "partition"... ...and change partition "0". We call it a "boot" partition, mark it as writable and mountable, let it start at cylinder 0 and give it the 100 meg size. Then we edit partition 1, mark it as "swap", mark that partition as writable but unmountable have it start at cylinder 100 and make it 256 mb in size. Next, partition 2... no, wait, partition 2 describes the whole disk, as we said, so let's edit partition 3 as the root partition 256 mb in size, and finally partition 4 for "usr" using the remainder of the disk space. And here's what the new partition table now looks like. All entries neatly reflecting what we had requested. So let's write this label to the disk and quit out. Then we can use the "prtvtoc" tool to print the "Volume Table of Contents", which just displays this same partition table. As you see, while somewhat different from the NetBSD example, there's plenty of similarities. So let's quickly also compare this to how you'd do this on Linux, ok? --- Again, same procedure as before. This time, we use a Fedora instance. Attach the volume and ssh to it. Whoops, we have to use the 'fedora' user for this instance. There. Ok, so here we start with the "fdisk" command, displaying the current partition table, which contains no entries, so we only get the disk geometry. Let's use the "cfdisk" tool to edit the partition table. This tool has its own peculiar syntax, but to specify the first partition, we enter ", 100 MB" here, then specify the information for the second partition, then the third and the fourth. The resulting partition table looks like this, and we write the label to the disk. Now since this is Linux, we have about another half dozen tools that could do the same thing in a different manner, so let's use the "cfdisk" tool to verify the layout, why not. Here we go, a nice menu-driven interface. Ok, everything looks kosher. ...and lsblk, which we remember from an earlier video, also shows us the correct partitioning of the disk. --- Ok, so let's recap: - We've seen that partitions on hard disk drives are groupings of cylinder groups into contiguous regions, and thus cannot be visualized as pie wedges, even though that's a common representation in many tools. - We've seen different partition schemes and have mentioned different types of partitions; - and we saw that even though different operating systems may use different tools and have some other slight differences, the overall concepts remain the same: we utilize cylinder groups, tracks, and sectors to address the blocks and define partitions, with a description of these partitions -- the partition table -- being written to the disk. - We did hint at the fact that BIOS or MBR partitions are different from OS partitions, but we haven't quite looked at _how_ they're different. That will be covered in a future video, so don't worry. - One of the perhaps peculiar things we've seen is that partitions may _overlap_. That is ok, however, as it depends on the purpose of the partition. If we want to describe the entire disk, we need a way to do so, and logically other partitions will be comprised within that larger partition. - Finally, we should quickly note just _why_ we may want to partition our disk, rather than just using all the disk space we have in one giant blob. The reasons for this include - a desire to separate system data from user data, so that for example users writing to their home directory cannot fill up the system partition. Another reason might be to separate the boot partition from the rest to allow the bootloader to bootstrap a system that can address a disk that's too large for the BIOS, for example. - Another reason might be that we may wish to use different _types_ of filesystems for different partitions. Again, we'll talk more about this in the next few videos. - And finally, we sometimes may wish to apply different mount flags for different partitions. For example, you may wish to mount the system partition as read-only, so that a compromise of the system cannot lead to a persistent compromise by installation of a backdoor. Or you might want to mark a partition as nosuid or noexec to further strengthen security, or enable or disable asynchronous IO on the filesystem. There are many other reasons, and we'll soon enough revisit many of them, as these topics continue to build on one another. So make sure to come back to this and the previous videos, even as we prepare to move forward to filesystems, bootloaders and how the system bootstraps itself. Until then - thanks for watching! Cheers!