Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Implement SEMI_DIRECT access method #31

Closed
brettkettering opened this issue Dec 11, 2015 · 4 comments
Closed

Implement SEMI_DIRECT access method #31

brettkettering opened this issue Dec 11, 2015 · 4 comments
Labels
wontfix

Comments

@brettkettering
Copy link
Contributor

This method is where the data is stored in a separate file system that allows update-in-place. Typically, the repository would be a parallel file system or other fully POSIX-compliant file system that allows for efficient editing of files and not just complete overwrites.
@brettkettering brettkettering changed the title Implement SEMI_DIRECT access methos Implement SEMI_DIRECT access method Dec 11, 2015
@brettkettering
Copy link
Contributor Author

Same code path as DIRECT, but the data operations go to a remove PFS via IOFSL or other forwarding library. This is for Globus, HPSS, etc.

@brettkettering
Copy link
Contributor Author

Pretty easy as it follows DIRECT mode, the only complication is someone needs to get IOFSL and play with it in parallel as the FUSE daemon and also as a lib. I don’t know if we have someone that we can assign to this at some point when it makes sense to play with IOFSL. Since its can run as user space, one could even have someone try this on a production machine I guess, not sure about that.

@brettkettering
Copy link
Contributor Author

If we're going to make it so that the FUSE mount uses the MarFS permission of read/write metadata, but not write data (e.g. only read data), then we don't need this so much. This allows the users to manage their tree and even copy the file off MarFS to a non-MarFS file system. They just can't do copies to or edit a MarFS file.

For now we won't implement this and not implement SEMI_DIRECT at this time.

jti-lanl added a commit that referenced this issue Jul 27, 2016
@jti-lanl
Tweak MarFS_FileHandle to handle pftool issue #31
188395f 
This is the simple "near-term" solution, expanding both MDAL and non-MDAL
members of the file-handle (and dir-handle), so that it has a constant size
regardless of how pftool includes it.  This at least addresses the known
problem when building pftool with an MDAL-enabled libmarfs.
jti-lanl added a commit that referenced this issue Jul 29, 2016
@jti-lanl
Makefile now builds differently-named libraries for MDAL/non-MDAL.
9a8c640 
libmarfs_mdal/libmarfs_nomdal.  We always provide a libmarfs symlink, for
apps that don't care.  Not sure if this is a great idea.  Started out as an
approach to pftool issue #31, allowing us to return to forcing filehandles
to only support MDAL or non-MDAL (i.e. getting the compiler to prevent
app-developers from hurting themselves).  But that would require all app
builds to reliably define USE_MDAL at compile-time, consistently with the
library they are linking, which is still error-prone.  Therefore, we still
keep both fd and MDAL-support in file-handles, and rely on app-developers
to never ever ever screw around with file-handle guts.
@shanegoff
Copy link
Contributor

Stale Issue cleanup

bertschinger pushed a commit to bertschinger/marfs that referenced this issue May 20, 2024
@gransom
Altered NoOp DAL read path to directly populate client buffers, rathe…
3703b86 
…r than performing a memcpy from an internally constructed buffer. This change is meant to drive down the internal memory bandwidth utilization of the NoOp DAL as much as possible. (mar-file-system#31)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
wontfix
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@brettkettering @jti-lanl @shanegoff