Tony Hutter

I like your proposal, with the only change being that close() would be the "local laminate()". So like: When a client process does a laminate() RPC, the server only returns...

Thanks @adammoody for the info on the open/writes/closes. What do you think of: local laminate: change permissions of the file to read-only global laminate: fsync Overall, I think it's beneficial...

Thinking about it more, we can get rid of the idea of a local lamination and just simplify it to "laminate() blocks until everyone (readers and writers) has closed the...

Across all nodes. The nodes would have to send an RPC on close(). Alternatively, you could remove the safety and simply say "if you call laminate(), you must be 100%...

Also: 1. chmod() and laminate details, including how we laminate files when we copy them in from a non-UnifyFS filesystem to /unifyfs. 2. fsync() meaning in a UnifyFS sense 3....

@MichaelBrim that's a good point about the mountpoint serving as the namespace name. Question though: Let's say your UnifyFS dir is called `/stuff`. You write files to `/stuff`. Then the...

@MichaelBrim that's true. You couldn't copy from the server's `/stuff` to Unify's `/stuff` though, but that probably an edge case we don't care about.

I've been playing around with busybox and I'm now able to get it to build against UnifyFS using gotcha. It's super broken right now, but the fact that it even...

I've been able to get the Unify client to build in a hacky way so that you don't need to use MPI (which was causing a bunch of problems with...

I dunno if this is relevant, but `stat()` is weird in that it may be externed as `stat()` or inlined to `__xstat()` in `/usr/include/sys/stat.h`: ```C #ifndef __USE_FILE_OFFSET64 /* Get file...