Mini-Conference Proposal: olpcfs

C. Scott Ananian cscott at
Wed Apr 2 13:42:06 EDT 2008

On Tue, Mar 25, 2008 at 11:44 AM, Tomeu Vizoso <tomeu at> wrote:
> On Mon, Mar 24, 2008 at 5:35 PM, C. Scott Ananian <cscott at> wrote:
>  >  Delta-based storage is an implementation detail, certainly possible (I
>  >  provided cites in the olpcfs page for how it would be done).  I don't
>  >  think it should be a visible part of the API.
>  Of course it is an implementation detail, but one that is a major
>  roadblock in the effort to implement the specified design.

The olpcfs design envisions a user-space process to do garbage
collection of old versions; it's not hard to do delta-compression in
userspace.  xdelta and bsdiff do a fine job.  To transparently
uncompress when the old version is accessed is only a little more
difficult, you just link to libxdelta2.

>  >  >  - get a saner way of passing files from activity side to the DS-managed side,
>  >
>  >  My answer here: they are just files.  All existing applications can
>  >  open files, given a path.
>  I was talking here about the other way, checking in files into the DS:
>  during a Write session, what needs to do the activity in order to get
>  a new version every time after the user clicks on the Keep button?
>  Just close the file and open it again?


>  In most cases, every time an activity saves the current state several
>  files plus their metadata will be updated, can that happen atomically?

Well, it's certainly *possible* in the current implementation, but I'm
wary of promising too much.  POSIX generally doesn't provide
multi-file atomic update.  Amino
( extended
ACID transactions to POSIX-land via some heuristics (treat all
operations by this application as atomic, etc), but I'm not convinced
yet that this is necessary.  Can you provide some specific use

 ( )

More information about the Devel mailing list