2

Is writing to a disc more costly operation then reading from a disk. For example - writing a 1 GB file of records as compared to reading the whole file.

2
  • Title doesn't quite match question. Title refers to nonspecific I/O, whereas question text specifies to disk I/O and file operations.
    – sawdust
    Sep 7, 2011 at 9:20
  • @saw I do mean Disk I/Os only. Sorry if the question text makes it confusing
    – AnkurVj
    Sep 7, 2011 at 20:13

1 Answer 1

3

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.

9
  • 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)? Sep 7, 2011 at 11:26
  • On a flash memory drive, write operation takes longer time than read.
    – jeffgao
    Sep 7, 2011 at 19:19
  • 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
    Sep 7, 2011 at 20:17
  • @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
    Sep 7, 2011 at 23:36
  • 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
    Sep 8, 2011 at 6:53

Not the answer you're looking for? Browse other questions tagged .