Logically, a single write can be seen as both, random and sequential, because it always affects a specific number of consecutive bytes. In case of synchronous and direct I/O, where writes are not delayed based on caching, the actual execution order and timing of writes are critical.

At any point-in-time, the block device has an queue containing zero or more writes. The size and location of those writes determine if they can be considered random or sequential. If the queue to be processed contains small writes that affect different non-consecutive blocks, they represent random writes and will “become” random writes because a limited number of consecutive block writes take place as a result. If, on the other hand, one of those supposedly random writes is larger and therefore covers a large number of consecutive blocks, that one write represents a sequential write because a significant number of consecutive block writes will be triggered as a result.

The situation is a little more nuanced because those I/O requests are executed in a specific order. If the disk queue contains writes for the blocks 1, 2, 3, 4, 10, 11, 12, 13, two larger writes will be triggered that can be considered sequential. If, however, the write order issued by the application was different (e.g. due to multi-threading), a disk queue of 1, 10, 2, 11, 3, 12, 4, 13 would basically trigger 10 writes that can be considered random even though the the application might have issued two sequential writes from a logical POV.

The situation changes / improves dramatically with two additional aspects:

• Deferring writes using the OS page cache / storage controller cache
• Reordering writes using I/O scheduling

In case of asynchronous I/O (the usual default), writes only affect the OS page cache during the call and will either be executed in the background or whenever a sync operation (e.g. fsync) is triggered. The same is true for the storage controller cache that can defer writes using a similar strategy.

Using write deferral, individual writes can be aggregated into large writes if they affect consecutive blocks and might become sequential writes even though they would otherwise have been random writes. Even if those writes represent random writes of a database that updated individual database pages in the course of different SQL statements, they can become sequential writes if they can be aggregated because the timing happened to be right.

As outlined before, the write order affects this scenario. In case of write deferral, the OS and/or the controller is free to reorder writes based on whichever criteria is in place. The reordering process could favor specific blocks, small writes, old writes, writes with better sequential locality. As in the example above, the order can turn writes that would otherwise have been considered sequential into random writes if the scheduling policy prioritizes those.

In a SAN environment, a write is

1. triggered by an application
2. cached/aggregated/reordered by the OS
3. forwarded by the HBA
4. cached/aggregated/reordered by the storage array controller
5. aggregated/reordered and executed by the disk.

So, while the disk has the final say in terms of I/O scheduling (the disk queue can be reordered) and thus, that’s where the final decision will be made on whether or not the write will be sequential or random, the storage array controller represents the last major stage of caching/aggregation/reordering.

The sequential locality and size of the I/O request issued by the OS / storage array controller after potentially aggregating multiple individual writes based on the page cache / storage controller cache turns writes into either random or sequential writes.