[Interest] [Semi OT] Concurrent (multi-threaded) read/write disk IO?

[Rainer Wiesenfarth]

From: Till Oliver Knoll
> Am 05.02.2015 um 14:25 schrieb Till Oliver Knoll:
> > ...
> > 
> > Does it make sense to guarantee/enforce "sequential (exclusive)
> > access to the harddisk" on application level, or would I
> > re-invent functionality already present in the underlying
> > OS/disk driver (and maybe even sacrifice performance)?
> 
> I eventually found a link which seems to confirm that
> it would be best to only have sequential read/write access
> with physically spinning drives, that is, have some kind of
> "IO Manager" in the application:
> 
> http://www.tomshardware.co.uk/forum/251768-32-impact-concurrent-speed
> [...]

Please note that this post is more than five years old. Things - namely I/O schedulers in operating systems and hard disk caching - have changed since then.

I would _assume_ that any modern OS is capable of scheduling I/O for maximum performance. In addition, an own I/O scheduler would probably only work for bare metal access to the harddisk. Otherwise, the underlying file system and its potential fragmentation might void all your effort.

Thus my approach would be to start any number of concurrent reads and writes that makes sense for the application side and start optimizing if (and only if!) throughput is too bad.

Best Regards / Mit freundlichen Grüßen
Rainer Wiesenfarth

-- 
Software Engineer | Trimble Geospatial
Rotebühlstraße 81 | 70178 Stuttgart | Germany
Office +49 711 22881 0 | Fax +49 711 22881 11
http://www.trimble.com/geospatial/ | http://www.inpho.de/

Trimble Germany GmbH, Am Prime Parc 11, 65479 Raunheim
Eingetragen beim Amtsgericht Darmstadt unter HRB 83893,
Geschäftsführer: Dr. Frank Heimberg, Hans-Jürgen Gebauer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6250 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20150205/45ef8904/attachment.bin>