Storage: HDD and SSD Partitioning and I/O Operations

This is actually a really good question, because it allows us to take a look at some of the things that are easy to misunderstand; namely, how much control we typically have over how our computers write to storage devices.

Before we get started, it might be useful to understand how data gets from an application to your storage device. If you’re interested in an easy-to-read comic about it, it can help give you some background (though it’s certainly not a requirement).

Now, on to the answer that specifically addresses your question:

Data is written to hard drives and SSDs in fundamentally different ways, though there are certainly some fundamentals that are shared. In order to understand this, bear with me while I get a little in-the-weeds for you.

Hard drives work under the principle of spinning disks, called platters. This part you may have already known. If you were to take apart a hard drive, it would look something like this:

If you were to “zoom in,” you’d see that each platter is broken down further:

These disks are broken down into tracks, sectors and, even, further, blocks. Now, in a hard drive (HDD), these blocks are very important. (Note, the graphic above is not representative of how the blocks are actually laid out on the disk, it’s just to show the fact that sectors have blocks in them).

[NB: My good friend Howard Marks of Deep Storage Networks sent me a specific correction: “On disk drives 1 block==1 sector. Blocks aren’t a sub object. SCSI always talked about blocks because it wasn’t disc specific and the really early SCSI to ST-506 controllers allowed 512 byte blocks on 1K sectors but the only case today is 512e where a native block/sector is 4K but the drive emulates 512 byte blocks” Fortunately, this doesn’t affect our understanding for answering the question.].

To answer the question, it’s very important to note that these blocks are key. Everything a file system does is composed of operations done on blocks.

This is where file systems come in. At a basic level, a file system maintains the list of file names on the disk and their corresponding storage media, so when an application needs to read or write data to a HD the File System knows where to go, like this:

Here’s the thing, though. The File System does not directly manage the Hard Drive physical media. That’s done by a disk controller:

The disk controller, then, is in charge of where the data gets placed on the actual physical media.

But we’re not quite ready to answer your question yet. See, in between the file system and the disk controller is something called a volume manager. The volume manager takes raw disk devices and puts them together to create virtual disk devices that get used by the system.

So, the File System actually translates the locations of the data from the volume manager to the applications (including the operating system), the volume manager translates the locations from the disk controller to the File System, and the Disk Controller translates the data locations from the volume manager to the actual physical media. There are actually more layers of abstraction in this cake, though, but for now we’ll just stick to these for the sake of simplicity.

So, here’s where we get to the crux of your question:

“Are only certain harddisk or SSD sectors used and accessed when io operations implemented on only one partion?”

I’m bolding these last two words here because they are key.

When you create a partition on your home computer or laptop, you are not actually changing the placement of the data on the physical media. Instead, depending on the software you are using to do this, you could be creating a partition at the File System layer or the Volume Manager layer. The actual data itself is still managed on the physical device by the disk controller.

For spinning disks, we know from physics that the areas closer to the center of the drive move slower than the outside of the drive. So, when the data moves by the read/write head on the outside, it’s going to be much faster performance than when the same number of blocks/sectors pass by on the inner tracks:

Don’t worry about the size of these blocks right now. Just know that it takes a lot shorter time to read the same amount of information at the outside of the disk than the inside.

Highly advanced software can tell the disk controller to only write to those blocks and ignore the ones on the inside. That means that while we are technically “partitioning” the drive to do this, that’s not actually what the term means. Instead, this type of configuration is called short stroking.

There are a couple of reasons why people might want to do this, and a lot of reasons why people might not. Generally speaking, you lose a lot of capacity when you do this – the rest of the drive is not being used, because you are specifically looking to prevent the movement of the read/write head.

So, you wouldn’t create a “slow partition” on a short-stroked drive, for instance. Your cost necessarily goes up too, because in order to get the same capacity you’d have to buy multiple drives (which leads to additional considerations that are beyond the scope of this description).

However, you will get better average performance for the drive now, since you’re only using the fast tracks. So, there’s

Now, let’s look at Flash.

Flash technology (of which SSDs are made; SSD is a form factor, Flash is the memory type, and they aren’t the same thing) also breaks up the physical media into regions that can be managed.

If you’re really interested in how these things relate, you may want to check out my article on how Flash Memory avoids data loss – it goes into a lot more detail about the process of writing to a Flash device. If you don’t have the time, though, I’ll briefly cover some of the important bits (get it? ah, never mind) here.

Quickly, the three things to keep in mind are that there are still blocks, but unlike hard drives blocks are made up of additional things. So, to keep things simple, there are three components that are worth knowing about for what you’re looking to do:

1. Cells: the smallest unit on a Flash NAND die that can be programmed – that is, read or written to. You’ve probably heard of SLC, MLC, TLC, or even QLC Flash – these refer to the number of bits a cell can hold.
2. Pages: made up of cells. A page of cells is the smallest unit that can be written to. That is, when you send a write I/O, it takes up an entire page (or series of pages). You cannot write directly to cells; you must write to pages.
3. Blocks: Groups of pages. Blocks are the smallest unit that can be erasedon Flash SSDs, and most blocks are made up with 128 or 256 pages.

Obviously, Flash devices don’t have any spinning disk, so there are no ways to “short stroke”. Because there are no moving parts, then writing to one page on a flash die is exactly the same as writing to another page, in terms of performance.

To add to the confusion, there are internal workings of a flash device that mean that data is constantly being moved. It goes beyond what we’re looking to describe here, but it’s important to note that the way to keep a Flash drive healthy is to avoid keeping the data in the same place for very long.

For a Flash drive, the equivalent of a drive controller is called a Flash Translation Layer (FTL). Like a HDD device controller, it is responsible for knowing where everything is. It’s impossible to overstate how important the role of the FTL is. If the information in the FTL is lost – your drive is hosed.

Why is this not the case for a HDD? Because of the way that the data is written – HDDs “like” long sequential reads and writes. It’s easy to parse information when it’s written sequentially. Flash, however, “likes” random I/O. Plus, the FTL is constantly moving data around all day long, when a HDD simply keeps the data in place until it needs to “de-fragment”. This is, btw, why you don’t “defrag” a SSD.

Anyway, back to the question at hand. When you create a partition for SSDs, you never do it at the FTL (there are exceptions within NVMe, but that is a far more advanced topic). Instead, you will always do it inside of the volume manager or, in some cases, inside of the operating system at a higher level.

I know this answer was long, but hopefully it gave you enough of a background to understand how data written to HDDs and SSDs works.

If you wish to find out more information about how storage works, you can check out my storage bibliography, which includes articles, webinars, and podcasts about storage technology.