One bit to rule them all? Forget it – old storage types never die

Pups' guide to running with the storage pack

Block storage, file storage and object storage are all frequently bandied about terms in the storage world. They are fundamentally different, and yet inextricably intertwined. Choosing the right storage today means understanding the differences between these different storage classes, and how they can be made redundant and/or highly available.

The following is a really basic overview. The goal isn't really to keep going "turtles all the way down" until we're talking about etching ones and zeros onto magnetic media by hand with an electron microscope. The goal is give a brief overview that – with luck – practicing systems administrators who aren't quite specialised in storage can follow enough to ask Google better questions about various points of interest.

Block storage

Block storage has a fixed number of blocks of data of a fixed size. The storage in question could be a LUN, which is a designed chunk of storage that may or may not be the size of an entire drive or array, or it could be an entire drive or array, presented as raw block storage.

The old-school way to make block storage redundant is RAID. Essentially, you have two choices. You can keep a copy of each block stored on one disk and another disk (RAID 1). Alternately, you could make a parity calculation (or two) across multiple disks and store the parity value(s) in a striping pattern designed to allow for one (RAID 5) or two (RAID 6) disk failure - for the purposes of this article, the other RAID modes don't exist. Hush. I'm trying to keep this simple.

If you want to distribute block storage across multiple nodes, then you need to – at a minimum – mirror your blocks across nodes. When block A is written to hard drive 0 on node 0 then you also write block A to one of the hard drives on the other nodes.

Typically (more on this later) when you are dealing with things at the block level you're only mirroring, and thus block devices are mirrored block for block. To mirror a block device from one node to another, there must be enough space (usually enough space all on one block device) on the destination node to absorb the mirror.

Deduplication and replication and other technologies can change the maths on this, but let's try to keep it simple for now.

Block storage doesn't understand files. It only understands reading and writing blocks of data of the exact size it's configured, not what that data represents, nor that data might be smaller than a given block or so large it takes up millions of blocks. Block storage stores blocks.

This makes it spectacularly easy to replicate. If a block is changed on node 0 then you send that change to the partner node. Individual blocks are small and you don't ultimately care about the contents. You're replicating underlying storage. Let the something else worry about what the blocks contain.

File storage

Blocks aren't particularly useful to humans, or the applications that we use. We don't tend to remember that our thesis begins at byte 13 on block 476 and continues on to byte 42 on block 482, then is bytes 5 thru 64 on block 1076 and all of blocks 41768 thru 41892. While I suppose we could write the most important blocks down on a piece of paper, that would get old really quickly.

So we came up with file systems. We abstract away which bytes in which order make up the data we care about by giving it all a (hopefully easy to remember) name. That name is really just an index entry that points to both which data chunks make up your file and the order they should be assembled in.

File storage is important to operating systems because they consist of millions of files. Indeed, operating systems manage their own file systems: they take raw block storage and make a hierarchical file system available for consumption by the operating system itself, by applications and sometimes by other computers on a network.

Similar topics

Other stories you might like

Biting the hand that feeds IT © 1998–2021