readv: parallel or sequential?

[Peter Schuller]

> In case the application uses serialized access there is not much to do
> beside preread or caching writes to make use of multiple spindles.

Agreed.

> But an application has to be carefull, because parallel access within
> a single file almost always mean that access is not linear anymore, so
> many opther performance tunings won't work as good as they could, so
> this could easily outweight the performance gain from multiple access.

For seek bound applications you don't really care anyway. If you have a 
mixture of stream bound and seak bound I/O going on you will run into various 
issues which are difficult to avoid without very careful application-specific 
tuning I think. But for the simple case of doing concurrent seek-bound I/O I 
would expect it to be handled gracefully by the OS.

And I do mean to the same file, rather than file descriptor (in response to 
the other post on descriptors).

> Nonlinear access from within an application has to be for another reason
> and not as a performance tuning.

Why? Again, PostgreSQL, other databases, or any file access pattern which is 
seek bound stands to gain more or less linearly from concurrent I/O being 
propagated to constituent devices in a non-serialized fashion. This is a 
pretty basic assumption in my book when designing an application. Whenever 
something is seek bound, assuming I have concurrency in my app, I look at the 
number of constituent devices on the device and the type of RAID or similar 
being used (including stripe sizes in relation to the size of my I/O 
requests, etc).

I fully expect to be able to scale linearly with the number of underlying 
devices, assuming raid0/raid10 or something equivalent, and assuming I have a 
concurrency that is sufficiently high to keep all drives busy.

(There are valid exceptions of course, such as raidz/raidz2. But that's beyond 
the scope of this discussion.)

-- 
/ Peter Schuller

PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller at infidyne.com>'
Key retrieval: Send an E-Mail to getpgpkey at scode.org
E-Mail: peter.schuller at infidyne.com Web: http://www.scode.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20071220/2ca4e24f/attachment.pgp