CST334 Persistence, IO Devices

 As is pretty much every topic in this course so far, this week's persistence topics were very illuminating.  We covered IO devices with a specific focus on hard drives.  Not only hard drives, but some of the topics about legacy hard drives, the platter kind that I grew up with.  On my old 386, I recall having to set up the drive specifications in the main board's BIOS for it to recognize and use the drive correctly.  I didn't entirely understand what I was inputting for settings, but this week brought it home.  We also discussed file systems, how they can be organized, and how they can be accessed.

 An important distinction was made between two different types of IO devices.  There are block devices such as hard drives, and there are character devices.  Character devices stream data byte-by-byte.  This data stream can be ephemeral; if the data fails to be captured at the other end, it is gone.  Though I presume the device could resend, depending on the nature of the data source.  Block data transfers entire blocks of data from a structured, addressable storage space.  The character devices' data are not addressable in the same way.

Both interesting and hard to intuitively grasp was the operation and timing of spinning platter drives.  I've seen the inside of these drives before, and I understood that the R/W heads moved across the platters quickly and that the spinning speed of the drive had an impact on the total access rate.  However, doing the calculations for these I found a bit tricky.  Even on the quiz, I didn't manage my units correctly and made some errors.  Using the average time to get to data on the far side of the platter was an interesting bit of information. 

How are SSD devices, flash memory like USB drives or SD cards, handled differently?  Or are they?  I suppose the interface between storage devices and the OS is abstracted enough now that the OS doesn't need to concern itself with how the device works.  Unless there is a driver that lets the OS do so, that is.  How are total access times, or read/write performances, evaluated with SSDs?  I see that read tends to be faster than write, but the gap between these two transfer speeds is less than with platter HDs, if I recall correctly.  The speed of the storage medium plus whatever controller processors are on the SSD must be responsible.  Like the video lecture stated, these other devices are really just little computers themselves, with some sort of control logic device, perhaps some storage, and whatever other hardware makes them the specific device they are.

I really want to put these concepts, not just this week, but this whole class, to use in dabbling in firmware programming.  The devices I work with day-to-day, primarily printers, have custom firmware and I’m lead to understand the development of the firmware is very tricky.  Unfortunately, it is closed firmware and unavailable for analysis and learning.