“Trail: a Track-Based Logging Disk Architecture for Zero-Overhead Writes”, 1993-10-03 ():
A novel disk architecture called Trail is proposed to optimize the disk write latency without sacrificing the disk read performance. This architecture features a track-based logging technique, which essentially reduces a disk write latency to the transfer delay. In addition, this disk architecture allows concurrent read/write, and implicit write scheduling without compromising data integrity.
Through a synthetic-trace simulation study, we have shown that for transaction processing workloads:
the write latency improvement of Trail over conventional disk devices is at least an order of magnitude. Trail’s read latency performance is also better in all cases, sometimes the improvement is also over an order of magnitude. In terms of disk bandwidth usage, the Trail architecture has a close to 100% write bandwidth efficiency and a read bandwidth efficiency at least as good as a conventional disk.
…A Trail disk operates as follows. The read-write head of the log disk is guaranteed to be on a cylinder that has at least one free track. In response to a disk write request, the disk controller simply starts the write to wherever the disk head happens to be. Because there is always a free track under the disk head, the write can be performed immediately. As a result, there is no seek and rotational latency involved in the write process! The only latency is due to data transfer As soon as data is completely transferred to the log disk. the device can return a completion signal to the software. At this point, there is still a copy of the data kept in the disk controller’s DRAM-based buffer. From the software standpoint, a Trail disk completes a disk write without any additional delay. Ultimately the data will be put back to the main disk, at a time determined by the intelligent controller. Only when the data copy is safely moved to the main disk can its occupied buffer space be reused. When a read request arrives, the controller first looks up the buffer and returns the requested data if it is there. Otherwise an access to the main disk is scheduled to satisfy the request. Note that the log disk never services disk reads. So it is not a cache. It serves as a safety net to fall back on when the contents of the controller buffer are corrupted.
…Compared to LFS, Trail achieves a better disk write performance because of the reduction in the rotational latency. Moreover, the file system is not required to perform clustered writes in one batch. Consequently the performance of synchronous writes is only limited by the disk’s raw transfer bandwidth. Because the main disk assumes a data organization that is determined by the file system, disk read performance is not penalized. Last but not least, there is no need for garbage collection because the hardware assumes the responsibility of managing the log disk. This simplifies the implementation and improves the performance of the storage management software.
[HN: optimization by inferring disk geometry like sector location to predict heads: “One of my co-workers did some work back ~2003 based on the finding reported in this paper…Those findings dovetail with those mentioned here in that he used the true/discovered disk geometry map to allow him to stream data onto the disk very fast by writing to the specific sectors that were known to be arriving under the heads right now, which caused the data to appear out-of-order when accessed later via sequential LBA block numbers but could be reordered using that same map.”]