More about Disks

SSD v HDD

Flash technology is getting cheaper and cheaper, so a viable alternative to a Hard Disk Drive (HDD) is a Solid State Drive (SSD). SSDs are generally much more expensive than HDDs. But, SSDs are also less susceptible to shock problems (because there are no moving parts), and have faster access times and lower latency.

• SSDs usually use a type of NAND gate that retains its state without power. (For more on NAND gates, take CSCI 211). These chips are slower than the chips used for RAM.
• SSDs use the same hardware interface as HDDs.
• Unlike HDDs, SSDs do not suffer from disk framentation.
• SSDs use less power (no motors to spin).
• SSDs have a limited number of reads and writes, but generally higher Mean Time Between Failure rates.
• The main disadvantage of SSD is cost. HDDs are currently running about $0.05 to $0.10 per GB, while SSDs are $1 to $2 per GB.

The following table overviews the manufacturer's specs for two desktop drives from Western Digital.

	SSC-D0256SC-2100 256GB SSD	WD2500AAKX 250GB HDD
Price	$499.00	$44.99
Size	3.9 x 2.75 x 0.4 inches	5.7 x 4.0 x 1.0 inches
Sustained Read	up to 250MB/sec	126MB/sec
Sustained Write	up to 170MB/sec
Cache	---	16MB

Disk Fragmentation

Using the manufacturer's specs for an average hard disk, let's see how fragmentation impacts speed.

As a reminder from our last class,
       Time per disk operation = Seek Time + Latency + Transfer Time
Since Seek Time and Latency are nondeterminstic, we must use averages for their values. Transfer Time is directly dependant on data size and write speed.

Assuming we want to write a small JPEG image that is 1156x723 and 672KB, how long should it take to write the file?

The following table summarizes the manufacturer's specs for an average hard disk.

Manufacturer	Seagate
Model Number	ST3500630AS
Price	$117
Capacity	500 GB
Discs	3
Sectors per Track	63
Bytes per Sector	512
Speed	7200 RPM
Read/Write Heads	16
Cache Buffer	16 MB
Avg Latency	4.16 ms
Track-to-Track Seek Time	<0.8 ms for read; <1.0 ms per write
Average Seek, Read	< 8.5 ms
Average Seek, Write	< 10.0 ms
see page 12 of spec sheet

Approx Write Time assuming Contiguous Sectors

Let's make a big assumption and assume that our picture will be written to contiguous sectors on contiguous tracks.
672KB will take 1344 sectors.      (672KB / .5KB/sector = 1344 sectors)
1344 sectors will take 21.33 tracks.      (1344 sectors / 63 sect/track = 1344 tracks)

The seek time to the first track is the "Average Seek, Write", which is 10ms. Then, moving to each adjacent track will take 1ms per track, and there are 21 tracks after the first track. So, the total seek time is 31ms.

For each of the 22 tracks used by the image file, the latency time will average 4.16ms. So, latency will take, 22 * 4.16, or 91.5ms.

Remembering our logic from the last class, the time to write one track is the same as the time to make one revolution. A 7200RPM disk will take 8.33ms to make one revolution. So, our image file on 21.33 tracks will take 21.33 * 8.33, or 177.7ms, in transfer time.

So, total time to write our 672KB file, is
     31ms + 91.5ms + 177.7ms = 300.2ms

Once again, we are neglecting system bus delays, not counting sector headers, ignoring impact of cache, assuming maximum write efficiency, yadda yadda. But, for sake of our comparison, a contiguous 672KB file should take roughly about one third a second to write.

Approx Write Time assuming minor Fragmentation

What will be the impact of file fragmentation? How much will each of the three time components increase?   Seek Time?   Latency?   Transfer Time?

Our file will still use 1344 sectors. Fragmentation causes the sectors to be spread out. Let's assume that instead of 22 tracks, our file uses 44 tracks.

Seek Time for writing averages 10ms. Since we will not assume all 44 tracks are next to each other, we should use that average for each of the 44 tracks. So, seek time is now 10ms * 44 tracks = 440ms.

If we use contiguous sectors on each track, then latency becomes 44 tracks * 4.16ms/track = 183ms. Also, note that if we used 2 blocks of sectors on each of the 44 tracks then latency would be 44 tracks * 2 blocks/track * 4.16ms/block = 366ms.

Total Write time will not change. Writing 672KB should take about 178ms. Spreading out the file contents only causes longer head movement wait times, not longer times actually writing data.

So, total time to write our 672KB file spread across 44 tracks instead of 22, is
     440ms + 183ms + 178ms = 801ms
And, spreading the blocks across those tracks would slow write time to
     440ms + 366ms + 178ms = 984ms
In other words, about 1 second.

You knew the moral of this story before it began: "fragmentation slows disk operations". Now you have an idea of by how much.

Exercise:

How long would it take to write a 2,097,152 byte (2MB) file with no fragmentation?

How about with fragmentation similar to that above - twice as many tracks, non-contiguous tracks, and using contiguous sectors per track?