> * Support for "a posteriori" or Run Length Encoded file formats
> - simple case of header followed by either homogeneous
Can you clarify what the term "run length encoded" means.
> * Standard READ/WRITE stream access model
> * Standard SEEK positioning model, in units of MPI_Datatype(s)
> * Atomic SEEK_AND_READ/WRITE for high-performance
In the proposal, I couldn't find a function for the standard SEEK
positioning model.
> 2. Proposed API
> ---------------
> MPI_FREAD(fh, buff, buftype, bufcount, offset, status)
> MPI_FWRITE(...)
> MPI_IFREAD(..., request)
> MPI_IFWRITE(..., request)
> IN fh File handle
> IN buff buffer (OUT on write)
> IN bufcount number of buftypes to read/write
> IN offset offset in filetypes
> OUT status success/warning/failure
> OUT request request handle (for asynchronous versions)
>
Are these reads/writes independent or collective?
Even though a group of processes may have opened the file
collectively, and the communicator is cached in the file handle, they
may at times want to perform I/O independently.
>
> * An Atomic SEEK_AND_READ/WRITE for high-performance could be
> constructed as a union of the MPI_FLAYOUT and MPI_FREAD specs.
>
> MPI_FSEEKREAD(fh, etype, filetype, count,
> buff, buftype, bufcount, offset, comm, status)
> MPI_FSEEKWRITE(...)
> MPI_IFSEEKREAD(..., request)
> MPI_IFSEEKWRITE(..., request)
>
I don't quite understand the benefit of combining LAYOUT with READ and
calling it a SEEKREAD. Presumably, many users would like to define the
layout once and perform I/O many times. SEEKREAD will be of use in
only the first read in such cases.
The traditional seek model with individual file pointers,
i.e. seek first and then read without an offset, is also important.
Users are comfortable with it, as all file systems support it.
(MPI_Read_next in the original MPI-IO proposal).
Rajeev