Mini-Conference Proposal: olpcfs

[C. Scott Ananian]

On Tue, Mar 25, 2008 at 11:44 AM, Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:
> On Mon, Mar 24, 2008 at 5:35 PM, C. Scott Ananian <cscott at laptop.org> 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?

Yes.

>  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
(http://www.fsl.cs.sunysb.edu/docs/amino-phdthesis/amino.ps) 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
examples?
 --scott

-- 
 ( http://cscott.net/ )