I/O Flashcards
file system components
interface
implementation
mass-storage structure: lowest level of the fs, the secondary and tertriary storage structures
block devices
hard disks, SSDs
store information in fixed-sized blocks
transfers are in units of entire blocks
I/O occurs with random access (by block ID)
character devices
printers, network interfaces
no blocks, only stream of characters/bytes
not addressable, doesn’t have any seek operation
I/O occurs with sequential access
device controller
- Located between actual device and computer
- Offers electronic interface in form of I/O registers
- R/W those registers to ask the controller to perform actions
- e.g. parallel port, usb
port-mapped I/O
two address spaces: main memory + ports
I/O Registers are accessed via dedicated port numbers and special instructions
memory-mapped I/O
one address space
I/O Registers are mapped into addresses of main memory and accessed like memory
hybrid I/O
two address spaces
Both implementation can coexist on a given architecture
I/O requests
Most devices offer status bits in their registers to signal that a request has been finished (and the error code)
OS can poll this status bit (polling)
polling / busy waiting
after outputting a character, the CPU continuously polls the device to see if it is ready to accept another one
interrupts
Device controller can trigger interrupts to signal that an I/O request is complete
=> For the device, this means simply changing the voltage on an electrical interrupt line
- Each controller has interrupt vector assigned
- CPU runs vector-specific handler when int occurs
trap
deliberate action from a program, software interrupt
fault (exception)
usually not deliberate, typically caused by programs
hardware interrupt
device such as printer or network sends a signal to the CPU
precise <-> imprecise interrupts
precise: state is consistent- everything before the interrupt is executed and after isn’t
imprecise: doesn’t have the same guarantee
Data Exchange Between Device and CPU
- Program disk controller reads a sector
- Wait for interrupt
- Read sizeof(sector) bytes from I/O registers
- Repeat for next sector
DMA
hardware does the data transfer
DMA steps
- CPU programs the DMA controller
- DMA requests transfer to memory from disk controller
- data transferred to/from main memory
- ack sent to DMA controller
- interrupt sent to the CPU when done
DMA controller
- On ISA systems there was a dedicated DMA controller (third-party DMA)
- On PCI (and PCIe) systems each PCI device may become “Bus Master” and perform DMA (first-party DMA)
- Device and DMA controller are combined
- problem: You have to trust your Hw
- Embedded systems still have a dedicated DMA controller
- Disk controller still uses own buffers
issues in I/O software
- Device independence
- Uniform naming
- Error handling
- Buffering
- Synchronous vs asynchronous
device independence
- I/O software provides abstraction over actual hardware
- Programs should not have to care about device particularities
uniform naming
- We don’t want to type ST6NM04 to address the first hard disk
- /dev/sda is better
- /mnt/movies even better
error handling
errors should be handled closest to their source
buffers
networking: incoming packets have to be buffered
audio: buffering to avoid clicks
synchronous vs asynchronous
- Programs don’t want to deal with interrupts → OS turns async operations into blocking operations
- Lower levels have to deal with interrupts, DMA, etc.
I/O software layers + their functions
- user processes: make i/o call, format i/o, spooling
- device-independent software: naming, protection, blocking, buffering, allocation
- device drivers: set up device registers, check status
- interrupt handlers: wake up driver when i/o completed
- hardware: perform i/o operation
i/o storage devices
SSD
HDD
SSD vs HDD
DRAM
or NOR/NAND flash memory
no mechanical parts (only controller + memory)
can be used as part of SSHDs