Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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.

share|improve this question

closed as not a real question by Linker3000, Sathya Sep 8 '11 at 4:33

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

    
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 '11 at 9:20
    
@saw I do mean Disk I/Os only. Sorry if the question text makes it confusing –  AnkurVj Sep 7 '11 at 20:13

1 Answer 1

up vote 2 down vote accepted

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.

share|improve this answer
    
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 Sep 7 '11 at 11:26
    
On a flash memory drive, write operation takes longer time than read. –  jeffgao Sep 7 '11 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 '11 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 '11 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 '11 at 6:53

Not the answer you're looking for? Browse other questions tagged or ask your own question.