search

mpi-forum / mpi-forum-historic

Migration of old MPI Forum Trac Tickets to GitHub. New issues belong on mpi-forum/mpi-issues.
http://www.mpi-forum.org
2 stars 3 forks source link

MPI3 Fault Tolerance - Files #326

Open mpiforumbot opened 8 years ago

mpiforumbot commented 8 years ago

Originally by jjhursey on 2012-03-06 20:29:48 -0600

326-E: MPI I/O semantic after process failuresThis ticket is a split from ticket #323 . It covers the specific semantic of returned errors in case File operations cannot be completed after a process failure, and the recovery options for the associated file handle.

Votes

no votes yet.

Description

Extended Scope

This is a split from ticket #323. It depends on ticket #323.

History

Initially was part of ticket #323. It is now separated out.

Proposed Solution

Impact on Implementations

Adds the MPI_FILE_REVOKE function and clarifies semantics after an exception of class MPI_ERR_REVOKED or MPI_ERR_PROC_FAILED has been raised.

Impact on Applications / Users

Provides fault tolerance to interested users. Users/implementations that do not care about fault tolerance are not impacted.

Alternative Solutions

Entry for the Change Log

mpiforumbot commented 8 years ago

Originally by jjhursey on 2012-03-07 00:30:01 -0600

Attachment added: mpi-report.pdf (2322.7 KiB) Changes for ticket 326, within the scope of #323

mpiforumbot commented 8 years ago

Originally by bouteill on 2012-05-23 14:31:13 -0500

This is the complete document including all ticket0 compared to previous readings. Mostly automatic renaming.

https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/323/mpi-report-17complete1.pdf

See #323 for a cleaner version with only important ticket0 changes.

mpiforumbot commented 8 years ago

Originally by @wbland on 2013-10-24 10:30:24 -0500

This ticket is no longer necessary as the entire FT proposal will be presented as #323 in the future rather than as separate tickets.

mpiforumbot commented 8 years ago

Originally by @wbland on 2015-04-09 15:27:54 -0500

It was decided to leave the I/O portion of ULFM as a separate ticket to prevent it from holding up the reading of the main ticket, though there hasn't been much contention about the new semantics being proposed here. Obviously, the intention is still to get all parts of FT into the standard at the same time, even if they aren't the same ticket (as has been done with other items in the past).