Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On 02/28/2013 12:22 PM, Arnold Krille wrote: >> It's interesting because, normally, writes do not directly translate >> > to head seeks (thanks to dirty pages, caches, NCQ, firmware-level >> > optimization...), and ideally barriers should be disabled (and caches >> > reliable). > If you want secure storage on disk, every write translates to > disk-head-action, if you have random writes, every write results in > a head-seek. Otherwise the data wouldn't be on disk. Actually every > write has to result in two seeks: seek the position to write, seek the > position to write the fs' metadata. With drbd and internal-metadata you > add another seek to the end of the disk... To chime in on this - I do see that write caching and disk I/O scheduling can potentially reduce the impact of seek operations. Nevertheless, I'm with Arnold on this one: It's wrong to build a system and estimate its I/O capacity based on best case (or even average case) caching scenarios. If caches would protect you from all disk performance limitations, there would be little use for fast HDDs. In real life, this performance matters, and from my experience, you *will* see latency induced by DRBD metadata operations, even when using hardware RAIDs with write cache. Optimizing metadata access and disk seeking is valid and worthwile. Do not blindly assume that your hardware excempts you from it. Cheers, Felix