6 ms·
The quick 'n dirty recipe to test the disk write speed isn't ideal, since there's the buffer cache which significantly skews the results. A much better way woul
by onosendai 13y ago
The quick 'n dirty recipe to test the disk write speed isn't ideal, since there's the buffer cache which significantly skews the results. A much better way would be:
> sync && time sh -c "dd if=/dev/zero of=foo bs=1M count=10000 && sync"
Then just divide 10000 (or whatever value you choose) by the number of seconds elapsed and you should get a much closer approximation of the sequential write speed, taking into account completely flushing the buffer to disk.
- emilw 13y agoEven better would be to not use dd, it isn't intended for testing/benchmarking write speeds, and use http://www.iozone.org/ http://www.iozone.org/
- ehsanu1 13y agoOr fio. https://www.linux.com/learn/tutorials/442451-inspecting-disk-io-performance-with-fio/ https://www.linux.com/learn/tutorials/442451-inspecting-disk...
- onosendai 13y agoThis is a collection of quick shell recipes, so in that context it's perfectly acceptable. Besides, there are some environments where you can't just install packages willy-nilly, even if they're present on the repositories.
- vram22 13y agoI had read some time ago that sync doesn't actually flush the buffer cache, it just schedules it to be written (and that may happen a little later). Could be wrong though, or the information could be outdated in recent Linux versions (I read that about some UNIX version, IIRC).
- vram22 13y agoEdit: by "a little later", I meant: not necessarily synchronously. So the sync command may return before the buffer cache is actually flushed.