seek time

Imagine a librarian who must fetch a book, but the shelves are arranged in long rows and she can only walk straight down one aisle. Before she can even start reading a title, she has to physically walk to the right aisle. If the next book is in the aisle she is standing in, that walk is instant; if it is at the far end of the building, the walk is long. Seek time on a hard disk is exactly that walk: the time for the head's arm to move from where it is to the track that holds the data you want.

Concretely, the read/write head sits on a moving arm, and the data lives on concentric tracks at different radii. To read a sector on a track the arm is not currently over, the drive must accelerate the arm, glide it across, and settle it precisely on the target track. That whole motion is the seek. It depends on how far the arm has to travel: a short hop to a neighbouring track might take well under a millisecond, while a full sweep across the platter takes several milliseconds. Drive makers quote an 'average seek time' (often 8 to 12 ms for a desktop disk), meaning the typical seek over a random distance.

Why it matters: seek time is usually the single biggest cost in a random disk access and the main thing disk scheduling tries to reduce. By reordering pending requests so the head sweeps smoothly across the disk instead of jumping back and forth, the OS cuts total seek time dramatically. Seek time is also why sequential access (reading the next track over) crushes random access (jumping all over the disk) in speed. Crucially, an SSD has no arm and no tracks, so it has no seek time at all — which is why disk scheduling barely matters on flash.