[saga-rg] proposal for extended file IO

[John Shalf]

On Jun 14, 2005, at 10:45 AM, Andre Merzky wrote:
> readv is more posix like, and more generic.  It always works
> if you are on read level (e.g. HDF5 VFD layer ;-).
>
> eread is more powerful: it allows applicatoin specific
> optimization which is not achievable with readv (the size of
> the iovecs in the read request is double of the size of the
> data returned!).

OK,
I think we have both arrived at the same overall conclusion.  I think 
eRead would be useful as a way to package an underlying complex service 
for implementing remote data requests. One must be able to extend the 
services on both the client and the server side to provide new e-modes 
to the user that implement these services.  The vector read ops (not 
necessarily readv/pread, but perhaps something similar that describes 
patterned reads in a compact form, would be useful for other 
application use cases where we are are not permitted (or have no 
desire) touch or extend the remote service.  I think readv/pread is a 
bit *too* restrictive, but we should have some similarly compact set of 
read ops that allow for gather/scatter type remote operations that do 
not require the service be installed on both ends (eg. just client 
side) in addition to an eRead() interface for access to two-sided 
services.

So I guess we have a need to do both.

For a suitable vread alternative, it would be useful to have something 
like
	read_pattern(descriptor,buffer,int nlogicaldims,int 
logicaldims[],offset[],block[],stride[]);
to specify a patterned operation.  The list of iovecs[] can be used for 
gather operations that cannot be encoded as a regular pattern.

-john