use ADIOI_Type_create_hindexed_x in place of MPI_Type_indexed in case… #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
A demonstration of stackable ROMIO drivers implementing log-based i/o.
- no longer need to special-case contiguous types - don't flush a file if it's not open - too aggressive check for reading - promote type sizes to match ROMIO: the 32-to-64 bit promotions from a few years back need to propagate to the (much older) logfs code. - logfs does not support atomicity - long ago we broke out open into two parts - 'name' already implemented elsewhere: a while back we added a "romio_filesystem_type" hint for cases where someone wants a human-readable string for what file system romio found. Remove this feature from logfs (since it's already there) let's try the create-and-reopen open now that permissions are in place, the create on one, open on all might work better
when replaying log, logfs was using hard-coded 1mb buffer. good for aggregating tiny writes. Less helpful if operations are large.
it did a poor job managing types with lb and ub markers, and I am suspicous of its prior handling of partial types
logfs will already proces the type and put the first byte in the right place. I wonder if we even need this for common code, now that we use pwrite/pread? It's been in the view code forever.
a simple blocking version of non-blocking read. We can come back and re-think what non-blocking i/o means in a log-based file system.
some mixup here between etypes and bytes when computing offset
logfs was ignoring flags like EXCL and such. use user-provided flags when creating the file, and report an error if we are unable.
not just the logfs metadata
maybe the right way to implement shared file pointers is to drop down to the target file system somehow. maintaining the hidden shared file pointer file as a logfs log is a silly idea anyway.
sometimes we do need read a write-only file (as when replaying a log)
always open an independent version of the file
Useful for debugging and for demonstrating how the logfs data structures are stored.
the logfs write will take into account the type, but it won't know anything about the displacement unless we update it here
… sortindices is larger than INT_MAX
…ad_lustre_rwcontig.c
…tree walk to generate file view with decreasing offset that caused ad_lustre to crash
roblatham00
force-pushed
the
logfs-in-romio
branch
from
415004a to
a956cca
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When writing large files, it is possible that the indexes in the file view exceed the size of int, resulting in overflow.
By replacing MPI_Type_indexed with ADIOI_Type_create_hindexed_x that uses MPI_Aint and MPI_Count, we can support larger files.