Cost of disc I/O read versus write

At the drive level, a read sector operation would take about the same (or a bit longer) time as a write sector operation. For a read sector, the command has to arrive over the drive interface (e.g. SATA), the command decoded, seek issued, scan Address Marks and record IDs until sector is found, read sector data into a buffer, validate the sector using ECC (error correction code), and then finally send out the sector data. (Note that there is a widespread misconception that sector data can be transferred directly from the read head to the interface. Absolutely false: the sector data is always fully buffered, and is always transmitted at full interface speed only after the entire sector has been read and validated.) If read-ahead is performed and cached, then a subsequent sequential read will not have the seek and rotational delays. For a write sector, the command and sector data has to arrive over the drive interface, the command decoded, seek issued, scan Address Marks and record IDs until sector is found, write out sector with ECC, and the host is notified of completion.

At the OS or filesystem level, writes are more complex when a new file is being created. Reading a or rewriting an existing disk file only requires lookup of where the data sectors (or clusters) are located. Writing a new file or appending to a file will require first allocating sectors/clusters from the free list, assigning those sectors/clusters to the file (directory entry update?), and then writing the data out. Note that the disk allocation table(s) will typically be updated (i.e. written to disk) as soon as possible, maybe even before the file data, in order to maintain filesystem integrity. If you've ever noticed/heard a lot of disk seeks while creating a file, you can assume the heads were moving between the allocation table and the new file.

sawdust

Posted 2011-09-07T07:56:29.587

Reputation: 14 697

If you've ever noticed/heard a lot of disk seeks while creating a file, you can assume the heads were moving between the allocation table and the new file. I assume this will only occur if the filesystem is heavily fragmented (otherwise it would only have to update the allocation table once or twice)? – Breakthrough – 2011-09-07T11:26:16.237

On a flash memory drive, write operation takes longer time than read. – jeffgao – 2011-09-07T19:19:57.840

saw, the answer is by all means comprehensive and complete, however I have one more doubt : Is there anyway to force a highly fragmented file ? I wanted to benchmark the performance of disk reads when the file is highly fragmented versus when the file is contiguous. Can each fragment be smaller than a block size ? – AnkurVj – 2011-09-07T20:17:15.170

@Breakthrough - Not necessarily. Windows Media Center seems to create fragmented (rather than nice contiguous) files for recorded TV regardless of the partition's condition. – sawdust – 2011-09-07T23:36:12.807

@AnkurVj - There are degrees of fragmentation: just a sector or two apart, or a track away (just a head selection & no seek), or a cylinder or more away. When the read request for the next (logical) sector is processed, perhaps the data is already in the drive cache due to read-ahead; so in that situation the performance is as good as a contiguous file. To create a fragmented file, try writing a program that alternates writes of an allocation unit worth of bytes to the target file with very large writes to a filler file. Invoke sync() to flush the data out to disk after each write. – sawdust – 2011-09-08T00:02:48.597

@AnkurVj - File fragments have sizes that are a multiple of the allocation unit (except for the tail of the file). A block size is rather arbitrary, and often chosen by a program to optimize I/O and record deblocking for space and/or time. Not sure what you're really asking. – sawdust – 2011-09-08T00:08:55.450

Another way to to create highly fragmented files is to download MyDefrag. There is a test mode that writes fragmented files. – surfasb – 2011-09-08T01:52:14.423

@sawdust I used to think that the disk I/O happens in units of blocks. That is, multiple blocks at a time. I will try your fragmentation suggestion. Thanks a lot – AnkurVj – 2011-09-08T04:22:24.400

2@AnkurVj - Blocks (and/or records) are usually the transfer size between user buffers and system buffers, and can be of arbitrary size with a performance penalty . The actual disk I/O between host (system buffers) and disk drive has to be in terms of a disk sector (traditionally 512 bytes, but evolving to 4KB to match the typical erase page size of SSD). If you choose your block size to be a multiple of the sector size, then the OS might allow unbuffered disk I/O to be employed for a big performance gain by eliminating the intermediate system buffer. – sawdust – 2011-09-08T06:53:51.887

Cost of disc I/O read versus write

Answers